Re: [jira] [Commented] (FELIX-6616) Dynamic greedy 1..1 references may activate with no reference service bound
Carsten’s example results in the sequence 1. bind X ranking 1 2. bind X ranking 100 3 unbind X ranking 1 IIRC this is explicitly mandated by the spec. This is a different order than Tom’s example. FWIW I suspect Tom’s situation can arise after component activation if two threads register two more X’s simultaneously at different rankings. > On Jul 11, 2023, at 11:55 PM, Christoph Läubrich (Jira) > wrote: > > >[ > https://issues.apache.org/jira/browse/FELIX-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742296#comment-17742296 > ] > > Christoph Läubrich commented on FELIX-6616: > --- > > [~cziegeler] I think what you describes is expected and the usual pattern for > dynamic single reference is using a AtomicReference and use the different > compare and set methods but I'm not sure if it is the same problem and why a > compnent should be "confused" here, maybe [~tjwatson] is referring to a > static (non dynamic) service where it would be indeed be quite unexpected. > >> Dynamic greedy 1..1 references may activate with no reference service bound >> --- >> >>Key: FELIX-6616 >>URL: https://issues.apache.org/jira/browse/FELIX-6616 >>Project: Felix >> Issue Type: Bug >> Components: Declarative Services (SCR) >> Affects Versions: scr-2.2.6 >> Reporter: Tom Watson >> Assignee: Tom Watson >> Priority: Major >>Fix For: scr-2.2.8 >> >> >> If using a 1..1 cardinality for a dynamic greedy reference there is a timing >> issue possible which will cause SCR to unbind all reference when activating >> the component. >> The timing window involves at least two threads. >> 1) thread 1 is in the process of activating the component with a 1..1 >> dynamic greedy reference to service X (ranking=1) >> 2) thread 2 is in the process of registering another service X with a higher >> service ranking=100 >> When this happens thread 1 determines it should bind service X ranking 1. >> Thread 1 creates the service component instance and enables the tracking of >> all the dependencies. It then proceeds to bind all the required services. >> Before binding service X ranking=1 thread 2 registers service X ranking=100. >> Thread 2 then finds the created service component instance that thread 1 >> has created (but is still in the process of binding all the services) and >> then thread 2 binds service X ranking=100. At this point thread 2 thinks >> the component actually got bound to service X ranking=1 so it begins to >> unbind it. Before unbinding, if thread 1 proceeds it will bind service X >> ranking=1. So now the component itself (depending on the implementation) >> will start using X ranking=1. But then thread 2 proceeds and it will unbind >> service X ranking=1. >> So basically we are left with this flow: >> 1) bind X ranking=100 >> 2) bind X ranking=1 >> 3) unbind X ranking =1 >> At this point the component will be confused and think it likely has no >> services to use. > > > > -- > This message was sent by Atlassian Jira > (v8.20.10#820010)
[jira] [Closed] (FELIX-1864) Manual is not longer generated
[ https://issues.apache.org/jira/browse/FELIX-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed FELIX-1864. --- Resolution: Invalid This is certainly no longer relevant > Manual is not longer generated > -- > > Key: FELIX-1864 > URL: https://issues.apache.org/jira/browse/FELIX-1864 > Project: Felix > Issue Type: Bug >Affects Versions: karaf-1.0.0 >Reporter: Moulliard Charles >Priority: Major > > The manual is not longer generated > The html page contains the following text : Unable to generate manual. > I see in maven the following error : ERROR: java.net.UnknownHostException: > cwiki.apache.org -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FELIX-6069) SCR detects cyclic dependency for dynamically bound service
[
https://issues.apache.org/jira/browse/FELIX-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467775#comment-17467775
]
David Jencks commented on FELIX-6069:
-
I don't think there's any practical way to detect this situation. You
shouldn't use circular references, they are never going to be very reliable.
> SCR detects cyclic dependency for dynamically bound service
> ---
>
> Key: FELIX-6069
> URL: https://issues.apache.org/jira/browse/FELIX-6069
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Andreas Lemmer
>Priority: Major
> Labels: cyclic, scr
>
> Problem case: A bundle with two components: Component1 binds Component2
> statically, Component2 binds Component1 dynamically. Both components have
> immediate=true (but changing that also doesn't help).
> When starting the bundle, there is (nearly always) a Framework error message
> from SCR:
> {{ERROR [org.apache.felix.scr] bundle org.apache.felix.scr:2.1.14
> (12)Circular reference detected trying to get service [Component1]}}
> {{stack of references: ServiceReference: [Component1]}}
> {{ServiceReference: [Component2]}}
> {{java.lang.Exception: stack trace}}
> {{at
> org.apache.felix.scr.impl.ComponentRegistry.enterCreate(ComponentRegistry.java:485)}}
> {{at
> org.apache.felix.scr.impl.BundleComponentActivator.enterCreate(BundleComponentActivator.java:735)}}
> {{at
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:882)}}
> SCR tries it again a few milliseconds later *which works*.
> The real problem here is the error logging indicating that something is not
> working. This is very disturbing, because the behavior changes from time to
> time which makes it very hard to see if something is really wrong or if it's
> just a temporary problem.
> In my opinion, SCR should first start Component2 without Component1, then
> start Component1 and then bind Component1 to Component2.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (FELIX-5076) Website shows a lot of issues
[ https://issues.apache.org/jira/browse/FELIX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467773#comment-17467773 ] David Jencks commented on FELIX-5076: - I'll note that this issue was opened long before the current Antora website was set up, but I obviously didn't review the new site carefully enough! > Website shows a lot of issues > - > > Key: FELIX-5076 > URL: https://issues.apache.org/jira/browse/FELIX-5076 > Project: Felix > Issue Type: Improvement > Components: Documentation >Reporter: Rolf Geuenich >Priority: Major > > On the projects website are a lot of glitches like doubled headings > (http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-application-demonstration.html), > no line breaks > (http://felix.apache.org/documentation/development/building-felix.html), a > lot of markdown links which are shown in text form instead as a link > (http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-application-demonstration.html), > dead links (http://felix.apache.org/documentation.html -> site map) etc. > I'm unable to find informations about how the webpage is generated or where > the files are stored. So I'm unable to help. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FELIX-5076) Website shows a lot of issues
[ https://issues.apache.org/jira/browse/FELIX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467772#comment-17467772 ] David Jencks commented on FELIX-5076: - Thanks Alexander!!! > Website shows a lot of issues > - > > Key: FELIX-5076 > URL: https://issues.apache.org/jira/browse/FELIX-5076 > Project: Felix > Issue Type: Improvement > Components: Documentation >Reporter: Rolf Geuenich >Priority: Major > > On the projects website are a lot of glitches like doubled headings > (http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-application-demonstration.html), > no line breaks > (http://felix.apache.org/documentation/development/building-felix.html), a > lot of markdown links which are shown in text form instead as a link > (http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-application-demonstration.html), > dead links (http://felix.apache.org/documentation.html -> site map) etc. > I'm unable to find informations about how the webpage is generated or where > the files are stored. So I'm unable to help. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (FELIX-4895) dead link to FAQ page
[ https://issues.apache.org/jira/browse/FELIX-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed FELIX-4895. --- > dead link to FAQ page > - > > Key: FELIX-4895 > URL: https://issues.apache.org/jira/browse/FELIX-4895 > Project: Felix > Issue Type: Bug > Components: Documentation >Reporter: Peter Platek >Priority: Major > > When clicking on FAQ link on: > http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html > it leads to "Page not found" -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (FELIX-4895) dead link to FAQ page
[ https://issues.apache.org/jira/browse/FELIX-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks resolved FELIX-4895. - Resolution: Fixed No longer a problem. Thanks Alexander! > dead link to FAQ page > - > > Key: FELIX-4895 > URL: https://issues.apache.org/jira/browse/FELIX-4895 > Project: Felix > Issue Type: Bug > Components: Documentation >Reporter: Peter Platek >Priority: Major > > When clicking on FAQ link on: > http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html > it leads to "Page not found" -- This message was sent by Atlassian Jira (v8.20.1#820001)
Re: [RESULT][VOTE] Apache Felix FileInstall 3.7.2 release
Wasn’t the vote open for only about 66 hours? No vetos in the following 6 hours, but…. David Jencks > On Oct 24, 2021, at 2:22 AM, Jean-Baptiste Onofre wrote: > > Hi everyone, > > This vote passed with the following result: > > +1 (binding): Ray Augé, JB Onofré, Pierre De Rop, Carsten Ziegeler > +1 (non binding): Grzegorz Grzybek > > I’m promoting the artifacts on Maven Central and dist, and I will update Jira. > > Thanks all for your vote! > > Regards > JB > >> Le 21 oct. 2021 à 17:03, Jean-Baptiste Onofré a écrit : >> >> Hi guys, >> >> I submit Apache Felix FileInstall 3.7.2 to your vote. >> >> This release includes several fixes introduced in FileInstall 3.7.0 due to >> bunch of changes. >> You can find details on the Release Notes. >> >> Release Notes: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100=12350194 >> >> Maven Staging Repository: >> https://repository.apache.org/content/repositories/orgapachefelix-1403/ >> >> Dist Staging Repository: >> https://dist.apache.org/repos/dist/dev/felix/fileinstall/ >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] -1 Don't approve the release (please provide specific comments) >> >> This vote will be open for at least 72 hours. >> >> Regards >> JB >
Re: iPojo Controller
I haven’t looked at the condition spec nor IPOJO’s @Controller, but for many years you’ve been able to influence the presence of DS component instances through configuration by making the component configuration-required and only supplying configurations for the instances you want. I seem to recall also controlling whether instances are created by having a mandatory reference and adjusting the target filter in configuration so it is or isn’t satisfied. David Jencks > On Sep 7, 2021, at 6:02 AM, Thomas Watson wrote: > > The condition specification is part of OSGi R8 Core and Compendium > releases. The OSGi R8 Core (Framework) implementation is available now > with implementations available from Felix and Equinox. The > condition factory specification is in the works but is not going to be > included with the OSGI R8 specifications ( > https://github.com/osgi/osgi/blob/design/168/.design/design-168.md). But > the declarative services specification for OSGi R8 has been updated to > include how conditions can influence service components. A release > candidate of Felix SCR 2.2.0-RC1 will be available shortly that implements > the latest OSGi R8 release candidate APIs. The final release of OSGi R8 > compendium will hopefully be released by October. All of that means that > it is not available in Karaf at this time. > > Tom > > On Tue, Sep 7, 2021 at 6:14 AM Bengt Rodehav wrote: > >> Thanks Karl for your tip. >> >> Do you know which version of DS/SCR is required for using the new condition >> specification? Is it included in Karaf? >> >> Unfortunately I don't have the possibility to help develop iPojo. I've >> helped out in a few projects before but I think iPojo is a bit over my head >> both in skills and time. >> >> Best regards, >> >> Bengt >> >> Den tis 7 sep. 2021 kl 11:10 skrev Karl Pauls : >> >>> Hi, >>> >>> I agree that iPojo is a very good component model and it will be hard >>> to replace it. I think the closest you could come to replace it with >>> would be a combination of Declarative Services (DS/SCR) and the new >>> condition specification [0] - obviously depends on what you where >>> actually doing with iPojo (for a simple @Controller it might be enough >>> to use conditions). >>> >>> That said, let me point out: there is no reason iPojo couldn't still >>> be developed - we just lack somebody to work on it for the time being. >>> If you (and/or others you know) want to continue to develop it that >>> certainly could be a way forward as well. >>> >>> regards, >>> >>> Karl >>> >>> >>> [0] >>> >> http://docs.osgi.org/specification/osgi.core/8.0.0/service.condition.html#service.condition >>> >>> >>> On Tue, Sep 7, 2021 at 10:39 AM Bengt Rodehav wrote: >>>> >>>> I have noticed that iPojo is not supported any more. That is >> unfortunate >>>> for us since we have built a lot of our functionality on iPojo. It's >>>> actually the best component model I have seen so far. >>>> >>>> We need to move on to something else then. What would you suggest? What >>>> alternative is closest to iPojo in functionality? >>>> >>>> The big difference for us has been the @Controller annotation. With >> this >>> we >>>> have a system where we enable/disable services using configurations. I >>>> really need some way to achieve the same but with another model than >>> iPojo. >>>> I would appreciate any suggestions. >>>> >>>> /Bengt >>> >>> >>> >>> -- >>> Karl Pauls >>> karlpa...@gmail.com >>> >>
Re: Putting subproject docs in the code repos -- sample preview available
inline... > On Jul 29, 2021, at 9:28 PM, Carsten Ziegeler wrote: > > I like the approach in general, the location of the adoc file within the scr > tree is a little bit awkward, but not a showstopper. To me Antora directory structure is a bit like maven project layout, once you get used to it anything else seems odd. We could shorten the path slightly to /docs/modules//pages/.adoc, making each subproject an Antora “module”. I think it’s a good idea to separate the docs under “docs” although Antora would be just as happy with /modules>/… The directory name “modules” doesn’t immediately imply “documentation” to me, and this shortening would put the required antora.yml next to e.g. the pom.xml. > What I personally don't like is that these files need to be written in > asciidoc and not gh markdown. But if everyone else is fine with that, I can > probably adjust. It might have been more appropriate to bring this up when I proposed using Antora. I’m curious what you prefer about markdown. I would not participate in a documentation project using markdown rather than AsciiDoc: I find it ugly and limited. David Jencks > > Regards > Carsten > > Am 29.07.2021 um 02:31 schrieb David Jencks: >> I’ve set up a somewhat usable preview workflow and a preview for scr for >> what I’d like for the subproject docs. >> Take a look at https://felix.staged.apache.org/. Scr is now in the nav >> under subprojects and linked from the table of subprojects. >> The minimal README.adoc is visible at >> https://github.com/djencks/felix-dev/tree/adoc-preview/scr. Note that here >> GitHub is rendering AsciiDoc. The source scr website content is at >> https://github.com/djencks/felix-dev/blob/adoc-preview/scr/docs/modules/ROOT/pages/subprojects/scr.adoc >> I’d suggest doing this transformation for all the subprojects currently >> relying on READMEs and moving the docs for the other subprojects from the >> felix-antora-site repo to appropriate places in felix-dev. >> David Jencks >>> On Jul 27, 2021, at 12:17 PM, David Jencks wrote: >>> >>> The new version of that page, >>> https://felix.staged.apache.org/documentation/subprojects.html, still has >>> links to the GitHub README. If we stick with this (my 3rd option) we >>> should at least also have links in the nav. >>> >>> I suspect that it’s not clear how my preferred solution would work or look. >>> I’ll see about setting up a preview for scr, since I already translated >>> the README to .adoc. >>> >>> In any case I’d suggest translating all the READMEs to AsciiDoc so all the >>> documentation is in the same language. GitHub renders AsciiDoc for READMEs >>> automatically. >>> >>> David Jencks >>> >>>> On Jul 27, 2021, at 2:05 AM, Carsten Ziegeler wrote: >>>> >>>> >>>> >>>> Am 27.07.2021 um 10:59 schrieb Bertrand Delacretaz: >>>>> On Tue, Jul 27, 2021 at 10:50 AM Carsten Ziegeler >>>>> wrote: >>>>>> ...I prefer having the docs of a subproject directly within git as this >>>>>> makes updates that involve code and docs much easier (a single PR)... >>>>> I also like that option as long as all modules are discoverable from >>>>> the main website. >>>>> For Sling and its more than 300 modules we have >>>>> https://sling.apache.org/repolist.html which lists all modules on a >>>>> single page. >>>> >>>> Good point, we have this at >>>> https://felix.apache.org/documentation/subprojects.html , the links >>>> currently either point to a readme in git or a page on the website. >>>> Regards >>>> Carsten >>>> >>>> -- >>>> Carsten Ziegeler >>>> Adobe Research Switzerland >>>> cziege...@apache.org >>> > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: Putting subproject docs in the code repos -- sample preview available
I’ve set up a somewhat usable preview workflow and a preview for scr for what I’d like for the subproject docs. Take a look at https://felix.staged.apache.org/. Scr is now in the nav under subprojects and linked from the table of subprojects. The minimal README.adoc is visible at https://github.com/djencks/felix-dev/tree/adoc-preview/scr. Note that here GitHub is rendering AsciiDoc. The source scr website content is at https://github.com/djencks/felix-dev/blob/adoc-preview/scr/docs/modules/ROOT/pages/subprojects/scr.adoc I’d suggest doing this transformation for all the subprojects currently relying on READMEs and moving the docs for the other subprojects from the felix-antora-site repo to appropriate places in felix-dev. David Jencks > On Jul 27, 2021, at 12:17 PM, David Jencks wrote: > > The new version of that page, > https://felix.staged.apache.org/documentation/subprojects.html, still has > links to the GitHub README. If we stick with this (my 3rd option) we should > at least also have links in the nav. > > I suspect that it’s not clear how my preferred solution would work or look. > I’ll see about setting up a preview for scr, since I already translated the > README to .adoc. > > In any case I’d suggest translating all the READMEs to AsciiDoc so all the > documentation is in the same language. GitHub renders AsciiDoc for READMEs > automatically. > > David Jencks > >> On Jul 27, 2021, at 2:05 AM, Carsten Ziegeler wrote: >> >> >> >> Am 27.07.2021 um 10:59 schrieb Bertrand Delacretaz: >>> On Tue, Jul 27, 2021 at 10:50 AM Carsten Ziegeler >>> wrote: >>>> ...I prefer having the docs of a subproject directly within git as this >>>> makes updates that involve code and docs much easier (a single PR)... >>> I also like that option as long as all modules are discoverable from >>> the main website. >>> For Sling and its more than 300 modules we have >>> https://sling.apache.org/repolist.html which lists all modules on a >>> single page. >> >> Good point, we have this at >> https://felix.apache.org/documentation/subprojects.html , the links >> currently either point to a readme in git or a page on the website. >> Regards >> Carsten >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org >
Re: Preview of new website?
I’ve switched the site over to the Antora site….
https://felix.apache.org/index.html
Assuming no major problems surface I’ll ask infra to decommission the CMS area
in the next day or two.
David Jencks
> On Jul 27, 2021, at 1:42 AM, Carsten Ziegeler wrote:
>
> +1
>
> And thanks to all the great work and effort you put into this, David! I think
> we all owe you something now :)
>
> Regards
> Carsten
>
> Am 26.07.2021 um 21:39 schrieb David Jencks:
>> I’ve:
>> - added a link to the KEYS file and validation instructions to the downloads
>> page.
>> - updated the site-how-to and release-management-nexus pages to correspond
>> to the Antora site.
>> - restored the components/bundle-plugin[-archives] documentation I deleted
>> earlier.
>> The CMS system is going to be deactivated in a few days. If there are no
>> more comments I’m going to switch over to the new site on Wednesday July 28
>> (2 days). I think the new site is definitely in usable condition and we can
>> deal with any remaining problems as they appear.
>> David Jencks
>>> On Jul 21, 2021, at 4:57 PM, David Jencks wrote:
>>>
>>> Some questions from fixing these…
>>>
>>> - Should the current core version be set as an attribute in the playbook
>>> so it is available on any page? I put it in the apache-felix-framwork.adoc
>>> page as
>>>
>>> :framework-version: R8
>>>
>>> but perhaps this would be more useful in the playbook.
>>>
>>> - I don’t know that we have current TCK compliance results for the
>>> framework or anything else…. do we? On the apache-felix-framework-faq.adoc
>>> I changed from an outdated and broken link to R4.2 to simply saying “Yes”
>>> to “is it compliant?”. This might be a place to use the version attribute,
>>> e.g. “is the framework R8 compliant?".
>>>
>>> And a couple of comments/questions below…
>>>
>>> Thanks!
>>> David Jencks
>>>
>>>
>>>> On Jul 21, 2021, at 2:39 PM, Karl Pauls >>> <mailto:karlpa...@gmail.com> <mailto:karlpa...@gmail.com
>>>> <mailto:karlpa...@gmail.com>>> wrote:
>>>>
>>>> Hi David,
>>>>
>>>> thanks again for taking care of this. Looks very good overall. I
>>>> noticed some minor issues namely,
>>>>
>>>> - In the top right corner (or the „hamburger“ menu in the mobile view)
>>>> we have „Projects“ which I think should rather be „Subprojects“ to be
>>>> consistent with the sidebar. That said, I’m not sure we need the
>>>> „hamburger“ menu/the top right corner short links at all as they are
>>>> in the sidebar anyways (but I don’t feel too strongly about it).
>>> fixed
>>>> - On the download page, the links for the framework distribution are
>>>> not correct. They need to target the distribution artifacts (i.e.,
>>>> org.apache.felix.main.distribution-7.0.0.tar.gz and
>>>> org.apache.felix.main.distribution-7.0.0.zip)
>>> I changed the (top) “framework distribution” section. Is it correct for
>>> the subprojects framework entry points to the framework jar and related
>>> source-release artifacts?
>>>>
>>>> - The framework page
>>>> (https://felix.staged.apache.org/documentation/subprojects/apache-felix-framework.html
>>>>
>>>> <https://felix.staged.apache.org/documentation/subprojects/apache-felix-framework.html><https://felix.staged.apache.org/documentation/subprojects/apache-felix-framework.html
>>>>
>>>> <https://felix.staged.apache.org/documentation/subprojects/apache-felix-framework.html>>)
>>>> has only a broken listing „{% for label, page in children %}* link:{{
>>>> page.path }}[{{ page.headers.title }}] {% endfor %}“
>>> fixed
>>>>
>>>> - In the framework FAQ
>>>> (/documentation/subprojects/apache-felix-framework/apache-felix-framework-faq.html)
>>>> there are some broken links.
>>> fixed
>>>>
>>>> - The index page does say: „A list of javascript extracted news
>>>> excerpts:“ but there are no excerpts. If that is hard todo right now,
>>>> maybe we should just remove that notice?
>>>>
>>> If we put the list of releases in a .yml or json5 file that would be
>>> plausible, but I don’t think it adds much value. I removed the placeholder.
>>>> - Ultimately, it would be very
[Website] Atomos download problem
While fixing a few problems with the new downloads page I found some with Atomos. The old download page is incorrect, as it links to one of the atomos binary bundles but the only required links, to the source archives, are broken. I fixed that problem on the new downloads page, so the tar.gz and zip point to the correct atomos-distribution artifacts, so it’s at least compliant with requirements, but there is no atomos-distribution binary jar and I have no idea which of the many actual jars, if any, or all, is or are the correct one or ones to link from. I don’t see anything in the atomos readme to guide me. At the moment there’s no binary artifact listed for atomos. David Jencks
Possible release/download page cleanup
I believe the release area at https://www.apache.org/dist/felix has the latest release of every Felix subproject, and the download page lists most of them. I think that having a project represented in “releases” and on the download page implies that it’s maintained and that problems will be addressed by the existing committers. For a lot of subprojects, this is no longer true: we even list some as retired. I suggest that we remove all the unmaintained projects from dist and the downloads page. If we agree that this is a good idea, I’ll propose lists of “keep” and “remove” which we can then debate. Note that all releases remain available in the archives, as well as from maven central. David Jencks
Re: Putting subproject docs in the code repos
The new version of that page, https://felix.staged.apache.org/documentation/subprojects.html, still has links to the GitHub README. If we stick with this (my 3rd option) we should at least also have links in the nav. I suspect that it’s not clear how my preferred solution would work or look. I’ll see about setting up a preview for scr, since I already translated the README to .adoc. In any case I’d suggest translating all the READMEs to AsciiDoc so all the documentation is in the same language. GitHub renders AsciiDoc for READMEs automatically. David Jencks > On Jul 27, 2021, at 2:05 AM, Carsten Ziegeler wrote: > > > > Am 27.07.2021 um 10:59 schrieb Bertrand Delacretaz: >> On Tue, Jul 27, 2021 at 10:50 AM Carsten Ziegeler >> wrote: >>> ...I prefer having the docs of a subproject directly within git as this >>> makes updates that involve code and docs much easier (a single PR)... >> I also like that option as long as all modules are discoverable from >> the main website. >> For Sling and its more than 300 modules we have >> https://sling.apache.org/repolist.html which lists all modules on a >> single page. > > Good point, we have this at > https://felix.apache.org/documentation/subprojects.html , the links currently > either point to a readme in git or a page on the website. > Regards > Carsten > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Putting subproject docs in the code repos
The CMS website and the Antora website currently have the docs source far from the code. As a result several subprojects (SCR, Atomos at least) have put their documentation in a README in the same git repo as the code. This results in these subproject documentation appearing really different from other subprojects docs and lacking the overall navigation facilities from the site. Currently the Antora based website doesn’t attempt to include this documentation. With Antora this is not necessary: Antora can extract documentation source from any number of git repos and assemble it all seamlessly. I think it would be a good idea to set this up. In general Antora requires sources in each git repo to be in a specific directory structure, for the current felix site `…/modules/ROOT/pages/*.adoc`. There are several choices for how to do this: - Move the README contents to a concrete .adoc page in the above structure and have the README mostly point to the website. This allows use of the full power of Asciidoc on the pages, rather than the quite constricted subset available from the GitHub asciidoc renderer (or the GitHub markdown renderer). I think this is the best choice. - Symlink from the above structure location to the README (which will need to be translated to Asciidoc, which will still be rendered by GitHub). Symlink support was recently added to Antora but I haven’t tried it in this scenario. This would give the same content at GitHub (in roughly its current format) and in the website(integrated, with nav, header, footer, etc), but would limit subproject documentation to a single page and inhibit links to other website pages, among other problems. - Add (external) links in the nav to the READMEs on GitHub. In this case there will be no version of the documentation integrated into the website. Thoughts? Some other current and future possibilities with Antora: - It’s easy to have many versions of documentation for each subproject. However, I doubt the effort to maintain multiple documentation versions is reasonable for the Felix community. - Most likely soon it will be plausible to include javadoc as site pages with navigation, ability to link to javadoc pages, etc. AFAICT the limited apidocs currently in the site are not linked to in any way. David Jencks
Re: Preview of new website?
I’ve:
- added a link to the KEYS file and validation instructions to the downloads
page.
- updated the site-how-to and release-management-nexus pages to correspond to
the Antora site.
- restored the components/bundle-plugin[-archives] documentation I deleted
earlier.
The CMS system is going to be deactivated in a few days. If there are no more
comments I’m going to switch over to the new site on Wednesday July 28 (2
days). I think the new site is definitely in usable condition and we can deal
with any remaining problems as they appear.
David Jencks
> On Jul 21, 2021, at 4:57 PM, David Jencks wrote:
>
> Some questions from fixing these…
>
> - Should the current core version be set as an attribute in the playbook so
> it is available on any page? I put it in the apache-felix-framwork.adoc page
> as
>
> :framework-version: R8
>
> but perhaps this would be more useful in the playbook.
>
> - I don’t know that we have current TCK compliance results for the framework
> or anything else…. do we? On the apache-felix-framework-faq.adoc I changed
> from an outdated and broken link to R4.2 to simply saying “Yes” to “is it
> compliant?”. This might be a place to use the version attribute, e.g. “is
> the framework R8 compliant?".
>
> And a couple of comments/questions below…
>
> Thanks!
> David Jencks
>
>
>> On Jul 21, 2021, at 2:39 PM, Karl Pauls > <mailto:karlpa...@gmail.com>> wrote:
>>
>> Hi David,
>>
>> thanks again for taking care of this. Looks very good overall. I
>> noticed some minor issues namely,
>>
>> - In the top right corner (or the „hamburger“ menu in the mobile view)
>> we have „Projects“ which I think should rather be „Subprojects“ to be
>> consistent with the sidebar. That said, I’m not sure we need the
>> „hamburger“ menu/the top right corner short links at all as they are
>> in the sidebar anyways (but I don’t feel too strongly about it).
> fixed
>> - On the download page, the links for the framework distribution are
>> not correct. They need to target the distribution artifacts (i.e.,
>> org.apache.felix.main.distribution-7.0.0.tar.gz and
>> org.apache.felix.main.distribution-7.0.0.zip)
> I changed the (top) “framework distribution” section. Is it correct for the
> subprojects framework entry points to the framework jar and related
> source-release artifacts?
>>
>> - The framework page
>> (https://felix.staged.apache.org/documentation/subprojects/apache-felix-framework.html
>>
>> <https://felix.staged.apache.org/documentation/subprojects/apache-felix-framework.html>)
>> has only a broken listing „{% for label, page in children %}* link:{{
>> page.path }}[{{ page.headers.title }}] {% endfor %}“
> fixed
>>
>> - In the framework FAQ
>> (/documentation/subprojects/apache-felix-framework/apache-felix-framework-faq.html)
>> there are some broken links.
> fixed
>>
>> - The index page does say: „A list of javascript extracted news
>> excerpts:“ but there are no excerpts. If that is hard todo right now,
>> maybe we should just remove that notice?
>>
> If we put the list of releases in a .yml or json5 file that would be
> plausible, but I don’t think it adds much value. I removed the placeholder.
>> - Ultimately, it would be very good to update the
>> https://felix.staged.apache.org/documentation/development/site-how-to.html
>> <https://felix.staged.apache.org/documentation/development/site-how-to.html>
>> with the new way of working and update the bits about changing the
>> side on releases as well here:
>> https://felix.staged.apache.org/documentation/development/release-management-nexus.html#_update_the_site
>
> Soon :-)
>>
>> I think it would be good if we could get these fixed before the
>> switch. Otherwise, I think we are good to go - thanks a lot!
>>
>> Regards,
>>
>> Karl
>>
>> On Wed, Jul 21, 2021 at 6:18 PM David Jencks > <mailto:david.a.jen...@gmail.com>> wrote:
>>>
>>> Thanks!, fixed.
>>>
>>> David Jencks
>>>
>>>> On Jul 21, 2021, at 1:04 AM, Александр Шаклеин >>> <mailto:cheester...@gmail.com>> wrote:
>>>>
>>>> Hi all
>>>> Tutorials page starting with code block
>>>>
>>>> ср, 21 июл. 2021 г., 10:01 David Jencks >>> <mailto:david.a.jen...@gmail.com>>:
>>>>
>>>>> I’ve updated the UI to fix the problems noted, and made the logo have a
>>>>> transparent background as Amit suggested. For some reason Safari doesn’t
>>>&
Re: Preview of new website?
Some questions from fixing these…
- Should the current core version be set as an attribute in the playbook so it
is available on any page? I put it in the apache-felix-framwork.adoc page as
:framework-version: R8
but perhaps this would be more useful in the playbook.
- I don’t know that we have current TCK compliance results for the framework or
anything else…. do we? On the apache-felix-framework-faq.adoc I changed from
an outdated and broken link to R4.2 to simply saying “Yes” to “is it
compliant?”. This might be a place to use the version attribute, e.g. “is the
framework R8 compliant?".
And a couple of comments/questions below…
Thanks!
David Jencks
> On Jul 21, 2021, at 2:39 PM, Karl Pauls wrote:
>
> Hi David,
>
> thanks again for taking care of this. Looks very good overall. I
> noticed some minor issues namely,
>
> - In the top right corner (or the „hamburger“ menu in the mobile view)
> we have „Projects“ which I think should rather be „Subprojects“ to be
> consistent with the sidebar. That said, I’m not sure we need the
> „hamburger“ menu/the top right corner short links at all as they are
> in the sidebar anyways (but I don’t feel too strongly about it).
fixed
> - On the download page, the links for the framework distribution are
> not correct. They need to target the distribution artifacts (i.e.,
> org.apache.felix.main.distribution-7.0.0.tar.gz and
> org.apache.felix.main.distribution-7.0.0.zip)
I changed the (top) “framework distribution” section. Is it correct for the
subprojects framework entry points to the framework jar and related
source-release artifacts?
>
> - The framework page
> (https://felix.staged.apache.org/documentation/subprojects/apache-felix-framework.html)
> has only a broken listing „{% for label, page in children %}* link:{{
> page.path }}[{{ page.headers.title }}] {% endfor %}“
fixed
>
> - In the framework FAQ
> (/documentation/subprojects/apache-felix-framework/apache-felix-framework-faq.html)
> there are some broken links.
fixed
>
> - The index page does say: „A list of javascript extracted news
> excerpts:“ but there are no excerpts. If that is hard todo right now,
> maybe we should just remove that notice?
>
If we put the list of releases in a .yml or json5 file that would be plausible,
but I don’t think it adds much value. I removed the placeholder.
> - Ultimately, it would be very good to update the
> https://felix.staged.apache.org/documentation/development/site-how-to.html
> with the new way of working and update the bits about changing the
> side on releases as well here:
> https://felix.staged.apache.org/documentation/development/release-management-nexus.html#_update_the_site
Soon :-)
>
> I think it would be good if we could get these fixed before the
> switch. Otherwise, I think we are good to go - thanks a lot!
>
> Regards,
>
> Karl
>
> On Wed, Jul 21, 2021 at 6:18 PM David Jencks wrote:
>>
>> Thanks!, fixed.
>>
>> David Jencks
>>
>>> On Jul 21, 2021, at 1:04 AM, Александр Шаклеин
>>> wrote:
>>>
>>> Hi all
>>> Tutorials page starting with code block
>>>
>>> ср, 21 июл. 2021 г., 10:01 David Jencks :
>>>
>>>> I’ve updated the UI to fix the problems noted, and made the logo have a
>>>> transparent background as Amit suggested. For some reason Safari doesn’t
>>>> seem to load the fixed logo, but it looks fine on Chrome and Firefox.
>>>>
>>>> I need to do something about the changelog links on the download page, but
>>>> it’s not any worse than the current download page where these links are all
>>>> broken.
>>>>
>>>> Any other comments? I think infra would appreciate us switching to the
>>>> new site soon.
>>>>
>>>> Thanks
>>>> David Jencks
>>>>
>>>>> On Jul 19, 2021, at 11:26 PM, David Jencks
>>>> wrote:
>>>>>
>>>>> Hi Amit,
>>>>>
>>>>> Great idea, and it looks like there are free tools to do that that even
>>>> I will be able to figure out how to use!
>>>>>
>>>>> Thanks
>>>>> David
>>>>>
>>>>>> On Jul 19, 2021, at 10:57 PM, Amit Mondal wrote:
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> The new revamped website looks pretty awesome. I have one tiny
>>>> proposal: we could make the Felix logo transparent so that it looks
>>>> dissolved on the background.
>>>>>>
>>>>>> Best Regards,
>>>>>>
Re: Preview of new website?
Thanks!, fixed. David Jencks > On Jul 21, 2021, at 1:04 AM, Александр Шаклеин wrote: > > Hi all > Tutorials page starting with code block > > ср, 21 июл. 2021 г., 10:01 David Jencks : > >> I’ve updated the UI to fix the problems noted, and made the logo have a >> transparent background as Amit suggested. For some reason Safari doesn’t >> seem to load the fixed logo, but it looks fine on Chrome and Firefox. >> >> I need to do something about the changelog links on the download page, but >> it’s not any worse than the current download page where these links are all >> broken. >> >> Any other comments? I think infra would appreciate us switching to the >> new site soon. >> >> Thanks >> David Jencks >> >>> On Jul 19, 2021, at 11:26 PM, David Jencks >> wrote: >>> >>> Hi Amit, >>> >>> Great idea, and it looks like there are free tools to do that that even >> I will be able to figure out how to use! >>> >>> Thanks >>> David >>> >>>> On Jul 19, 2021, at 10:57 PM, Amit Mondal wrote: >>>> >>>> Hi David, >>>> >>>> The new revamped website looks pretty awesome. I have one tiny >> proposal: we could make the Felix logo transparent so that it looks >> dissolved on the background. >>>> >>>> Best Regards, >>>> Amit >>>> >>>> From: David Jencks >>>> Sent: 20 July 2021 02:25 >>>> To: dev@felix.apache.org >>>> Subject: Re: Preview of new website? >>>> >>>> I’ve set up a preview at https://felix.staged.apache.org/ >>>> >>>> I think the content is in an acceptable if not ideal state to switch >> over from the CMS site. >>>> >>>> The top bar of the UI needs some work: >>>> - feather looks weird >>>> - “apache felix” both in logo and text >>>> - links in drop-downs broken >>>> - downloads link broken. >>>> >>>> I’d like to integrate the README-based subproject documentation (e.g. >> atomos, scr) better but I’ll discuss that in another email. >>>> >>>> David Jencks >>>> >>>>> On Jul 14, 2021, at 2:18 PM, Karl Pauls wrote: >>>>> >>>>> Hi David, >>>>> >>>>> sounds like very good progress - thanks a lot for looking into this! >>>>> >>>>> I think a preview would be good if it is not too much work. >>>>> >>>>> regards, >>>>> >>>>> Karl >>>>> >>>>> On Wed, Jul 14, 2021 at 11:06 PM David Jencks < >> david.a.jen...@gmail.com> wrote: >>>>>> >>>>>> I hope to get the new Antora based website deployable in the next few >> days, the main task left is setting up an .htaccess file with redirects >> from the old page locations to the new. >>>>>> >>>>>> Does anyone want to see a preview before I make the new site live, or >> shall we assume the best and fix any problems anyone notices? >>>>>> >>>>>> Thanks >>>>>> David Jencks >>>>> >>>>> >>>>> >>>>> -- >>>>> Karl Pauls >>>>> karlpa...@gmail.com >>>> >>> >> >>
Re: Preview of new website?
I’ve updated the UI to fix the problems noted, and made the logo have a transparent background as Amit suggested. For some reason Safari doesn’t seem to load the fixed logo, but it looks fine on Chrome and Firefox. I need to do something about the changelog links on the download page, but it’s not any worse than the current download page where these links are all broken. Any other comments? I think infra would appreciate us switching to the new site soon. Thanks David Jencks > On Jul 19, 2021, at 11:26 PM, David Jencks wrote: > > Hi Amit, > > Great idea, and it looks like there are free tools to do that that even I > will be able to figure out how to use! > > Thanks > David > >> On Jul 19, 2021, at 10:57 PM, Amit Mondal wrote: >> >> Hi David, >> >> The new revamped website looks pretty awesome. I have one tiny proposal: we >> could make the Felix logo transparent so that it looks dissolved on the >> background. >> >> Best Regards, >> Amit >> >> From: David Jencks >> Sent: 20 July 2021 02:25 >> To: dev@felix.apache.org >> Subject: Re: Preview of new website? >> >> I’ve set up a preview at https://felix.staged.apache.org/ >> >> I think the content is in an acceptable if not ideal state to switch over >> from the CMS site. >> >> The top bar of the UI needs some work: >> - feather looks weird >> - “apache felix” both in logo and text >> - links in drop-downs broken >> - downloads link broken. >> >> I’d like to integrate the README-based subproject documentation (e.g. >> atomos, scr) better but I’ll discuss that in another email. >> >> David Jencks >> >>> On Jul 14, 2021, at 2:18 PM, Karl Pauls wrote: >>> >>> Hi David, >>> >>> sounds like very good progress - thanks a lot for looking into this! >>> >>> I think a preview would be good if it is not too much work. >>> >>> regards, >>> >>> Karl >>> >>> On Wed, Jul 14, 2021 at 11:06 PM David Jencks >>> wrote: >>>> >>>> I hope to get the new Antora based website deployable in the next few >>>> days, the main task left is setting up an .htaccess file with redirects >>>> from the old page locations to the new. >>>> >>>> Does anyone want to see a preview before I make the new site live, or >>>> shall we assume the best and fix any problems anyone notices? >>>> >>>> Thanks >>>> David Jencks >>> >>> >>> >>> -- >>> Karl Pauls >>> karlpa...@gmail.com >> >
Re: Preview of new website?
Hi Amit, Great idea, and it looks like there are free tools to do that that even I will be able to figure out how to use! Thanks David > On Jul 19, 2021, at 10:57 PM, Amit Mondal wrote: > > Hi David, > > The new revamped website looks pretty awesome. I have one tiny proposal: we > could make the Felix logo transparent so that it looks dissolved on the > background. > > Best Regards, > Amit > ____ > From: David Jencks > Sent: 20 July 2021 02:25 > To: dev@felix.apache.org > Subject: Re: Preview of new website? > > I’ve set up a preview at https://felix.staged.apache.org/ > > I think the content is in an acceptable if not ideal state to switch over > from the CMS site. > > The top bar of the UI needs some work: > - feather looks weird > - “apache felix” both in logo and text > - links in drop-downs broken > - downloads link broken. > > I’d like to integrate the README-based subproject documentation (e.g. atomos, > scr) better but I’ll discuss that in another email. > > David Jencks > >> On Jul 14, 2021, at 2:18 PM, Karl Pauls wrote: >> >> Hi David, >> >> sounds like very good progress - thanks a lot for looking into this! >> >> I think a preview would be good if it is not too much work. >> >> regards, >> >> Karl >> >> On Wed, Jul 14, 2021 at 11:06 PM David Jencks >> wrote: >>> >>> I hope to get the new Antora based website deployable in the next few days, >>> the main task left is setting up an .htaccess file with redirects from the >>> old page locations to the new. >>> >>> Does anyone want to see a preview before I make the new site live, or shall >>> we assume the best and fix any problems anyone notices? >>> >>> Thanks >>> David Jencks >> >> >> >> -- >> Karl Pauls >> karlpa...@gmail.com >
Re: Preview of new website?
I’ve set up a preview at https://felix.staged.apache.org/ I think the content is in an acceptable if not ideal state to switch over from the CMS site. The top bar of the UI needs some work: - feather looks weird - “apache felix” both in logo and text - links in drop-downs broken - downloads link broken. I’d like to integrate the README-based subproject documentation (e.g. atomos, scr) better but I’ll discuss that in another email. David Jencks > On Jul 14, 2021, at 2:18 PM, Karl Pauls wrote: > > Hi David, > > sounds like very good progress - thanks a lot for looking into this! > > I think a preview would be good if it is not too much work. > > regards, > > Karl > > On Wed, Jul 14, 2021 at 11:06 PM David Jencks > wrote: >> >> I hope to get the new Antora based website deployable in the next few days, >> the main task left is setting up an .htaccess file with redirects from the >> old page locations to the new. >> >> Does anyone want to see a preview before I make the new site live, or shall >> we assume the best and fix any problems anyone notices? >> >> Thanks >> David Jencks > > > > -- > Karl Pauls > karlpa...@gmail.com
Re: The migration of the Felix website off the Apache CMS
- Construct an appropriate .htaccess file mapping old page locations to new ones. - Finish the new download page. - Set up a preview site. - Review everything. - Adjust .asf.yml to publish site. - Deactive the CMS site. We could start with the last two steps, but I’d rather not. David Jencks > On Jul 15, 2021, at 6:47 AM, Andrew Wetmore wrote: > > Hi: > > I gather, per your Jira ticket INFRA-20635, that your ci folder is set up > and that you have been able to start using it. What other steps need > completion before Felix is able to bid farewell to the Apache CMS? > > Thanks! > Andrew > -- > Andrew Wetmore > Technical Writer-Editor > Infra > *Apache Software Foundation* > andr...@apache.org > > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Preview of new website?
I hope to get the new Antora based website deployable in the next few days, the main task left is setting up an .htaccess file with redirects from the old page locations to the new. Does anyone want to see a preview before I make the new site live, or shall we assume the best and fix any problems anyone notices? Thanks David Jencks
New website question #2 - downloads page (3 part question/proposal)
I can’t figure out how the current downloads page is generated. It’s evident
that there’s a text file with version info that is used in the generation, but
where the base text comes from is not evident to me.
Furthermore, AFAICT the current changelog links are all broken (I think the
generation mechanism assumes svn rather than git).
1. I’ve prototyped a replacement that I at least find more self-documenting.
The version source data would be in a yaml file (or json, but yaml is more
human-friendly). A typical entry would be something like
——
subprojects:
- title: Atomos
artifactId: org.apache.felix.atomos
version: 1.0.0
——
I think this is pretty easy to understand/modify and better than the current
text file.
The slightly less satisfactory part is the formatting for the output, which
currently looks like:
——
[cols="6*",opts="headers"]
|===
|Module
|Version
|Binary
|tar.gz Source
|zip Source
|changelog
|===
jsonpathTable2::example$downloads.yml['$.subprojects.*',
'title|version|`{mirror}/$\{artifactId}-$\{version}.jar{query}[jar]
({dist}/$\{artifactId}-$\{version}.jar.asc[asc],
{dist}/$\{artifactId}-$\{version}.jar.sha1[sha1])` |!!targz ?
`{mirror}/$\{artifactId}-$\{version}-source-release.tar.gz{query}[tar.gz]
({dist}/$\{artifactId}-$\{version}-source-release.tar.gz.asc[asc],
{dist}/$\{artifactId}-$\{version}-source-release.tar.gz.sha1[sha1])` : ""
|`{mirror}/$\{artifactId}-$\{version}-source-release.zip{query}[zip]
({dist}/$\{artifactId}-$\{version}-source-release.zip.asc[asc],
{dist}/$\{artifactId}-$\{version}-source-release.zip.sha1[sha1])` |changelog']
——
The first part between the |=== is normal AsciiDoc table formatting, which is
easy to understand, but the jsonpathTable2 block macro instruction that formats
the yaml content into the table cells is admittedly difficult to understand. I
haven’t finished documenting the syntax for this, but docs for an earlier
version are here: https://gitlab.com/djencks/asciidoctor-jsonpath.
If someone explains how the current generation works I could try to use that
instead but I don’t know if it will work.
I’m planning to go ahead with this new approach unless there are objections and
an explanation of an alternative.
2. I think it’s implausible to link to git to the exact changelog version for
each release. AFAICT it would require putting the exact blob link into each
subproject yaml entry (or text file, if we stay with the current generation
approach). Instead, I think it’s fine to link to the git HEAD changelog. Since
there are already a variety of git paths used this is already going to b e a
significant effort to maintain.
3. I suggest we remove all non-maintained subprojects from the download page.
They will always be available from the historical releases, but we shouldn’t
be encouraging anyone to use them.
Comments? Suggestions?
Thanks
David Jencks
New Website question #1 - Docs for dead subproject.
I’m hoping to finish the conversion to a new Antora/AsciiDoc based website soon. The (perhaps not quite up to date) preview is at https://felix-preview.s3.us-west-2.amazonaws.com/documentation/index.html. The content source is visible at felix-antora-site <https://github.com/apache/felix-antora-site> I haven’t pushed the Antora playbook that builds the site yet, but should be able to soon. I have several questions about how to proceed that I’ll ask one-per-email. The current website has docs for several subprojects that aren’t being developed any more, notable iPOJO. These docs in particular seem to already have been through one episode of partial conversion from another format resulting in some rather unpleasant source code. I don’t want to spend the time translating this to proper AsciiDoc. Can we drop documentation for subprojects that are no longer maintained? I think having documentation easily visible gives an impression that using these projects is plausible. Perhaps we can have a branch in felix-site-pub where the last version of the html can be looked at, and links to it from an “obsolete subproject” page. Thanks David Jencks
Re: project doc website migration
I’ve pushed the current state of my migration, and the DM stuff is mostly under https://github.com/apache/felix-antora-site/tree/main/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager. It would probably be best to wait to push changes until things are cleaned up a bit more and I’ve had infra turn the commit notifications back on, but you can certainly work on a PR. I think the DM .adocs are fine, but haven’t reviewed recently. I also need to push the repo that has the site build. It’s too hot here to do much but I hope to make progress soon. David Jencks > On Jun 27, 2021, at 1:14 AM, David Jencks wrote: > > Hi Pierre, > > I should be able to push the current state later Sunday. I’ve already > converted the content to asciidoc, with some exceptions I need to discuss > separately. I think the DM content is all converted. > > Thanks, > David Jencks > >> On Jun 26, 2021, at 1:20 AM, Pierre De Rop wrote: >> >> Hi David, >> >> There is no rush, I can wait until all is migrated, and I don't want to add >> extra work to what you are doing. >> >> So, when you say I could possibly create a PR against the .adoc files in >> your GitHub repo (but I won't, there is no rush), I'm not sure to >> understand if I would first have to convert the existing dependency manager >> documentations from [1] into some .adoc files, then submit the converted >> files ? or have you already converted [1] into some .adoc files ? Then in >> this case, where are they located ? >> I'm asking because from your repo, I only found a "adoc-test" branch and >> from there, I only found scr/modules/scr/pages/scr.adoc. >> So, maybe there is another branch when you are converted everything ? >> >> I'm asking this to try to catch-up with all what you have done, thanks. >> >> [1] >> http://svn.apache.org/repos/asf/felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager/ >> >> regards >> /pierre >> >> >> On Fri, Jun 25, 2021 at 8:10 PM David Jencks >> wrote: >> >>> Hi Pierre, >>> >>> Thanks for asking! >>> >>> The new site work has taken much longer than I planned, partly to do me >>> and partly due to infra. I’d like to get it set up soon. I have some >>> questions that I’ll try to ask in the next couple of days. >>> >>> What’s your timeline? How extensive are the changes? >>> >>> It would be most convenient for me if you made a PR against the .adoc >>> files in a GitHub “djencks” repo I’ll push later today or tomorrow, or >>> waited till the new site is set up at apache even if not published. This >>> would result in some delay in publishing the changes. You can modify the >>> CMS based site but then I’ll have to port the changes, which is certainly >>> possible but more work for me. >>> >>> David Jencks >>> >>>> On Jun 25, 2021, at 12:12 AM, Pierre De Rop >>> wrote: >>>> >>>> Hi all, >>>> >>>> I did not have time to follow, but I think that David (Jencks) is working >>>> on migrating the felix website to a new technology (thanks David for >>> taking >>>> care of that). >>>> >>>> So, first, I wonder if I need to do specific things regarding the >>>> DependencyManager documentation ? >>>> >>>> Then, I wonder if I can currently modify the existing DependencyManager >>>> documentation ? or if I must wait until all is migrated before modifying >>>> anything ? >>>> >>>> thank you >>>> >>>> kind regards >>>> /pierre >>> >>> >
Re: project doc website migration
Hi Pierre, I should be able to push the current state later Sunday. I’ve already converted the content to asciidoc, with some exceptions I need to discuss separately. I think the DM content is all converted. Thanks, David Jencks > On Jun 26, 2021, at 1:20 AM, Pierre De Rop wrote: > > Hi David, > > There is no rush, I can wait until all is migrated, and I don't want to add > extra work to what you are doing. > > So, when you say I could possibly create a PR against the .adoc files in > your GitHub repo (but I won't, there is no rush), I'm not sure to > understand if I would first have to convert the existing dependency manager > documentations from [1] into some .adoc files, then submit the converted > files ? or have you already converted [1] into some .adoc files ? Then in > this case, where are they located ? > I'm asking because from your repo, I only found a "adoc-test" branch and > from there, I only found scr/modules/scr/pages/scr.adoc. > So, maybe there is another branch when you are converted everything ? > > I'm asking this to try to catch-up with all what you have done, thanks. > > [1] > http://svn.apache.org/repos/asf/felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager/ > > regards > /pierre > > > On Fri, Jun 25, 2021 at 8:10 PM David Jencks > wrote: > >> Hi Pierre, >> >> Thanks for asking! >> >> The new site work has taken much longer than I planned, partly to do me >> and partly due to infra. I’d like to get it set up soon. I have some >> questions that I’ll try to ask in the next couple of days. >> >> What’s your timeline? How extensive are the changes? >> >> It would be most convenient for me if you made a PR against the .adoc >> files in a GitHub “djencks” repo I’ll push later today or tomorrow, or >> waited till the new site is set up at apache even if not published. This >> would result in some delay in publishing the changes. You can modify the >> CMS based site but then I’ll have to port the changes, which is certainly >> possible but more work for me. >> >> David Jencks >> >>> On Jun 25, 2021, at 12:12 AM, Pierre De Rop >> wrote: >>> >>> Hi all, >>> >>> I did not have time to follow, but I think that David (Jencks) is working >>> on migrating the felix website to a new technology (thanks David for >> taking >>> care of that). >>> >>> So, first, I wonder if I need to do specific things regarding the >>> DependencyManager documentation ? >>> >>> Then, I wonder if I can currently modify the existing DependencyManager >>> documentation ? or if I must wait until all is migrated before modifying >>> anything ? >>> >>> thank you >>> >>> kind regards >>> /pierre >> >>
Re: project doc website migration
Hi Pierre, Thanks for asking! The new site work has taken much longer than I planned, partly to do me and partly due to infra. I’d like to get it set up soon. I have some questions that I’ll try to ask in the next couple of days. What’s your timeline? How extensive are the changes? It would be most convenient for me if you made a PR against the .adoc files in a GitHub “djencks” repo I’ll push later today or tomorrow, or waited till the new site is set up at apache even if not published. This would result in some delay in publishing the changes. You can modify the CMS based site but then I’ll have to port the changes, which is certainly possible but more work for me. David Jencks > On Jun 25, 2021, at 12:12 AM, Pierre De Rop wrote: > > Hi all, > > I did not have time to follow, but I think that David (Jencks) is working > on migrating the felix website to a new technology (thanks David for taking > care of that). > > So, first, I wonder if I need to do specific things regarding the > DependencyManager documentation ? > > Then, I wonder if I can currently modify the existing DependencyManager > documentation ? or if I must wait until all is migrated before modifying > anything ? > > thank you > > kind regards > /pierre
Re: Migration of your project website
I’m waiting on INFRA-21834 <https://issues.apache.org/jira/browse/INFRA-21834>. David Jencks > On Jun 17, 2021, at 6:41 AM, Andrew Wetmore wrote: > > The Jira ticket infra-20635 is supposed to cover progress on migration of > your project website off the Apache CMS and onto some other technology. As > Gavin MacDonald commented on the ticket in April, infra is ready to help > you move forward. The CMS will cease operation this summer, so this is now > a high-priority item. > > We now have an "ASF-Pelican" template and migration process available that > could speed things along. > > Please let me know today where things stand with your website. Information > about the Pelican template is at https://infra.apache.org/asf-pelican.html. > > Thanks! > > Andrew > > > > -- > Andrew Wetmore > Technical Writer-Editor > Infra > *Apache Software Foundation* > andr...@apache.org
Re: Github actions
My understanding is that the queue and quota for GitHub actions is shared across all or almost all of Apache so any project can make the service unavailable for everyone by overloading it, and this frequently happens. GH actions are great but I would investigate this before spending a lot of time on it. IIRC there’s discussion on the builds mailing list. I didn’t use GH actions for the Aries website build because of this. Jenkins is worse documented and somewhat harder to set up but seems to have better sharing behavior, at least reviewed and possibly controlled by infra. David Jencks Sent from my iPhone > On May 15, 2021, at 10:18 PM, Jean-Baptiste Onofre wrote: > > No objection. However, be careful about the number of jobs created on GH > Actions. I know that some projects (Beam) reach max number of allowed jobs on > a period. > I think we won’t have any problem at Felix at we won’t launch bunch of jobs > (per PR/commits/scheduled jobs), but just in case ;) > > Regards > JB > >> Le 15 mai 2021 à 03:00, Raymond Augé a >> écrit : >> >> Would folks be offended if I added github actions and dependabot to some of >> the subprojects? >> >> I personally feel this motivates me to continue making small updates. >> >> -- >> *Raymond Augé* (@rotty3000) >> Senior Software Architect *Liferay, Inc.* (@Liferay) >> OSGi Fellow >
Re: [Discuss] Moving the Converter implementation to OSGi at Eclipse
Some recent experiences have led me to conclude that a project claiming to be open-source does not mean that contributions are welcome or that it’s possible to gain commit karma: at Apache we might be living in a very pleasant bubble. Is there evidence that OSGI at Eclipse in fact does welcome contributions from non-project-members and that it is possible to gain commit karma? I think moving the implementation is a good idea but I’m a little worried. I guess we could always fork it again if problems appear. David Jencks > On May 7, 2021, at 2:18 AM, dav...@apache.org wrote: > > Hi JB, > > Some of the contributors of the Converter at Felix are already committers > at the Eclipse project [5]. > Others can just create PRs for any changes to the > https://github.com/osgi/osgi/ project. As it's an opensource project you > can earn committer karma the usual open-source way. > I have done a quick commit grep and found that of the 200 commits to the > converter there are 13 made by people who are not already committers at the > OSGi project at Eclipse. > > I have also checked with Eclipse around releasing the component. Any fixes > that don't impact the API, i.e. micro-version releases can be done from an > Eclipse project pretty much any time. Fixes that do impact the API would > also need a specification update. > > Best regards, > > David > > [5] https://projects.eclipse.org/projects/technology.osgi/who > > On Thu, 6 May 2021 at 16:23, Jean-Baptiste Onofre wrote: > >> Hi David, >> >> It makes sense and it would be more "consistent" to have a single >> repository. >> >> As Converter is part of the "spec", it makes sense to be located at >> Eclipse. >> >> My only "concern" is about the contributions/contributors on Felix >> Converter. >> Will all Felix committers be able to change/maintain code at Eclipse (the >> code coming from Felix Converter) ? >> >> Regards >> JB >> >>> Le 6 mai 2021 à 17:17, dav...@apache.org a écrit : >>> >>> Hi all, >>> >>> As most would have noticed, OSGi has moved to the Eclipse Foundation [1] >>> and all the future OSGi specification work will happen there [2]. >>> >>> The Converter that's in the Felix codebase is an implementation of the >> OSGi >>> Converter specification [3]. As Converter is a 'util' specification, OSGi >>> also provides an implementation with the API. There could be other >>> implementations as well, this is similar to what is done with Push >> Streams >>> and the Service Tracker. >>> >>> The initial implementation of the Converter Util at OSGi was based on the >>> same codebase as the Converter at Felix. In effect it's a fork. Over time >>> the two forks have started to diverge a little, mostly due to different >>> fixes being applied to both of them. >>> >>> Now that OSGi is an Eclipse project and all of the OSGi technology at >>> Eclipse is developed as ordinary opensource projects with the ASL2 >> license >>> I think it would be good if we could collapse these 2 forks into one >> again. >>> Because the Converter is the implementation shipped by OSGi as part of >> its >>> spec API (into [4]), we can't really remove the implementation from the >>> OSGi codebase. >>> So I would like to discuss removing the Converter from the Felix >> codebase, >>> so that the codebase can live on in a single location which would be: >>> >> https://github.com/osgi/osgi/tree/main/org.osgi.util.converter/src/org/osgi/util/converter >>> >>> Obviously this would mean to consolidate all the bugfixes that went into >>> its Felix codebase into the combined one. >>> Combining the codebases into one would mean that all users get the >> benefit >>> from work done to the implementation by both communities. >>> >>> I hope that the Felix community would be open to this. >>> >>> Best regards, >>> >>> David Bosschaert >>> >>> [1] >>> >> https://newsroom.eclipse.org/news/announcements/osgi-alliance-transfers-governance-osgi-specifications-open-source-software >>> [2] https://projects.eclipse.org/projects/technology.osgi >>> [3] >> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/util.converter.html >>> [4] https://repo1.maven.org/maven2/org/osgi/org.osgi.util.converter/ >> >>
Re: Website migration to Antora
As usual I found a way to express myself ambiguously :-) I meant more “will if be convenient for everyone to avoid making any CMS site updates” :-) Thanks David Jencks > On May 4, 2021, at 12:18 PM, Robert Munteanu wrote: > > Hi, > > On Tue, 2021-05-04 at 11:37 -0700, David Jencks wrote: >> Would it be practical to avoid further updates to the CMS site? > > You can ask infra to make a certain part of a svn tree read-only, with > optional exceptions for certain users. > > Thanks, > Robert >
Website migration to Antora
I’ve figured out how to automate Antora website builds on the Aries website and would like to finish up the Felix site migration in the next few days. The last CMS site update appears to have been in February. Would it be practical to avoid further updates to the CMS site? Thanks David Jencks
Re: Ready to proceed with project website migration
I finally succeeded in getting the proposed Aries website build automated using Jenkins. As noted on infra-20635 I now need a Felix folder in https://ci-builds.apache.org <https://ci-builds.apache.org/> to set up a Jenkins build for Felix. The Aries issue is infra-20633; I’m waiting for community feedback on the Aries Antora-built site before suggesting we switch. Thanks, David Jencks > On Apr 20, 2021, at 6:21 AM, Andrew Wetmore wrote: > > Hi, Felix folks and Daivd in particular. > > In reference to Jira ticket infra-20635, we are ready to move ahead when > you are. Please advise about timing and whether there is something else you > need. > > Is there a ticket for the aries migration, which I gather is at the same > stage? > > a > > -- > Andrew Wetmore > Technical Writer-Editor > Infra > *Apache Software Foundation* > andr...@apache.org
[Website] Docs near subprojects experiment
Currently the docs for the most active subprojects aren’t in the website, since they are READMEs in the individual subprojects. I did an experiment with the SCR subproject to get the same page in both the GitHub README and the (Antora) site. For Antora, the sources need to be in a particular folder structure, under modules//pages/, whereas for the README it should be in the root of the subproject. Unfortunately the best way to satisfy this, with an asciidoc include:: preprocessor instruction, is disabled by GitHub. In my experiment, the maven build copies scr/modules/scr/pages/scr.adoc (the page Antora works with) to src/README.adoc (visible on GitHub). The asciidoc (copied) README.adoc is visible at https://github.com/djencks/felix-dev/tree/adoc-test/scr (since there’s no README.md file GitHub shows README.adoc). The site with the page rendered by Antora is at https://felix-preview.s3-us-west-2.amazonaws.com/documentation/scr/scr.html — Some choices: - Antora source location. It might well make more sense to put the antora tree under src/doc/modules/scr/pages, or docs/modules/scr/pages, but I opted in this experiment to put the pages on the shortest possible path. - Copying method: I used the 3rd party copy-rename-maven-plugin which hasn’t been updated since 2014. This might be a risk. I think the antrun plugin can be configured to do the same. - Multiple pages. IIUC there can only be one README, but some subprojects have extensive documentation. I suggest that for such subprojects, we consider moving the documentation to the subproject and having a short non-copied README.adoc pointing to the website. Is migrating the docs for dead/retired subprojects a good idea? David Jencks
Why do the docs claim a DEPENDENCIES file is needed?
https://felix.apache.org/documentation/development/dependencies-file-template.html claims that each released software archive (what is that? source? compiled? ???) must contain a “DEPENDENCIES” file. Why? The information in it is either useless and misleading for OSGI (if the dependency is not included in the archive) or already required to be in NOTICE or LICENCE (if the dependency is included), which are actual Apache required files. I may have inadvertently started the idea that a DEPENDENCIES file is useful, before I knew about OSGI, by getting maven to generate one, listing the maven dependencies. Can we drop this page and stop this confusing and useless practice? David Jencks
Re: Your project website
I’ve made quite a bit more progress. Most links work, the UI is somewhat customized for Felix, and the nav reflects the directory structure. I think a significant reorganization of the content would be appropriate, to utilize the Antora left hand navigation pane. I suggest everyone look at the preview and think about what a good organization would be. Are all felix subprojects in the same git repo or are some of the newer ones in their own repos? I’m somewhat disturbed that several subprojects are no longer represented in the site, in particular SCR. I thought there was significantly more documentation than is in the current README. Have the optional extensions I wrote been removed? I haven’t really been paying attention. David Jencks > On Sep 1, 2020, at 1:24 PM, David Jencks wrote: > > I’ve made a _little_ progress, I’ve converted the content to asciidoc and > arranged it in Antora structure, made playbook and UI projects, and fixed the > command line errors, and made a global index. I put up a preview at > https://felix-preview.s3-us-west-2.amazonaws.com/documentation/auto-index.html > > <https://felix-preview.s3-us-west-2.amazonaws.com/documentation/auto-index.html>. > > There’s lots more to do. If anyone is interested in looking or helping I can > push my local repos to GitHub or even set up Apache git repos for the > projects and push to them. > > David Jencks > > >> On Aug 30, 2020, at 12:01 PM, David Jencks > <mailto:david.a.jen...@gmail.com>> wrote: >> >> I started on a migration, I’ll post more when I have more. >> >> David Jencks >> >>> On Aug 25, 2020, at 12:09 AM, Karl Pauls >> <mailto:karlpa...@gmail.com>> wrote: >>> >>> That would be great - the location is: >>> >>> http://svn.apache.org/repos/asf/felix/site/ >>> <http://svn.apache.org/repos/asf/felix/site/> >>> >>> regards, >>> >>> Karl >>> >>> On Tue, Aug 25, 2020 at 1:23 AM David Jencks >>> wrote: >>>> >>>> I _might_ be able to do a migration to Antora soon. I’ve been working on >>>> one for Aries. >>>> >>>> IIUC a CMS site is somewhere in svn…. does anyone know the address for the >>>> Felix site? >>>> >>>> David Jencks >>>> >>>>> On Aug 24, 2020, at 1:56 AM, Karl Pauls wrote: >>>>> >>>>> Hi, >>>>> >>>>> coming back to this issue. I did talk briefly (out of band) with Ray >>>>> directly on the Monday after but unfortunately, he had other matters >>>>> to attend to so this got lost a bit. >>>>> >>>>> As far as I understand the situation we have to migrate our site away >>>>> from the deprecated Apache CMS. There are various options but none are >>>>> directly supported in the sense that we wouldn't have to work on our >>>>> content. >>>>> >>>>> That said, it seems like we can use .asf.yml to have our site staged >>>>> and published from our felix-dev git repo and our CGis etc should >>>>> still be supported. What we need to replace is the templating engine. >>>>> We can either switch to something we run ourself like Jbake or the >>>>> Antora proposed by Ray (which would require to convert our markdown to >>>>> asciidoc) or we can try to use Jekyll which is supported by github >>>>> pages directly (AFAIU) and would accept at least some of our existing >>>>> markdown (so some work would need to be done). >>>>> >>>>> Now, I personally don't have (much) time for this - hence, if need be, >>>>> I would try to get some part of our site working with the existing >>>>> templates using .asf.yml and github pages and we could try to get it >>>>> all working eventually. However, if somebody volunteers to move >>>>> everything (to something else or just in general) that would be much >>>>> better. Is somebody willing and has the time to work on this in the >>>>> next week or two? >>>>> >>>>> regards, >>>>> >>>>> Karl >>>>> >>>>> On Sat, Aug 8, 2020 at 12:39 AM David Jencks >>>>> wrote: >>>>>> >>>>>> Converting the Aries website to Antora seems to be fairly easy and >>>>>> quick, most likely I could do much of that that here too. >>>>>> &
Re: Your project website
I’ve made a _little_ progress, I’ve converted the content to asciidoc and arranged it in Antora structure, made playbook and UI projects, and fixed the command line errors, and made a global index. I put up a preview at https://felix-preview.s3-us-west-2.amazonaws.com/documentation/auto-index.html <https://felix-preview.s3-us-west-2.amazonaws.com/documentation/auto-index.html>. There’s lots more to do. If anyone is interested in looking or helping I can push my local repos to GitHub or even set up Apache git repos for the projects and push to them. David Jencks > On Aug 30, 2020, at 12:01 PM, David Jencks wrote: > > I started on a migration, I’ll post more when I have more. > > David Jencks > >> On Aug 25, 2020, at 12:09 AM, Karl Pauls wrote: >> >> That would be great - the location is: >> >> http://svn.apache.org/repos/asf/felix/site/ >> >> regards, >> >> Karl >> >> On Tue, Aug 25, 2020 at 1:23 AM David Jencks >> wrote: >>> >>> I _might_ be able to do a migration to Antora soon. I’ve been working on >>> one for Aries. >>> >>> IIUC a CMS site is somewhere in svn…. does anyone know the address for the >>> Felix site? >>> >>> David Jencks >>> >>>> On Aug 24, 2020, at 1:56 AM, Karl Pauls wrote: >>>> >>>> Hi, >>>> >>>> coming back to this issue. I did talk briefly (out of band) with Ray >>>> directly on the Monday after but unfortunately, he had other matters >>>> to attend to so this got lost a bit. >>>> >>>> As far as I understand the situation we have to migrate our site away >>>> from the deprecated Apache CMS. There are various options but none are >>>> directly supported in the sense that we wouldn't have to work on our >>>> content. >>>> >>>> That said, it seems like we can use .asf.yml to have our site staged >>>> and published from our felix-dev git repo and our CGis etc should >>>> still be supported. What we need to replace is the templating engine. >>>> We can either switch to something we run ourself like Jbake or the >>>> Antora proposed by Ray (which would require to convert our markdown to >>>> asciidoc) or we can try to use Jekyll which is supported by github >>>> pages directly (AFAIU) and would accept at least some of our existing >>>> markdown (so some work would need to be done). >>>> >>>> Now, I personally don't have (much) time for this - hence, if need be, >>>> I would try to get some part of our site working with the existing >>>> templates using .asf.yml and github pages and we could try to get it >>>> all working eventually. However, if somebody volunteers to move >>>> everything (to something else or just in general) that would be much >>>> better. Is somebody willing and has the time to work on this in the >>>> next week or two? >>>> >>>> regards, >>>> >>>> Karl >>>> >>>> On Sat, Aug 8, 2020 at 12:39 AM David Jencks >>>> wrote: >>>>> >>>>> Converting the Aries website to Antora seems to be fairly easy and quick, >>>>> most likely I could do much of that that here too. >>>>> >>>>> David Jencks >>>>> >>>>>> On Aug 6, 2020, at 6:32 AM, Raymond Auge >>>>>> wrote: >>>>>> >>>>>> Hey Karl, >>>>>> >>>>>> The more time passes the less time I will have to do this work, but I'll >>>>>> leave it until you're around. >>>>>> >>>>>> - Ray >>>>>> >>>>>> On Thu, Aug 6, 2020 at 3:43 AM Karl Pauls wrote: >>>>>> >>>>>>> Hi Ray, >>>>>>> >>>>>>> thanks a lot for picking this up! >>>>>>> >>>>>>> I’m mostly offline this week but would like to look at the options as >>>>>>> well. >>>>>>> Can we wait until next week until a decision is made? >>>>>>> >>>>>>> >>>>>>> regards, >>>>>>> >>>>>>> Karl >>>>>>> >>>>>>> On Wednesday, August 5, 2020, Bertrand Delacretaz >>>>>>> >>>>>>> wrote: >>>>>>> >
Re: Your project website
I started on a migration, I’ll post more when I have more. David Jencks > On Aug 25, 2020, at 12:09 AM, Karl Pauls wrote: > > That would be great - the location is: > > http://svn.apache.org/repos/asf/felix/site/ > > regards, > > Karl > > On Tue, Aug 25, 2020 at 1:23 AM David Jencks wrote: >> >> I _might_ be able to do a migration to Antora soon. I’ve been working on >> one for Aries. >> >> IIUC a CMS site is somewhere in svn…. does anyone know the address for the >> Felix site? >> >> David Jencks >> >>> On Aug 24, 2020, at 1:56 AM, Karl Pauls wrote: >>> >>> Hi, >>> >>> coming back to this issue. I did talk briefly (out of band) with Ray >>> directly on the Monday after but unfortunately, he had other matters >>> to attend to so this got lost a bit. >>> >>> As far as I understand the situation we have to migrate our site away >>> from the deprecated Apache CMS. There are various options but none are >>> directly supported in the sense that we wouldn't have to work on our >>> content. >>> >>> That said, it seems like we can use .asf.yml to have our site staged >>> and published from our felix-dev git repo and our CGis etc should >>> still be supported. What we need to replace is the templating engine. >>> We can either switch to something we run ourself like Jbake or the >>> Antora proposed by Ray (which would require to convert our markdown to >>> asciidoc) or we can try to use Jekyll which is supported by github >>> pages directly (AFAIU) and would accept at least some of our existing >>> markdown (so some work would need to be done). >>> >>> Now, I personally don't have (much) time for this - hence, if need be, >>> I would try to get some part of our site working with the existing >>> templates using .asf.yml and github pages and we could try to get it >>> all working eventually. However, if somebody volunteers to move >>> everything (to something else or just in general) that would be much >>> better. Is somebody willing and has the time to work on this in the >>> next week or two? >>> >>> regards, >>> >>> Karl >>> >>> On Sat, Aug 8, 2020 at 12:39 AM David Jencks >>> wrote: >>>> >>>> Converting the Aries website to Antora seems to be fairly easy and quick, >>>> most likely I could do much of that that here too. >>>> >>>> David Jencks >>>> >>>>> On Aug 6, 2020, at 6:32 AM, Raymond Auge >>>>> wrote: >>>>> >>>>> Hey Karl, >>>>> >>>>> The more time passes the less time I will have to do this work, but I'll >>>>> leave it until you're around. >>>>> >>>>> - Ray >>>>> >>>>> On Thu, Aug 6, 2020 at 3:43 AM Karl Pauls wrote: >>>>> >>>>>> Hi Ray, >>>>>> >>>>>> thanks a lot for picking this up! >>>>>> >>>>>> I’m mostly offline this week but would like to look at the options as >>>>>> well. >>>>>> Can we wait until next week until a decision is made? >>>>>> >>>>>> >>>>>> regards, >>>>>> >>>>>> Karl >>>>>> >>>>>> On Wednesday, August 5, 2020, Bertrand Delacretaz >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Tue, Aug 4, 2020 at 6:30 PM Raymond Auge >>>>>>> wrote: >>>>>>>> ...So far the Apache Aries project seems to be leaning toward choosing >>>>>>> Antora >>>>>>>> [1] for choice of static site building tool... >>>>>>> >>>>>>> I'm not really active in Felix so I'll let the PMC or whoever does the >>>>>>> work decide. >>>>>>> >>>>>>> However, as per [2] it looks like Antora supports only Asciidoc as its >>>>>>> input format, whereas the current Felix site content is in Markdown. >>>>>>> >>>>>>> This *might* represent more conversion work - however there are >>>>>>> various flavors of Markdown, so even staying in that format will >>>>>>> require some conversion work as well. For Sling we migrated from the >>>>>>> Apache CMS to Jbake [3] and a number of things required fixing, even >>>>>>> though we used Markdown in both cases. >>>>>>> >>>>>>> -Bertrand >>>>>>> >>>>>>> [1] https://docs.antora.org/antora/2.3/ >>>>>>> [2] https://docs.antora.org/antora/2.3/page/ >>>>>>> [3] https://issues.apache.org/jira/browse/SLING-6955 >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Karl Pauls >>>>>> karlpa...@gmail.com >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>> (@rotty3000) >>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>>>> (@Liferay) >>>> >>> >>> >>> -- >>> Karl Pauls >>> karlpa...@gmail.com >> > > > -- > Karl Pauls > karlpa...@gmail.com
Re: Your project website
I _might_ be able to do a migration to Antora soon. I’ve been working on one for Aries. IIUC a CMS site is somewhere in svn…. does anyone know the address for the Felix site? David Jencks > On Aug 24, 2020, at 1:56 AM, Karl Pauls wrote: > > Hi, > > coming back to this issue. I did talk briefly (out of band) with Ray > directly on the Monday after but unfortunately, he had other matters > to attend to so this got lost a bit. > > As far as I understand the situation we have to migrate our site away > from the deprecated Apache CMS. There are various options but none are > directly supported in the sense that we wouldn't have to work on our > content. > > That said, it seems like we can use .asf.yml to have our site staged > and published from our felix-dev git repo and our CGis etc should > still be supported. What we need to replace is the templating engine. > We can either switch to something we run ourself like Jbake or the > Antora proposed by Ray (which would require to convert our markdown to > asciidoc) or we can try to use Jekyll which is supported by github > pages directly (AFAIU) and would accept at least some of our existing > markdown (so some work would need to be done). > > Now, I personally don't have (much) time for this - hence, if need be, > I would try to get some part of our site working with the existing > templates using .asf.yml and github pages and we could try to get it > all working eventually. However, if somebody volunteers to move > everything (to something else or just in general) that would be much > better. Is somebody willing and has the time to work on this in the > next week or two? > > regards, > > Karl > > On Sat, Aug 8, 2020 at 12:39 AM David Jencks wrote: >> >> Converting the Aries website to Antora seems to be fairly easy and quick, >> most likely I could do much of that that here too. >> >> David Jencks >> >>> On Aug 6, 2020, at 6:32 AM, Raymond Auge >>> wrote: >>> >>> Hey Karl, >>> >>> The more time passes the less time I will have to do this work, but I'll >>> leave it until you're around. >>> >>> - Ray >>> >>> On Thu, Aug 6, 2020 at 3:43 AM Karl Pauls wrote: >>> >>>> Hi Ray, >>>> >>>> thanks a lot for picking this up! >>>> >>>> I’m mostly offline this week but would like to look at the options as well. >>>> Can we wait until next week until a decision is made? >>>> >>>> >>>> regards, >>>> >>>> Karl >>>> >>>> On Wednesday, August 5, 2020, Bertrand Delacretaz >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Tue, Aug 4, 2020 at 6:30 PM Raymond Auge >>>>> wrote: >>>>>> ...So far the Apache Aries project seems to be leaning toward choosing >>>>> Antora >>>>>> [1] for choice of static site building tool... >>>>> >>>>> I'm not really active in Felix so I'll let the PMC or whoever does the >>>>> work decide. >>>>> >>>>> However, as per [2] it looks like Antora supports only Asciidoc as its >>>>> input format, whereas the current Felix site content is in Markdown. >>>>> >>>>> This *might* represent more conversion work - however there are >>>>> various flavors of Markdown, so even staying in that format will >>>>> require some conversion work as well. For Sling we migrated from the >>>>> Apache CMS to Jbake [3] and a number of things required fixing, even >>>>> though we used Markdown in both cases. >>>>> >>>>> -Bertrand >>>>> >>>>> [1] https://docs.antora.org/antora/2.3/ >>>>> [2] https://docs.antora.org/antora/2.3/page/ >>>>> [3] https://issues.apache.org/jira/browse/SLING-6955 >>>>> >>>> >>>> >>>> -- >>>> Karl Pauls >>>> karlpa...@gmail.com >>>> >>> >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> (@rotty3000) >>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>> (@Liferay) >> > > > -- > Karl Pauls > karlpa...@gmail.com
Re: Your project website
Converting the Aries website to Antora seems to be fairly easy and quick, most likely I could do much of that that here too. David Jencks > On Aug 6, 2020, at 6:32 AM, Raymond Auge > wrote: > > Hey Karl, > > The more time passes the less time I will have to do this work, but I'll > leave it until you're around. > > - Ray > > On Thu, Aug 6, 2020 at 3:43 AM Karl Pauls wrote: > >> Hi Ray, >> >> thanks a lot for picking this up! >> >> I’m mostly offline this week but would like to look at the options as well. >> Can we wait until next week until a decision is made? >> >> >> regards, >> >> Karl >> >> On Wednesday, August 5, 2020, Bertrand Delacretaz >> wrote: >> >>> Hi, >>> >>> On Tue, Aug 4, 2020 at 6:30 PM Raymond Auge >>> wrote: >>>> ...So far the Apache Aries project seems to be leaning toward choosing >>> Antora >>>> [1] for choice of static site building tool... >>> >>> I'm not really active in Felix so I'll let the PMC or whoever does the >>> work decide. >>> >>> However, as per [2] it looks like Antora supports only Asciidoc as its >>> input format, whereas the current Felix site content is in Markdown. >>> >>> This *might* represent more conversion work - however there are >>> various flavors of Markdown, so even staying in that format will >>> require some conversion work as well. For Sling we migrated from the >>> Apache CMS to Jbake [3] and a number of things required fixing, even >>> though we used Markdown in both cases. >>> >>> -Bertrand >>> >>> [1] https://docs.antora.org/antora/2.3/ >>> [2] https://docs.antora.org/antora/2.3/page/ >>> [3] https://issues.apache.org/jira/browse/SLING-6955 >>> >> >> >> -- >> Karl Pauls >> karlpa...@gmail.com >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay)
[jira] [Commented] (FELIX-6315) Factory components are eagerly deactivated
[
https://issues.apache.org/jira/browse/FELIX-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169175#comment-17169175
]
David Jencks commented on FELIX-6315:
-
It's been years, but I think I recall thinking the current behavior was silly
but required by the spec. It might be advisable to run the TCK against SCR
with this change to see if there are any hidden problems.
> Factory components are eagerly deactivated
> --
>
> Key: FELIX-6315
> URL: https://issues.apache.org/jira/browse/FELIX-6315
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.20
>Reporter: Robert Varga
>Priority: Major
>
> When a factory component with a services is is created via a call to
> ComponentFactory.newInstance(), it is treated as a delayed component where
> service reference counting is concerned. Specifically, if the resulting
> service undergoes a getService()/ungetService(), the component configuration
> is deactivated because the reference count reaches zero:
> {noformat}
> 2020-07-31T17:48:18,135 | INFO | Blueprint Extender: 3 |
> AbstractAdaptedService | 145 -
> org.opendaylight.mdsal.binding-dom-adapter - 6.0.5.SNAPSHOT | Binding/DOM
> adapter for DataBroker deactivated (0)
> java.lang.Throwable: null
> at
> org.opendaylight.mdsal.binding.dom.adapter.osgi.AbstractAdaptedService.stop(AbstractAdaptedService.java:40)
> [bundleFile:?]
> at
> org.opendaylight.mdsal.binding.dom.adapter.osgi.OSGiDataBroker.deactivate(OSGiDataBroker.java:76)
> [bundleFile:?]
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) ~[?:?]
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?]
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
> at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:242)
> [bundleFile:?]
> at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
> [bundleFile:?]
> at
> org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:678)
> [bundleFile:?]
> at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:524)
> [bundleFile:?]
> at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
> [bundleFile:?]
> at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
> [bundleFile:?]
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:409)
> [bundleFile:?]
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:164)
> [bundleFile:?]
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.ungetService(SingleComponentManager.java:1022)
> [bundleFile:?]
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$2.run(ServiceFactoryUse.java:260)
> [org.eclipse.osgi-3.12.100.jar:?]
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$2.run(ServiceFactoryUse.java:1)
> [org.eclipse.osgi-3.12.100.jar:?]
> at java.security.AccessController.doPrivileged(Native Method) [?:?]
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryUngetService(ServiceFactoryUse.java:258)
> [org.eclipse.osgi-3.12.100.jar:?]
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.ungetService(ServiceFactoryUse.java:160)
> [org.eclipse.osgi-3.12.100.jar:?]
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.ungetService(ServiceConsumer.java:50)
> [org.eclipse.osgi-3.12.100.jar:?]
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.ungetService(ServiceRegistrationImpl.java:593)
> [org.eclipse.osgi-3.12.100.jar:?]
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.ungetService(ServiceRegistry.java:540)
> [org.eclipse.osgi-3.12.100.jar:?]
> at
> org.eclipse.osgi.internal.framework.BundleContextImpl.ungetService(BundleContextImpl.java:666)
> [org.eclipse.osgi-3.12.100.jar:?]
> at
> org.opend
Re: [VOTE] Apache Felix FileInstall 3.6.8 release
IIUC your solution involves not altering the bundle binding of a configuration. It’s been many years, but IIRC it’s now recommended to completely sidestep this bundle binding of configurations by binding to an expression that allows any bundle to access the configuration. I thought it would be useful if fileinstall could (perhaps through configuration) set this expression on all configurations it loads. WDYT? David Jencks > On Jul 17, 2020, at 11:25 PM, Jean-Baptiste Onofre wrote: > > Hi everyone, > > We fixed an important issue in Felix FileInstall introduced in 3.6.6 release: > the configuration are bound to a bundle preventing "global" visibility, > impacting lot of user bundles (SCR, etc). > > Felix FileInstall 3.6.8 fixes that. > > Please, take a look on Release Notes for details. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100=12348457 > > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100=12348457> > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachefelix-1343/ > <https://repository.apache.org/content/repositories/orgapachefelix-1343/> > > Staging Dist: > https://dist.apache.org/repos/dist/dev/felix/fileinstall/3.6.8/ > <https://dist.apache.org/repos/dist/dev/felix/fileinstall/3.6.8/> > > Git Tag: > org.apache.felix.fileinstall-3.6.8 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB
Re: [VOTE] Accept the application metrics bundles contribution
+1 David Jencks > On Apr 30, 2020, at 8:22 AM, Karl Pauls wrote: > > I think the discussion of the "application metrics bundles" contribution > (https://github.com/apache/sling-whiteboard/tree/master/osgi-metrics) > by Robert Munteanu has died down by now. It looks like there is some > interest in the idea and > given that Robert is willing to maintain it we should bring it to a vote. > > This vote is about officially accepting the donation. As this has been > developed in Apache already we don't have to sort out the IP > clearance. > > Please cast your votes: > > [ ] +1 Accept the contribution into Felix > [ ] -1 Do not
Re: Proposal for a microservice blueprint
Inline... > On Apr 12, 2020, at 3:23 PM, Christian Schneider > wrote: > > Hi David, > > actually I did not think about Aries but you are right, it could also fit > there. If the Felix community thinks Aries is the better place I will > propose it there too. > I think for marketing purposes Felix is a lot more known than Aries. > The main purpose I want to achieve is that people consider doing > microservices with OSGi. So I wanted to leverage a well known brand that > people associate with OSGi. > Apart from that the only Aries project I use in my experiments is Aries > JAX-RS whiteboard but I use lots of felix bundles. That seems like a conceptual circular dependency with which I am not entirely comfortable. However, it wouldn’t be blocking for me. > > I agree about the naming. Blueprint was a bad choice. What do you think > about "felix cloud native starter”. Names are hard…. ’native’ to me suggests you will be targeting one (or more) of the nontraditional javas (that I am only vaguely acquainted with from watching the Camel list) such as graalvm or quarkus. (I know so little about this that I could be wrong about what these are). I do think that this initiative is a great idea! Maybe you could start it at GitHub while the location/name/description is hammered out? Thanks, David Jencks > > Christian > > > Am Mo., 13. Apr. 2020 um 00:05 Uhr schrieb David Jencks < > david.a.jen...@gmail.com>: > >> Hi Christian, >> >> I’d like to know why felix is a better location for this than aries. >> >> I also think that you should find a description or name other than >> “blueprint” as that term has unfortunately been taken by the osgi blueprint >> spec. Seeing your subject line I wondered why a blueprint (as in spring >> for osgi) project would fit in felix. >> >> Thanks >> David Jencks >> >>> On Apr 12, 2020, at 2:05 PM, Karl Pauls wrote: >>> >>> Hi Christian, >>> >>> I don't think we are at that point just yet. Given that this is a >>> holiday surrounded weekend for a lot of us (due to the easter break) I >>> would say we should at least give it a couple of more days to see >>> where the discussion is going. >>> >>> That said, I personally would like to see a little bit more about what >>> you had in mind. Is there already some existing body of work or are >>> you planning to create something from scratch? >>> >>> regards, >>> >>> Karl >>> >>> On Sun, Apr 12, 2020 at 9:32 PM Christian Schneider >>> wrote: >>>> >>>> There seems to be some interest in having such a blueprint or even more >>>> than one variant at felix. >>>> >>>> Should I start in felix-dev or use a new repo? >>>> I would prefer a new repo as the code will be a multi module maven >> project. >>>> I propose a repo name "felix-cloud-native-starter". >>>> We could have and have different blueprints (e.g. CDI and DS) inside. >>>> I thought about but disliked to have "blueprint" in the name as people >>>> might confuse it with the blueprint dependency injection. >>>> >>>> Christian >>>> >>>> Am So., 12. Apr. 2020 um 11:58 Uhr schrieb Christian Schneider < >>>> ch...@die-schneider.net>: >>>> >>>>> In recent years we saw a big trend towards micro services and cloud. >>>>> Lately people discovered though that such services are often made too >> fine >>>>> grained. >>>>> The newest trend goes to building bigger micro services on the level of >>>>> domain driven design bounded contexts. >>>>> >>>>> Especially for these services OSGi is a very interesting platform as >> they >>>>> need more internal structure than the more fine grained services. >>>>> Unfortunately it is quite hard to build a cloud native service in OSGi >>>>> from scratch. >>>>> >>>>> So I would like to offer a blueprint for cloud native micro services >>>>> inside the felix community. The goal is to provide all parts of a cloud >>>>> native >>>>> system that are usually needed, like: >>>>> >>>>> * Declarative services as dependency injection >>>>> * Aries Jaxrs Whiteboard for REST >>>>> * Dropwizard metrics exported as Prometheus metrics >>>>> * Swagger >>>>> * Halbrowser >>>>> * Felix healthchecks >>>>> * Configuration using OSGi configurator + Environment variables plugin >>>>> * Logging to console >>>>> * Final application is provided as a runnable jar >>>>> * Example docker build files >>>>> * Example kubernetes yaml >>>>> >>>>> What do you think? >>>>> >>>>> Christian >>>>> >>>>> -- >>>>> -- >>>>> Christian Schneider >>>>> http://www.liquid-reality.de >>>>> >>>>> Computer Scientist >>>>> http://www.adobe.com >>>>> >>>>> >>>> >>>> -- >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> >>>> Computer Scientist >>>> http://www.adobe.com >>> >>> >>> >>> -- >>> Karl Pauls >>> karlpa...@gmail.com >> >> > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com
Re: Proposal for a microservice blueprint
Hi Christian, I’d like to know why felix is a better location for this than aries. I also think that you should find a description or name other than “blueprint” as that term has unfortunately been taken by the osgi blueprint spec. Seeing your subject line I wondered why a blueprint (as in spring for osgi) project would fit in felix. Thanks David Jencks > On Apr 12, 2020, at 2:05 PM, Karl Pauls wrote: > > Hi Christian, > > I don't think we are at that point just yet. Given that this is a > holiday surrounded weekend for a lot of us (due to the easter break) I > would say we should at least give it a couple of more days to see > where the discussion is going. > > That said, I personally would like to see a little bit more about what > you had in mind. Is there already some existing body of work or are > you planning to create something from scratch? > > regards, > > Karl > > On Sun, Apr 12, 2020 at 9:32 PM Christian Schneider > wrote: >> >> There seems to be some interest in having such a blueprint or even more >> than one variant at felix. >> >> Should I start in felix-dev or use a new repo? >> I would prefer a new repo as the code will be a multi module maven project. >> I propose a repo name "felix-cloud-native-starter". >> We could have and have different blueprints (e.g. CDI and DS) inside. >> I thought about but disliked to have "blueprint" in the name as people >> might confuse it with the blueprint dependency injection. >> >> Christian >> >> Am So., 12. Apr. 2020 um 11:58 Uhr schrieb Christian Schneider < >> ch...@die-schneider.net>: >> >>> In recent years we saw a big trend towards micro services and cloud. >>> Lately people discovered though that such services are often made too fine >>> grained. >>> The newest trend goes to building bigger micro services on the level of >>> domain driven design bounded contexts. >>> >>> Especially for these services OSGi is a very interesting platform as they >>> need more internal structure than the more fine grained services. >>> Unfortunately it is quite hard to build a cloud native service in OSGi >>> from scratch. >>> >>> So I would like to offer a blueprint for cloud native micro services >>> inside the felix community. The goal is to provide all parts of a cloud >>> native >>> system that are usually needed, like: >>> >>> * Declarative services as dependency injection >>> * Aries Jaxrs Whiteboard for REST >>> * Dropwizard metrics exported as Prometheus metrics >>> * Swagger >>> * Halbrowser >>> * Felix healthchecks >>> * Configuration using OSGi configurator + Environment variables plugin >>> * Logging to console >>> * Final application is provided as a runnable jar >>> * Example docker build files >>> * Example kubernetes yaml >>> >>> What do you think? >>> >>> Christian >>> >>> -- >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Computer Scientist >>> http://www.adobe.com >>> >>> >> >> -- >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Computer Scientist >> http://www.adobe.com > > > > -- > Karl Pauls > karlpa...@gmail.com
Re: Resolving open issue FELIX-6161
I don’t think anyone should take my opinion as definitive, but when I (briefly) reviewed this some time ago I thought the proposed changes were fine. Since the spec apparently suggests that this “service on demand” scenario should be supported, I think this is a good idea. David Jencks > On Apr 12, 2020, at 3:07 AM, Carsten Ziegeler wrote: > > Hi, > > I agree it would be good to get to a conclusion on this one in one way or the > other. > > @Tom, @David J - WDYT? > > Regards > Carsten > > On 23.03.2020 14:29, GLIMMERVEEN Arnoud wrote: >> Hi all, >> Last July I opened an issue [1] regarding SCR's behaviour with respect to >> tracking services and how it prevents the use of 'Providing service on >> demand pattern' [2]. I also provided a patch that enables this pattern to be >> used in combination with Felix SCR. >> There has been an exchange of comments on the issue, with respect to it >> still supporting the original use-case of the current approach to service >> tracking and whether or not the proposed change could possibly negatively >> affect the performance of SCR. >> To my understanding the patch submitted still supports the original >> use-case. On the performance aspect, there is indeed the overhead of >> additional trackers in case you reference the same service multiple times, >> but I think there is also merit in simplifying the logic within SCR itself, >> by more relying on framework events, rather than doing target matching >> within SCR itself. >> I would like to see if we can get a conclusion for this issue. Of course my >> preference would be to get the proposed changes merged into Felix SCR, but >> if the concerns remain I would like to see what can be done to mitigate >> these. >> Best regards, >> Arnoud Glimmerveen. >> [1] https://issues.apache.org/jira/browse/FELIX-6161 >> [2] >> https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721 >> >> Disclaimer: >> If you are not the intended recipient of this email, please notify the >> sender and >> delete it. >> Any unauthorized copying, disclosure or distribution of this email or its >> attachment(s) is forbidden. >> Thales Nederland BV will not accept liability for any damage caused by this >> email or >> its attachment(s). >> Thales Nederland BV is seated in Hengelo and is registered at the Chamber of >> Commerce under number 06061578. >> > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: Felix on git(box)
+1 I think your plan will be a big improvement for now and allow for further rearrangement if needed. thanks! David Jencks > On Feb 21, 2020, at 8:27 AM, Karl Pauls wrote: > > Hi, > > I know i've been dragging my feet with regard to the migration to git. > Unfortunately, I didn't find the time until now. > > I would like to try to make some progress now and there are a couple > of points to consider namely, > > - our website is currently based on svn and we are using the apache > cms which IIUC doesn't translate directly to the gitbox support. > - with the ip clearance done, Tom would like to have a separate repo > for atomos as there are several submodules in atomos already. > > Hence, I would propose the following: > > We create two git repos called felix-dev and felix-atomos and keep the > current svn for the website. > > That would mean, we move all of the current svn/trunk into the new > felix-dev repo and put a Readme in the svn/trunk instead, pointing to > the two new repositories. That way, the website would still work as > is, the trunk would be in git, and we could give atomos a separate > repo. > > Effectively, that would give us 3 repos on github for now namely, > apache/felix (which is just a Readme pointing to the other two repos), > apache/felix-dev, and apache/felix-atomos. If in the future we want to > move out other parts of the trunk into their own repo we could do so > if we think it makes sense. > > I should be able to get that done next week and I'll start with it on > Tuesday unless somebody really is against it (in other words, I'm > calling for lazy consensus). > > The alternatives I see are to either create a separate repo per module > directly or to convert the current svn to just be the felix repo which > would require to rework the website with asf.yml support and not give > Tom a separate repo for atomos. However, in both cases, we would need > some volunteers as I likely don't have enough time. > > regards, > > Karl > > -- > Karl Pauls > karlpa...@gmail.com
Re: [VOTE] Accept the Atomos contribution
+1 David Jencks > On Jan 29, 2020, at 1:40 PM, Karl Pauls wrote: > > I think the discussion of the "Atomos" contribution > (https://github.com/tjwatson/atomos) by Thomas Watson has died down by > now. It looks like there is quite some interest in the idea and > assuming that the OSGI R8 Core specification will eventually have > something like the "OSGi Connect" proposal as part of the Core > Framework specification we would need something in this direction > anyway. > > We should bring it to a vote. > > This vote is about officially accepting the donation. If the vote is > successful I will follow-up with the incubator to get the IP clearance > sorted out. > > Please cast your votes: > > [ ] +1 Accept the contribution into Felix > [ ] -1 Do not
Re: [VOTE] Move Felix to git(box)
+1 David Jencks > On Nov 19, 2019, at 1:11 AM, Karl Pauls wrote: > > Following up on the discussion about moving Felix to git I'd like to > call for a vote now. > > The idea is to ask Infra to move the current svn to gitbox > (https://gitbox.apache.org) which will give us a two-master setup of > git repositories, allowing committers to utilize two different avenues > of committing code; through GitHub or through the ASF (gitbox) - > including the ability to work with pull requests on github directly. > > Please vote to approve this move: > > [ ] +1 Move source control to gitbox > [ ] 0 Don't care > [ ] -1 Don't, because ...
Re: [Discuss] Another try.. move to git
I’m not exactly active currently, but +1 David Jencks > On Nov 2, 2019, at 5:41 AM, Christian Schneider > wrote: > > I propose we first move the whole repo and then extract projects if people > like this. > It is much easier to do the extraction based on a git project. > > Christian > > Am Sa., 2. Nov. 2019 um 13:21 Uhr schrieb Jean-Baptiste Onofré < > j...@nanthrax.net>: > >> +1 >> >> The question is: do we keep an unique repository for all felix projects >> or we create one git repo per project. >> >> I would prefer to have one dedicated git repo per project >> (felix-framework, felix-configadmin, etc). >> >> Regards >> JB >> >> On 02/11/2019 10:06, Christian Schneider wrote: >>> In the past we discussed a few times about moving felix to git. >>> >>> A while ago we did this step for Aries and it was simpler than >> anticipated. >>> The problem in Aries were the remaining small bundles and subprojects >> that >>> were released by bundle. The larger sub projects were already moved out >> to >>> separate git repos a while ago. >>> >>> So the situation was very similar to felix. In the end we opted for the >>> simple solution of just migrating the full repo to git with the help of >> the >>> infra team. >>> This works quite fine since then. So I propose we do the same for felix. >>> >>> WDYT? >>> >>> Christian >>> >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com
[jira] [Commented] (FELIX-6161) SCR: Method of resolving references limits Service ListenerHook implementations
[ https://issues.apache.org/jira/browse/FELIX-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928232#comment-16928232 ] David Jencks commented on FELIX-6161: - I doubt that will be practical, but I could be wrong. My recollection (vague, it was a long time ago) is that in the actual usage causing the problem, there were several references with the same target filter on the same component, to get the target component and its service property map separately injected. If we were willing to support this scenario, we could register one service listener for each target filter used in the bundle and distribute the event to the several users of the filter. This would be theoretically slightly worse than what I came up with but satisfy your "create service on demand" scenario. Tom, what do you think? > SCR: Method of resolving references limits Service ListenerHook > implementations > --- > > Key: FELIX-6161 > URL: https://issues.apache.org/jira/browse/FELIX-6161 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.1.16 >Reporter: Arnoud Glimmerveen >Priority: Major > Attachments: FELIX-6161.patch > > > When experimenting with creating a Service ListenerHook to realise a > [providing a service on demand > pattern|https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721], > I noticed that references from components managed by Felix SCR were not > showing up as expected: When a reference declares a target filter, that > target filter is not included in the ListenerInfo provided to the > ListenerHook. As a consequence the ListenerHook is unable to create a > matching service. > Source of the observed behaviour is how SCR tracks references, specifically > that it opens a ServiceListener for just the className and performs the > matching of the target filter inside the ServiceListener. This approach > unfortunately hides the target filter from the Service ListenerHook and thus > the Service ListenerHook will have insufficient information to create a > matching service. > Also look at the discussion on the dev mailing list: > [https://www.mail-archive.com/dev@felix.apache.org/msg48657.html] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (FELIX-6161) SCR: Method of resolving references limits Service ListenerHook implementations
[ https://issues.apache.org/jira/browse/FELIX-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885870#comment-16885870 ] David Jencks commented on FELIX-6161: - Our comments crossed... I think that FELIX-4964 results in 2 events when references match different ObjectClasses from a single service. I wonder if there's a way to avoid responding to a 2nd or later event for the same service change, perhaps by checking whether the existing reference is currently the best? This might allow exposing the actual filters to the framework, as Arnold wants, and having only one component cycling in even more cases than at present. > SCR: Method of resolving references limits Service ListenerHook > implementations > --- > > Key: FELIX-6161 > URL: https://issues.apache.org/jira/browse/FELIX-6161 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.1.16 >Reporter: Arnoud Glimmerveen >Priority: Major > Attachments: FELIX-6161.patch > > > When experimenting with creating a Service ListenerHook to realise a > [providing a service on demand > pattern|https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721], > I noticed that references from components managed by Felix SCR were not > showing up as expected: When a reference declares a target filter, that > target filter is not included in the ListenerInfo provided to the > ListenerHook. As a consequence the ListenerHook is unable to create a > matching service. > Source of the observed behaviour is how SCR tracks references, specifically > that it opens a ServiceListener for just the className and performs the > matching of the target filter inside the ServiceListener. This approach > unfortunately hides the target filter from the Service ListenerHook and thus > the Service ListenerHook will have insufficient information to create a > matching service. > Also look at the discussion on the dev mailing list: > [https://www.mail-archive.com/dev@felix.apache.org/msg48657.html] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (FELIX-6161) SCR: Method of resolving references limits Service ListenerHook implementations
[ https://issues.apache.org/jira/browse/FELIX-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885866#comment-16885866 ] David Jencks commented on FELIX-6161: - Rereading FELIX-4964, I see that my "most likely" scenario indeed had references with identical filters, which your patch takes care of. It's still possible for references with different filters to match the same service. Reactivating with different services for the references would be pretty odd; would this actually happen, or does the reactivation recompute all the references? If all references are recomputed, the worst that could happen is the component deactivates/reactivates an extra time for no apparent reason. I don't think there's a solution that will solve all the problems here. I think all the problems are edge cases. Personally, I think that magically making services appear when they are requested (rather than registering services that represent some non-osgi service when requested) is a bit odd and that maintaining simpler SCR behavior is more useful and important. What do others think? > SCR: Method of resolving references limits Service ListenerHook > implementations > --- > > Key: FELIX-6161 > URL: https://issues.apache.org/jira/browse/FELIX-6161 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.1.16 >Reporter: Arnoud Glimmerveen >Priority: Major > Attachments: FELIX-6161.patch > > > When experimenting with creating a Service ListenerHook to realise a > [providing a service on demand > pattern|https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721], > I noticed that references from components managed by Felix SCR were not > showing up as expected: When a reference declares a target filter, that > target filter is not included in the ListenerInfo provided to the > ListenerHook. As a consequence the ListenerHook is unable to create a > matching service. > Source of the observed behaviour is how SCR tracks references, specifically > that it opens a ServiceListener for just the className and performs the > matching of the target filter inside the ServiceListener. This approach > unfortunately hides the target filter from the Service ListenerHook and thus > the Service ListenerHook will have insufficient information to create a > matching service. > Also look at the discussion on the dev mailing list: > [https://www.mail-archive.com/dev@felix.apache.org/msg48657.html] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (FELIX-6161) SCR: Method of resolving references limits Service ListenerHook implementations
[ https://issues.apache.org/jira/browse/FELIX-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885636#comment-16885636 ] David Jencks commented on FELIX-6161: - Looking briefly at your patch from the point of view of FELIX-4964, I think that your patch will produce one service reactivation if all references use the same target filter, but more than one reactivation if the references use different target filters. I doubt that if you have more than one reference to a service from a single component they would have the same filters why would you need more than one? It's more likely that the filters are different but happen to select the same service. Did I understand your patch correctly? Does my thinking make sense? > SCR: Method of resolving references limits Service ListenerHook > implementations > --- > > Key: FELIX-6161 > URL: https://issues.apache.org/jira/browse/FELIX-6161 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.1.16 >Reporter: Arnoud Glimmerveen >Priority: Major > Attachments: FELIX-6161.patch > > > When experimenting with creating a Service ListenerHook to realise a > [providing a service on demand > pattern|https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721], > I noticed that references from components managed by Felix SCR were not > showing up as expected: When a reference declares a target filter, that > target filter is not included in the ListenerInfo provided to the > ListenerHook. As a consequence the ListenerHook is unable to create a > matching service. > Source of the observed behaviour is how SCR tracks references, specifically > that it opens a ServiceListener for just the className and performs the > matching of the target filter inside the ServiceListener. This approach > unfortunately hides the target filter from the Service ListenerHook and thus > the Service ListenerHook will have insufficient information to create a > matching service. > Also look at the discussion on the dev mailing list: > [https://www.mail-archive.com/dev@felix.apache.org/msg48657.html] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: SCR: Question on how component references translate to service 'request' to the service registry
Hi Arnold, I agree your scenario fits into “providing services on demand”; I wasn’t aware of this spec section, and never thought of trying this. I’m still not comfortable with the idea although it seems like something I might be enthusiastically promoting if I had thought of it! Since the spec mentions this possibility, it would be nice if Felix SCR could support it. How important do others think this is? So far I haven’t remembered the details of the problem I was solving by filtering in SCR rather than in the service listener. My first idea to solve this problem is to register a factory configuration for each target filter; I think this is the same as what you propose. I wonder if you could put the code to do this in a ConfigurationListener registered with config admin; of course this assumes that the component with the target filter is configured through config admin. Hope this helps, and thanks for raising this interesting problem. David Jencks > On Jul 14, 2019, at 8:28 AM, Arnoud Glimmerveen > wrote: > > Hi David, > > Thanks for your response and providing some background on the behaviour of > Felix SCR with respect to handling references. I am wondering what you mean > with your remark on mixing logical levels. I thought that my use of the > Service ListenerHook would fall within the parameters of one of the usage > scenarios described in section 55.3.2 (Providing a Service on Demand) [1], or > do you see (other) concerns in my intended use of a Service ListenerHook? > > A different angle I see is to use a Managed Configuration Factory to describe > each instance of the ’ServiceClass’ (with its distinguishing properties) in a > Configuration object and have Felix SCR create service instances from them. > There would be some duplication in this approach, as (some) properties would > need to be both in the Configuration and in the target filter, but I guess > this would work right? > > Best regards, > > Arnoud Glimmerveen > > [1] > https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721 > > >> On 13 Jul 2019, at 23:14, David Jencks wrote: >> >> I certainly intended the behavior when I implemented it. I don’t remember >> the details but I think there is a problem receiving multiple service events >> for the same service for different references in the same bundle so I was >> forced into it. >> >> I think your use of service listener hooks is peculiar and is mixing logical >> levels. Even if you can get it to work I’d advise looking at your problem >> from a different angle to find a different solution. >> >> David Jencks >> >> Sent from my iPhone >> >>> On Jul 13, 2019, at 12:51 PM, Arnoud Glimmerveen >>> wrote: >>> >>> Hi all, >>> >>> I am experimenting with OSGi Framework’ s Service ListenerHook to detect >>> the need for a particular service and based on that need register a service >>> that matches that need. An important aspect for my ListenerHook >>> implementation is the ability to extract properties from the service need, >>> that are then used to initialise a matching service. I’ll try to explain >>> using an example: >>> >>> In my ListenerHook I expect to be notified of a service need as follows: >>> (&(objectClass=ServiceClass)(some.property=5)) >>> >>> Which would allow the ListenerHook to register a service with that >>> property, thus providing a match of the requested service. >>> >>> This appears to work fine when the ‘requesting code’ is either using >>> standard ServiceTracker or Felix’ DependencyManager. However when I have >>> Declarative Services based code requesting the service as follows: >>> >>> @Reference(target = “(some.property=5)”) >>> ServiceClass service; >>> >>> The ListenerHook is unable to construct a matching service, as it only sees >>> a service need for: >>> >>> (objectClass=ServiceClass) >>> >>> And the additional criterion from the target filter is not visible to the >>> ListenerHook. >>> >>> I did some debugging and found that Felix SCR 2.1.16 registers a >>> ServiceListener only for the className of a reference it needs to track. >>> The target filter of the reference (if present) is matched within that >>> ServiceListener and matches are tracked from then on. This behaviour >>> unfortunately prevents my ListenerHook to see the ‘complete picture’ of >>> what is needed and is not able to register a matching service. >>> >>> My question is: is the behaviour of SCR that I observed correct and >>> desired, or have I stumbled on an issue in SCR? >>> >>> Any thoughts and/or insights are greatly appreciated! >>> >>> Best regards, >>> >>> Arnoud Glimmerveen >
Re: SCR: Question on how component references translate to service 'request' to the service registry
I certainly intended the behavior when I implemented it. I don’t remember the details but I think there is a problem receiving multiple service events for the same service for different references in the same bundle so I was forced into it. I think your use of service listener hooks is peculiar and is mixing logical levels. Even if you can get it to work I’d advise looking at your problem from a different angle to find a different solution. David Jencks Sent from my iPhone > On Jul 13, 2019, at 12:51 PM, Arnoud Glimmerveen > wrote: > > Hi all, > > I am experimenting with OSGi Framework’ s Service ListenerHook to detect the > need for a particular service and based on that need register a service that > matches that need. An important aspect for my ListenerHook implementation is > the ability to extract properties from the service need, that are then used > to initialise a matching service. I’ll try to explain using an example: > > In my ListenerHook I expect to be notified of a service need as follows: > (&(objectClass=ServiceClass)(some.property=5)) > > Which would allow the ListenerHook to register a service with that property, > thus providing a match of the requested service. > > This appears to work fine when the ‘requesting code’ is either using standard > ServiceTracker or Felix’ DependencyManager. However when I have Declarative > Services based code requesting the service as follows: > > @Reference(target = “(some.property=5)”) > ServiceClass service; > > The ListenerHook is unable to construct a matching service, as it only sees a > service need for: > > (objectClass=ServiceClass) > > And the additional criterion from the target filter is not visible to the > ListenerHook. > > I did some debugging and found that Felix SCR 2.1.16 registers a > ServiceListener only for the className of a reference it needs to track. The > target filter of the reference (if present) is matched within that > ServiceListener and matches are tracked from then on. This behaviour > unfortunately prevents my ListenerHook to see the ‘complete picture’ of what > is needed and is not able to register a matching service. > > My question is: is the behaviour of SCR that I observed correct and desired, > or have I stumbled on an issue in SCR? > > Any thoughts and/or insights are greatly appreciated! > > Best regards, > > Arnoud Glimmerveen
Re: svn commit: r1862491 - in /felix/trunk/scr/src: main/java/org/apache/felix/scr/impl/ main/java/org/apache/felix/scr/impl/config/ main/java/org/apache/felix/scr/impl/manager/ main/java/org/apache/f
Would it be a good idea to start the serialized metadata file with a version
number so when you discover a better format old format data can be ignored
rather than causing a read error?
How much speedup and size reduction do you get from this binary format compared
to say one json file as the cache?
Thanks
David Jencks
Sent from my iPhone
> On Jul 3, 2019, at 9:35 AM, tjwat...@apache.org wrote:
>
> Author: tjwatson
> Date: Wed Jul 3 16:35:54 2019
> New Revision: 1862491
>
> URL: http://svn.apache.org/viewvc?rev=1862491=rev
> Log:
> FELIX-6155 - Add caching of service component metadata
>
> By default the caching is disabled. The configuration property (or
> framework launch property) ds.cache.metadata can be set to the string
> "true" to enable the support. Unfortunately dynamically setting this
> with config admin is problematic because the cache is read at activation
> time currently. This could be enhanced to read the cache any time the
> value is set to true dynamically. For now it is required to be set from
> the start with a system or framework launch property
>
> Added:
>
> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/metadata/MetadataStoreHelper.java
> Modified:
>felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/Activator.java
>
> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/BundleComponentActivator.java
>
> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/config/ScrConfigurationImpl.java
>
> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/manager/ScrConfiguration.java
>
> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/metadata/ComponentMetadata.java
>
> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/metadata/ReferenceMetadata.java
>
> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/metadata/ServiceMetadata.java
>
> felix/trunk/scr/src/test/java/org/apache/felix/scr/impl/logger/MockScrLogger.java
>
> Modified:
> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/Activator.java
> URL:
> http://svn.apache.org/viewvc/felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/Activator.java?rev=1862491=1862490=1862491=diff
> ==
> --- felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/Activator.java
> (original)
> +++ felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/Activator.java
> Wed Jul 3 16:35:54 2019
> @@ -18,9 +18,24 @@
> */
> package org.apache.felix.scr.impl;
>
> +import java.io.BufferedInputStream;
> +import java.io.BufferedOutputStream;
> +import java.io.DataInputStream;
> +import java.io.DataOutputStream;
> +import java.io.File;
> +import java.io.FileInputStream;
> +import java.io.FileOutputStream;
> +import java.io.IOException;
> +import java.util.ArrayList;
> +import java.util.Collections;
> import java.util.HashMap;
> +import java.util.HashSet;
> import java.util.List;
> import java.util.Map;
> +import java.util.Map.Entry;
> +import java.util.Set;
> +import java.util.concurrent.ConcurrentHashMap;
> +import java.util.concurrent.ConcurrentMap;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.locks.Lock;
> import java.util.concurrent.locks.ReentrantLock;
> @@ -28,9 +43,14 @@ import java.util.concurrent.locks.Reentr
> import org.apache.felix.scr.impl.config.ScrConfigurationImpl;
> import org.apache.felix.scr.impl.inject.ClassUtils;
> import org.apache.felix.scr.impl.logger.ScrLogger;
> +import org.apache.felix.scr.impl.manager.ComponentHolder;
> +import org.apache.felix.scr.impl.metadata.ComponentMetadata;
> +import org.apache.felix.scr.impl.metadata.MetadataStoreHelper.MetaDataReader;
> +import org.apache.felix.scr.impl.metadata.MetadataStoreHelper.MetaDataWriter;
> import org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl;
> import org.osgi.framework.Bundle;
> import org.osgi.framework.BundleContext;
> +import org.osgi.framework.BundleEvent;
> import org.osgi.framework.Constants;
> import org.osgi.framework.ServiceRegistration;
> import org.osgi.framework.wiring.BundleRevision;
> @@ -75,6 +95,8 @@ public class Activator extends AbstractE
>
> private ComponentCommands m_componentCommands;
>
> +private ConcurrentMap>
> m_componentMetadataStore;
> +
> public Activator()
> {
> m_configuration = new ScrConfigurationImpl( this );
> @@ -102,6 +124,8 @@ public class Activator extends AbstractE
>
> public void restart(boolean globalExtender)
> {
> +m_componentMetadataStore = load(m_context, logger,
> +m_configuration.cacheMetadata());
> BundleContext context = m_
Re: Best way to deal with async calls inside a DS activate() method without block?
If I understand, your idea is to basically make this component’s activation synchronous. If this works, it’s likely the simplest solution. In that case, is removing the extra thread an option? Another possibility that may bring its own set of problems is to have this async-startup component not declare any services but to register its services in code at the completion of the async startup. It’s been several years since I dealt with something like this but as I recall it can be difficult to get the async start/shutdown to work reliably while required dependencies are simultaneously coming and going on other threads. Why does this component need to start asynchronously? Thanks David Jencks Sent from my iPhone > On Jun 18, 2019, at 6:56 AM, Cristiano wrote: > > Hello all, > > We have a system where we use Felix Configurator in order to > initiate/activate a set of DeclarativeService bootstrap components (with > configurationPolicy = ConfigurationPolicy.REQUIRE,) as soon as the > container get started. Those components are triggering the activation of > other immediate components that referring them with a > ReferenceCardinality.MANDATORY. > > Now I need to integrate with a tool that provides me an async startup > method and returns a CompletionStage: CompletionStage > startup(Config config). > > I'm in doubt how would be the best way to deal with this kind of async > startup process inside the component's activate() method. I must ensure > that DS will not activate others components before this async tool is > started and also do not prevent that not related components do activate > properly. > > I have not sure yet, but I think that calling > startup().toCompletableFuture().get(), a blocking method, will block the > DS thread and prevent others components from being activated. Also, I > think that if I don't block then DS will consider this bootstrap > component activated and will trigger the activation of other components, > even if the tool's startup do fail later. Am I right? > > could someone please give me some tip? > > thanks and best regards, > > Cristiano > >
[jira] [Closed] (FELIX-6105) [DS] SCR does not add the component bundle location to the Configuration objects
[
https://issues.apache.org/jira/browse/FELIX-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks closed FELIX-6105.
---
> [DS] SCR does not add the component bundle location to the Configuration
> objects
>
>
> Key: FELIX-6105
> URL: https://issues.apache.org/jira/browse/FELIX-6105
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Reporter: Esin Yakub
>Priority: Major
>
> The SCR runtime does not set the bundle location of the configuration
> consuming component to the Configuration object. This is the case in the
> ManagedService-s and makes them more resilient to any external actions.
> With Felix SCR currently if you have a component requiring a configuration
> PID (the component is activated successfully) and you get the configuration
> PID using the ConfigurationAdmin service without specifying "null" for the
> bundle location you will end up sending a
> ConfigurationEvent.CM_LOCATION_CHANGED event which in hand will trigger a
> component destruction.
> Sample service:
> {code:java}
> import org.osgi.service.component.annotations.Activate;
> import org.osgi.service.component.annotations.Component;
> import org.osgi.service.component.annotations.ConfigurationPolicy;
> import org.osgi.service.component.annotations.Deactivate;
> @Component(
> configurationPid = "com.softwareag.dummy.pid",
> configurationPolicy = ConfigurationPolicy.REQUIRE,
> immediate = true)
> public class Dummy{
> @Activate
> public void activate() {
> System.out.println("Dummy is active");
> }
> @Deactivate
> public void deactivate() {
> System.out.println("Dummy is deactivated");
> }
> }
> {code}
> Sample snippet for consumer:
> {code:java}
> ...
> Configuration ssoConf =
> configAdmin.getConfiguration("com.softwareag.dummy.pid");
> System.out.println("Bundle location for the dummy configuration is: " +
> ssoConf.getBundleLocation());
> }
> {code}
> If the bundle location in the configuration is null the second snippet sets
> the bundle location and deactivates the component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (FELIX-6105) [DS] SCR does not add the component bundle location to the Configuration objects
[
https://issues.apache.org/jira/browse/FELIX-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks resolved FELIX-6105.
-
Resolution: Won't Fix
DS used to set the bundle location, however this leads to an unavoidable race
condition, so I changed it to not set the bundle location. Since DS does not
use managed services to obtain the configurations for components, this is spec
compliant. In addition, I believe that it's now recommended practice to set
the bundle location to the multi-location "?" unless you have a very special
case where you need to restrict a configuration to a particular bundle, in
which case your configuration manager should be doing so, not relying on which
bundle happens to pick up the configuration first.
> [DS] SCR does not add the component bundle location to the Configuration
> objects
>
>
> Key: FELIX-6105
> URL: https://issues.apache.org/jira/browse/FELIX-6105
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Reporter: Esin Yakub
>Priority: Major
>
> The SCR runtime does not set the bundle location of the configuration
> consuming component to the Configuration object. This is the case in the
> ManagedService-s and makes them more resilient to any external actions.
> With Felix SCR currently if you have a component requiring a configuration
> PID (the component is activated successfully) and you get the configuration
> PID using the ConfigurationAdmin service without specifying "null" for the
> bundle location you will end up sending a
> ConfigurationEvent.CM_LOCATION_CHANGED event which in hand will trigger a
> component destruction.
> Sample service:
> {code:java}
> import org.osgi.service.component.annotations.Activate;
> import org.osgi.service.component.annotations.Component;
> import org.osgi.service.component.annotations.ConfigurationPolicy;
> import org.osgi.service.component.annotations.Deactivate;
> @Component(
> configurationPid = "com.softwareag.dummy.pid",
> configurationPolicy = ConfigurationPolicy.REQUIRE,
> immediate = true)
> public class Dummy{
> @Activate
> public void activate() {
> System.out.println("Dummy is active");
> }
> @Deactivate
> public void deactivate() {
> System.out.println("Dummy is deactivated");
> }
> }
> {code}
> Sample snippet for consumer:
> {code:java}
> ...
> Configuration ssoConf =
> configAdmin.getConfiguration("com.softwareag.dummy.pid");
> System.out.println("Bundle location for the dummy configuration is: " +
> ssoConf.getBundleLocation());
> }
> {code}
> If the bundle location in the configuration is null the second snippet sets
> the bundle location and deactivates the component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5802) Service Component created via xml defines scope='singleton' and service specifies property with scope='bundle'
[
https://issues.apache.org/jira/browse/FELIX-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793045#comment-16793045
]
David Jencks commented on FELIX-5802:
-
Wow, I've never heard of Gravity before!
I'd be curious to see an example of where a service consumer knowing the
framework or SCR singleton scope of the service is relevant to its' behavior.
> Service Component created via xml defines scope='singleton' and service
> specifies property with scope='bundle'
> --
>
> Key: FELIX-5802
> URL: https://issues.apache.org/jira/browse/FELIX-5802
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.6.10
>Reporter: Matt Pavlovich
>Priority: Major
>
> Component with scope='singleton' created via xml or annotation has the
> service registered with a property of service.scope='bundle'
> Project reproducing the issue is available here:
> [https://github.com/mattrpav/felix-5802]
> Steps to reproduce:
> # Define a serviceComponent via xml (or osgi ds annotation)
> # Deploy bundle
> # run scr:info (observe Service Scope: singleton)
> # run service:list (observe service.scope = bundle)
> Investigation:
> * Service registers with property of 'service.scope=bundle' here:
> [https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/ServiceRegistrationImpl.java#L327]
> * Debugging in felix.scr confirms that the xml is being parsed correctly and
> the returned component metadata shows the 'scope' = 'singleton' correctly
> [o.a.felix.scr.impl.xml.XmlHandler#L362|https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java#L362]
> * Debugging confirms that felix.scr is detecting DS13 namespace
> scr:info output:
> {noformat}
> karaf@root()> scr:info TestModule
> *** Bundle: com.foo.test-module (124)
> Component Description:
> Name: BundleModule
> Implementation Class: com.foo.TestModule
> Default State: enabled
> Activation: immediate
> Configuration Policy: optional
> Activate Method: activate
> Deactivate Method: deactivate
> Modified Method: -
> Configuration Pid: [TestModule]
> Services:
> com.foo.api.Module
> Service Scope: singleton
> Component Description Properties:
> Component Configuration:
> ComponentId: 4
> State: active
> Component Configuration Properties:
> component.id = 4
> component.name = TestModule{noformat}
> service:list output
> {noformat}
> karaf@root()> service:list
> [com.foo.api.Module]
>
> component.id = 4
> component.name = TestModule
> service.bundleid = 124
> service.id = 141
> service.scope = bundle
> Provided by :
> Company :: Foo :: TestModule (124){noformat}
> OSGI-INF/serviceComponent.xml
> {noformat}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="TestModule" immediate="true">
>
>
>
>
> {noformat}
>
> Note: When the same impl class is reconfigured to register as a service via
> BundleActivator, the service has a service.scope = 'singleton'
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5802) Service Component created via xml defines scope='singleton' and service specifies property with scope='bundle'
[
https://issues.apache.org/jira/browse/FELIX-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793014#comment-16793014
]
David Jencks commented on FELIX-5802:
-
Rob-
The meanings of framework-singleton and SCR-singleton are rather different.
framework-singleton means the service implementation object was registered to
the service registry, so it was eagerly created and can't be changed without
unregistering the service first.
SCR-singleton usually means that the service implementation object is created
when the service is first requested and discarded when there are no more uses
of it. There are exceptions for immediate components and at least in felix SCR
for components configured to be never discarded after creation.
This difference in behavior means that using framework-singleton for an
SCR-singleton component is generally wrong.
framework-bundle means that for each bundle requesting the service, the
ServiceFactory is asked for a service implementation object; this object is
cached by the framework per bundle. What the ServiceFactory returns is up to
the ServiceFactory, and the framework doesn't care.
Do you have an actual problem to solve related to having something work the way
you need or are you trying to understand the specs?
> Service Component created via xml defines scope='singleton' and service
> specifies property with scope='bundle'
> --
>
> Key: FELIX-5802
> URL: https://issues.apache.org/jira/browse/FELIX-5802
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.6.10
>Reporter: Matt Pavlovich
>Priority: Major
>
> Component with scope='singleton' created via xml or annotation has the
> service registered with a property of service.scope='bundle'
> Project reproducing the issue is available here:
> [https://github.com/mattrpav/felix-5802]
> Steps to reproduce:
> # Define a serviceComponent via xml (or osgi ds annotation)
> # Deploy bundle
> # run scr:info (observe Service Scope: singleton)
> # run service:list (observe service.scope = bundle)
> Investigation:
> * Service registers with property of 'service.scope=bundle' here:
> [https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/ServiceRegistrationImpl.java#L327]
> * Debugging in felix.scr confirms that the xml is being parsed correctly and
> the returned component metadata shows the 'scope' = 'singleton' correctly
> [o.a.felix.scr.impl.xml.XmlHandler#L362|https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java#L362]
> * Debugging confirms that felix.scr is detecting DS13 namespace
> scr:info output:
> {noformat}
> karaf@root()> scr:info TestModule
> *** Bundle: com.foo.test-module (124)
> Component Description:
> Name: BundleModule
> Implementation Class: com.foo.TestModule
> Default State: enabled
> Activation: immediate
> Configuration Policy: optional
> Activate Method: activate
> Deactivate Method: deactivate
> Modified Method: -
> Configuration Pid: [TestModule]
> Services:
> com.foo.api.Module
> Service Scope: singleton
> Component Description Properties:
> Component Configuration:
> ComponentId: 4
> State: active
> Component Configuration Properties:
> component.id = 4
> component.name = TestModule{noformat}
> service:list output
> {noformat}
> karaf@root()> service:list
> [com.foo.api.Module]
>
> component.id = 4
> component.name = TestModule
> service.bundleid = 124
> service.id = 141
> service.scope = bundle
> Provided by :
> Company :: Foo :: TestModule (124){noformat}
> OSGI-INF/serviceComponent.xml
> {noformat}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="TestModule" immediate="true">
>
>
>
>
> {noformat}
>
> Note: When the same impl class is reconfigured to register as a service via
> BundleActivator, the service has a service.scope = 'singleton'
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5802) Service Component created via xml defines scope='singleton' and service specifies property with scope='bundle'
[
https://issues.apache.org/jira/browse/FELIX-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793000#comment-16793000
]
David Jencks commented on FELIX-5802:
-
In the SCR-xml singleton case, the object returned by the SCR-registered
service factory is customized to always be the same instance. (This ignores the
possible deactivation/discard/recreation/activation cycle for the transitions
between 0 and 1 use of the service)
In further posts, please be completely clear about who the actor is in each
sentence and action; the framework (including the service registry), SCR, or
something else.
> Service Component created via xml defines scope='singleton' and service
> specifies property with scope='bundle'
> --
>
> Key: FELIX-5802
> URL: https://issues.apache.org/jira/browse/FELIX-5802
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.6.10
>Reporter: Matt Pavlovich
>Priority: Major
>
> Component with scope='singleton' created via xml or annotation has the
> service registered with a property of service.scope='bundle'
> Project reproducing the issue is available here:
> [https://github.com/mattrpav/felix-5802]
> Steps to reproduce:
> # Define a serviceComponent via xml (or osgi ds annotation)
> # Deploy bundle
> # run scr:info (observe Service Scope: singleton)
> # run service:list (observe service.scope = bundle)
> Investigation:
> * Service registers with property of 'service.scope=bundle' here:
> [https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/ServiceRegistrationImpl.java#L327]
> * Debugging in felix.scr confirms that the xml is being parsed correctly and
> the returned component metadata shows the 'scope' = 'singleton' correctly
> [o.a.felix.scr.impl.xml.XmlHandler#L362|https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java#L362]
> * Debugging confirms that felix.scr is detecting DS13 namespace
> scr:info output:
> {noformat}
> karaf@root()> scr:info TestModule
> *** Bundle: com.foo.test-module (124)
> Component Description:
> Name: BundleModule
> Implementation Class: com.foo.TestModule
> Default State: enabled
> Activation: immediate
> Configuration Policy: optional
> Activate Method: activate
> Deactivate Method: deactivate
> Modified Method: -
> Configuration Pid: [TestModule]
> Services:
> com.foo.api.Module
> Service Scope: singleton
> Component Description Properties:
> Component Configuration:
> ComponentId: 4
> State: active
> Component Configuration Properties:
> component.id = 4
> component.name = TestModule{noformat}
> service:list output
> {noformat}
> karaf@root()> service:list
> [com.foo.api.Module]
>
> component.id = 4
> component.name = TestModule
> service.bundleid = 124
> service.id = 141
> service.scope = bundle
> Provided by :
> Company :: Foo :: TestModule (124){noformat}
> OSGI-INF/serviceComponent.xml
> {noformat}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="TestModule" immediate="true">
>
>
>
>
> {noformat}
>
> Note: When the same impl class is reconfigured to register as a service via
> BundleActivator, the service has a service.scope = 'singleton'
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5802) Service Component created via xml defines scope='singleton' and service specifies property with scope='bundle'
[
https://issues.apache.org/jira/browse/FELIX-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792973#comment-16792973
]
David Jencks commented on FELIX-5802:
-
I don't understand the point of view of what you wrote, who is doing the
actions?
The framework can only look at what it's handed when setting this flag.
The SCR implementation has to register a ServiceFactory rather than the
implementation object since it is required to only create and set up the
implementation object when the service is requested. However, the
ServiceFactory implementation used by the SCR implementation has a choice
whether to always return the same instance or an instance per bundle; the SCR
configuration xml is used to choose between these alternatives.
> Service Component created via xml defines scope='singleton' and service
> specifies property with scope='bundle'
> --
>
> Key: FELIX-5802
> URL: https://issues.apache.org/jira/browse/FELIX-5802
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.6.10
>Reporter: Matt Pavlovich
>Priority: Major
>
> Component with scope='singleton' created via xml or annotation has the
> service registered with a property of service.scope='bundle'
> Project reproducing the issue is available here:
> [https://github.com/mattrpav/felix-5802]
> Steps to reproduce:
> # Define a serviceComponent via xml (or osgi ds annotation)
> # Deploy bundle
> # run scr:info (observe Service Scope: singleton)
> # run service:list (observe service.scope = bundle)
> Investigation:
> * Service registers with property of 'service.scope=bundle' here:
> [https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/ServiceRegistrationImpl.java#L327]
> * Debugging in felix.scr confirms that the xml is being parsed correctly and
> the returned component metadata shows the 'scope' = 'singleton' correctly
> [o.a.felix.scr.impl.xml.XmlHandler#L362|https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java#L362]
> * Debugging confirms that felix.scr is detecting DS13 namespace
> scr:info output:
> {noformat}
> karaf@root()> scr:info TestModule
> *** Bundle: com.foo.test-module (124)
> Component Description:
> Name: BundleModule
> Implementation Class: com.foo.TestModule
> Default State: enabled
> Activation: immediate
> Configuration Policy: optional
> Activate Method: activate
> Deactivate Method: deactivate
> Modified Method: -
> Configuration Pid: [TestModule]
> Services:
> com.foo.api.Module
> Service Scope: singleton
> Component Description Properties:
> Component Configuration:
> ComponentId: 4
> State: active
> Component Configuration Properties:
> component.id = 4
> component.name = TestModule{noformat}
> service:list output
> {noformat}
> karaf@root()> service:list
> [com.foo.api.Module]
>
> component.id = 4
> component.name = TestModule
> service.bundleid = 124
> service.id = 141
> service.scope = bundle
> Provided by :
> Company :: Foo :: TestModule (124){noformat}
> OSGI-INF/serviceComponent.xml
> {noformat}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="TestModule" immediate="true">
>
>
>
>
> {noformat}
>
> Note: When the same impl class is reconfigured to register as a service via
> BundleActivator, the service has a service.scope = 'singleton'
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: gogo command descriptions as properties
As an alternative to translating the annotations to service properties, would it work to scan the bytecode, perhaps using asm or code from bnd, to extract the annotation content without loading the annotation classes, and perhaps even stop exporting the annotations? Are there problems with this approach? David Jencks Sent from my iPhone > On Feb 17, 2019, at 2:46 PM, Thomas Watson wrote: > > The problem with loading the class at all, even later as a dynamic import, > is then it creates a wire with the go go bundle. That means when go-go is > uninstalled then scr would need to be refreshed. While that should work in > a perfectly executed osgi system, it still would require all service > components to be restarted which is very disruptive. > > Tom > >> On Sun, Feb 17, 2019, 3:05 PM David Jencks > >> That was the problem I left the code base with:-) I think I recall seeing >> one of my failed attempts to solve it removed with a comment that made me >> hope someone had found a way to successfully deal with the situation; >> apparently not. I had thought that if the command class was loaded only >> after the annotations were available then they’d get imported and used, but >> couldn’t figure out a way to make that happen. >> >> A couple of questions about the proposal…. >> >> Is gogo related to an osgi spec? I thought not…. in which case using >> osgi.command.function in the property name is perhaps not appropriate. >> >> How about including the method signature in the property name rather than >> just the method name? I think this would make the properties approach as >> powerful as annotations. How about preprocessing the annotations into >> properties? >> >> In whatever form, I still think this is a good idea… >> >> David Jencks >> >>> On Feb 17, 2019, at 8:37 AM, Thomas Watson wrote: >>> >>> The problem is if scr is not resolved against the optional import for the >>> command package then the annotations are unrecognized by the gogo >> runtime. >>> So if scr is resolved before the gogo bundles are installed we get no >> help. >>> >>> Tom >>> >>> On Sat, Feb 16, 2019, 7:20 PM David Jencks > wrote: >>> >>>> Well, I like this idea. >>>> >>>> To dilute the thread, when I worked on the ds gogo commands, if ds >>>> started before the gogo annotations were available the gogo commands >> worked >>>> but had no “help”. Has anyone succeeded in solving this problem? Is this >>>> the sort of problem you’re proposing to solve here? >>>> >>>> Thanks >>>> David Jencks >>>> >>>> Sent from my iPhone >>>> >>>>> On Feb 16, 2019, at 3:44 PM, Raymond Auge >>>> wrote: >>>>> >>>>> I'll take the resounding silence as everyone holding their breath in >>>>> anticipation. >>>>> >>>>> Thx, >>>>> - Ray >>>>> >>>>> On Wed, Feb 13, 2019 at 9:45 AM Raymond Auge >> >>>>> wrote: >>>>> >>>>>> Hello everyone, >>>>>> >>>>>> A few months ago we discussed a way of describing Gogo Command >> functions >>>>>> without being bound by the gogo APIs (i.e. using the annotations). >>>>>> >>>>>> Recently the issue of being optionally bound to the Gogo runtime API >>>>>> actually caused the Equinox project some issues with their adoption of >>>>>> Felix SCR as its DS implementation. >>>>>> >>>>>> I've personally struggled with the issue at my company as well. >>>>>> >>>>>> In order to aleviate this coupling, Tom Watson and I have a proposal >> to >>>>>> simplify the common case (i.e. NOT as a full replacement for the >>>>>> annotations): >>>>>> >>>>>> The proposal is to support a _fall back to service properties_ for >>>> missing >>>>>> @Descriptor annotation, like so: >>>>>> >>>>>> - @Descriptor on TYPE = service.description >>>>>> - @Descriptor on METHOD = osgi.command.function. >>>>>> - @Descriptor on PARAMETER = osgi.command.function..param.# >>>> (indexed >>>>>> from 0) >>>>>> >>>>>> Note that overloaded methods lead to ambiguity in this model. Our >>>> proposal >>>>>> is NOT to solve that. Rather, if you have such a complex case, use the >>>>>> annotations. >>>>>> >>>>>> Thoughts? Anyone object to making this enhancement? >>>>>> >>>>>> -- >>>>>> *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: gogo command descriptions as properties
That was the problem I left the code base with:-) I think I recall seeing one of my failed attempts to solve it removed with a comment that made me hope someone had found a way to successfully deal with the situation; apparently not. I had thought that if the command class was loaded only after the annotations were available then they’d get imported and used, but couldn’t figure out a way to make that happen. A couple of questions about the proposal…. Is gogo related to an osgi spec? I thought not…. in which case using osgi.command.function in the property name is perhaps not appropriate. How about including the method signature in the property name rather than just the method name? I think this would make the properties approach as powerful as annotations. How about preprocessing the annotations into properties? In whatever form, I still think this is a good idea… David Jencks > On Feb 17, 2019, at 8:37 AM, Thomas Watson wrote: > > The problem is if scr is not resolved against the optional import for the > command package then the annotations are unrecognized by the gogo runtime. > So if scr is resolved before the gogo bundles are installed we get no help. > > Tom > > On Sat, Feb 16, 2019, 7:20 PM David Jencks >> Well, I like this idea. >> >> To dilute the thread, when I worked on the ds gogo commands, if ds >> started before the gogo annotations were available the gogo commands worked >> but had no “help”. Has anyone succeeded in solving this problem? Is this >> the sort of problem you’re proposing to solve here? >> >> Thanks >> David Jencks >> >> Sent from my iPhone >> >>> On Feb 16, 2019, at 3:44 PM, Raymond Auge >> wrote: >>> >>> I'll take the resounding silence as everyone holding their breath in >>> anticipation. >>> >>> Thx, >>> - Ray >>> >>> On Wed, Feb 13, 2019 at 9:45 AM Raymond Auge >>> wrote: >>> >>>> Hello everyone, >>>> >>>> A few months ago we discussed a way of describing Gogo Command functions >>>> without being bound by the gogo APIs (i.e. using the annotations). >>>> >>>> Recently the issue of being optionally bound to the Gogo runtime API >>>> actually caused the Equinox project some issues with their adoption of >>>> Felix SCR as its DS implementation. >>>> >>>> I've personally struggled with the issue at my company as well. >>>> >>>> In order to aleviate this coupling, Tom Watson and I have a proposal to >>>> simplify the common case (i.e. NOT as a full replacement for the >>>> annotations): >>>> >>>> The proposal is to support a _fall back to service properties_ for >> missing >>>> @Descriptor annotation, like so: >>>> >>>> - @Descriptor on TYPE = service.description >>>> - @Descriptor on METHOD = osgi.command.function. >>>> - @Descriptor on PARAMETER = osgi.command.function..param.# >> (indexed >>>> from 0) >>>> >>>> Note that overloaded methods lead to ambiguity in this model. Our >> proposal >>>> is NOT to solve that. Rather, if you have such a complex case, use the >>>> annotations. >>>> >>>> Thoughts? Anyone object to making this enhancement? >>>> >>>> -- >>>> *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: gogo command descriptions as properties
Well, I like this idea. To dilute the thread, when I worked on the ds gogo commands, if ds started before the gogo annotations were available the gogo commands worked but had no “help”. Has anyone succeeded in solving this problem? Is this the sort of problem you’re proposing to solve here? Thanks David Jencks Sent from my iPhone > On Feb 16, 2019, at 3:44 PM, Raymond Auge wrote: > > I'll take the resounding silence as everyone holding their breath in > anticipation. > > Thx, > - Ray > > On Wed, Feb 13, 2019 at 9:45 AM Raymond Auge > wrote: > >> Hello everyone, >> >> A few months ago we discussed a way of describing Gogo Command functions >> without being bound by the gogo APIs (i.e. using the annotations). >> >> Recently the issue of being optionally bound to the Gogo runtime API >> actually caused the Equinox project some issues with their adoption of >> Felix SCR as its DS implementation. >> >> I've personally struggled with the issue at my company as well. >> >> In order to aleviate this coupling, Tom Watson and I have a proposal to >> simplify the common case (i.e. NOT as a full replacement for the >> annotations): >> >> The proposal is to support a _fall back to service properties_ for missing >> @Descriptor annotation, like so: >> >> - @Descriptor on TYPE = service.description >> - @Descriptor on METHOD = osgi.command.function. >> - @Descriptor on PARAMETER = osgi.command.function..param.# (indexed >> from 0) >> >> Note that overloaded methods lead to ambiguity in this model. Our proposal >> is NOT to solve that. Rather, if you have such a complex case, use the >> annotations. >> >> Thoughts? Anyone object to making this enhancement? >> >> -- >> *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)
[jira] [Commented] (FELIX-6050) Get rid of SinglePrototypeRefPair
[ https://issues.apache.org/jira/browse/FELIX-6050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762212#comment-16762212 ] David Jencks commented on FELIX-6050: - The motivation was to provide a simpler quicker code path when there was only the one component with the reference; it leaves out a map and a map lookup. I still think the two versions make some sense but I'm not going to argue. It's not going to make any timing difference unless the component is using the locator strategy repeatedly over and over again; it does make a slight space difference. > Get rid of SinglePrototypeRefPair > - > > Key: FELIX-6050 > URL: https://issues.apache.org/jira/browse/FELIX-6050 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.1.14 >Reporter: Thomas Watson >Assignee: Thomas Watson >Priority: Minor > > The SCR implementation has two classes that keep track of prototype > references from a service component: > org.apache.felix.scr.impl.manager.MultiplePrototypeRefPair > org.apache.felix.scr.impl.manager.SinglePrototypeRefPair > I'm not entirely sure what motivated the need for Multiple vs. Single here. > The Single one gets used if the service component is a singleton service > component. The Multiple one gets used for service components that are bundle > or prototype service components. The Multiple one will key the instances of > the referenced prototype service by the ComponentContextImpl for the > requiring service component. That way if there are multiple instances of the > requiring component each instance (and therefore ComponentContextImpl > insteance) will get a unique instance of the required prototype service. > It appears the thought was that some optimizations could have been realized > for the Singleton case so it has a specialized class separate from Multiple. > But I think this only makes the code hard to understand and I question that > the current state of the code is providing any performance improvement. > I propose we remove the SinglePrototypeRefPair and rename the > MultiplePrototypeRefPair to be simply PrototypeRefPair. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline
[
https://issues.apache.org/jira/browse/FELIX-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16750521#comment-16750521
]
David Jencks commented on FELIX-6034:
-
Apparently Karaf does have an opt-out for this, but since no one will use it
there's something wrong. I suspect it's a global opt-out. Perhaps something
more acceptable to karaf devs/users would be some way of either marking a
feature as opt-out or marking a particular feature requirement optional.
Obviously felix is not the correct place to discuss details, but it seems to
keep coming up here.
> Gogo JLine requirement doesn't allow to embed gogo.jline
>
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
> Issue Type: Bug
> Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case
> of Gogo JLine embedded as a standalone bundle, waiting for commands
> implementation (later on), this requirement doesn't allow to start. That's
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x
> and then, I will have to find a bypass or at least a fake command providing a
> capability.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-6019) Provide a bnd plugin to remove header parameters
[
https://issues.apache.org/jira/browse/FELIX-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739656#comment-16739656
]
David Jencks commented on FELIX-6019:
-
I'm getting more confused. Reading the comments to KARAF-3520 my impression is
that there is universal agreement that karaf's 2015 behavior of failing to
deploy a feature due to unmatched service requirements marked effective:=active
is wrong and that this behavior was changed. However, there's no linked commit
so perhaps nothing actually happened?
If there is a possible interpretation of this karaf issue that supports
mandatory service requirement-capability matching please explain.
The discussion there also suggests an additional workaround, namely adding a
bogus capability that will satisfy service matching to the karat feature
description.
> Provide a bnd plugin to remove header parameters
>
>
> Key: FELIX-6019
> URL: https://issues.apache.org/jira/browse/FELIX-6019
> Project: Felix
> Issue Type: New Feature
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
>
> The plugin removes parameters from bundle headers.
> See bnd issue [#2429|https://github.com/bndtools/bnd/issues/2429] and
> SLING-8178.
> Example instruction (for bnd file):
> {noformat}
> -plugin:\
> org.apache.felix.bnd.plugins.header.RemoveParametersPlugin;\
>
> 'Require-Capability'='osgi.service;filter:="(objectClass=org.osgi.service.event.EventAdmin)";effective:=active,osgi.service;filter:="(objectClass=org.osgi.service.event.EventHandler)";effective:=active;cardinality:=multiple'
> {noformat}
> Initial source:
> https://svn.apache.org/repos/asf/felix/sandbox/olli/org.apache.felix.bnd.plugins/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-6019) Provide a bnd plugin to remove header parameters
[
https://issues.apache.org/jira/browse/FELIX-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16738564#comment-16738564
]
David Jencks commented on FELIX-6019:
-
I think you have created a new concept of optional component supported in none
of osgi, bnd, or karaf features. FWIW although it’s been several years I think
I encountered a similar problem with osgi subsystems and I don’t recall if or
how I solved it. I believe that if you installed your bundles individually into
karaf rather than as a feature you would have no problems. The problem is that
karaf’s feature resolver is insisting on resolving the non-runtime
effective:=active requirements. Generating the requirement is I believe part of
the ds spec so I would not advise arbitrarily removing it except perhaps as a
temporary workaround. I think better choices are:
- modifying your component to not generate the requirement (such as 0..n
reference set to 1..n with mandatory configuration supplied as json/yaml in the
bundle for the configuration)
- satisfying the requirement with a disabled component that won’t bind
- working with karaf to introduce the concept of optional requirement for a
feature.
What I don’t understand is why, AFAICT, you have not considered the third
option.
> Provide a bnd plugin to remove header parameters
>
>
> Key: FELIX-6019
> URL: https://issues.apache.org/jira/browse/FELIX-6019
> Project: Felix
> Issue Type: New Feature
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
>
> The plugin removes parameters from bundle headers.
> See bnd issue [#2429|https://github.com/bndtools/bnd/issues/2429] and
> SLING-8178.
> Example instruction (for bnd file):
> {noformat}
> -plugin:\
> org.apache.felix.bnd.plugins.header.RemoveParametersPlugin;\
>
> 'Require-Capability'='osgi.service;filter:="(objectClass=org.osgi.service.event.EventAdmin)";effective:=active,osgi.service;filter:="(objectClass=org.osgi.service.event.EventHandler)";effective:=active;cardinality:=multiple'
> {noformat}
> Initial source:
> https://svn.apache.org/repos/asf/felix/sandbox/olli/org.apache.felix.bnd.plugins/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-6019) Provide a bnd plugin to remove header parameters
[
https://issues.apache.org/jira/browse/FELIX-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16738511#comment-16738511
]
David Jencks commented on FELIX-6019:
-
IIUC the problem you are actually trying to solve is that you are trying to
deploy something as a karaf feature that doesn’t satisfy the conditions to be
a karaf feature, namely something about a feature not having any unsatisfied
requirements. I don’t recall seeing any discussion at Karaf that their feature
model could be improved. Wouldn’t making karaf work more flexibly be a better
solution than removing accurate information generated by bnd?
> Provide a bnd plugin to remove header parameters
>
>
> Key: FELIX-6019
> URL: https://issues.apache.org/jira/browse/FELIX-6019
> Project: Felix
> Issue Type: New Feature
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
>
> The plugin removes parameters from bundle headers.
> See bnd issue [#2429|https://github.com/bndtools/bnd/issues/2429] and
> SLING-8178.
> Example instruction (for bnd file):
> {noformat}
> -plugin:\
> org.apache.felix.bnd.plugins.header.RemoveParametersPlugin;\
>
> 'Require-Capability'='osgi.service;filter:="(objectClass=org.osgi.service.event.EventAdmin)";effective:=active,osgi.service;filter:="(objectClass=org.osgi.service.event.EventHandler)";effective:=active;cardinality:=multiple'
> {noformat}
> Initial source:
> https://svn.apache.org/repos/asf/felix/sandbox/olli/org.apache.felix.bnd.plugins/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: modelling gogo command descriptions
I think a json or text based approach is essential. It’s been a while but as I recall in DS with annotated commands, I could not find any way to make the information from the annotations available to gogo if DS started before gogo; once the command class was loaded without the gogo annotations there was no way to go back and get the annotations. Perhaps someone has solved this problem since, but any code complexity around this is silly. david jencks > On Oct 21, 2018, at 11:55 PM, Raymond Auge wrote: > > On Mon, Oct 22, 2018 at 8:47 AM Guillaume Nodet <mailto:gno...@apache.org>> wrote: > >> Afaik, gogo supports overriden methods, so you can have multiple methods >> for a single command (for example the "cd" command). >> I'm not sure that adding this metadata to the function name will be very >> easy. >> >> Maybe a possible way would be to have a json file containing the metadata >> in a know location so that the "help" command could load them on demand and >> have them generated by a maven plugin at build time ? >> > > That sounds interesting! It does force gogo into having to fetch the bundle > from the ServiceReference in order to fetch the resources, but I don't > think that's a deal breaker. > > Any other opinions? > > - Ray > > >> >> Le lun. 22 oct. 2018 à 05:59, Raymond Auge a >> écrit : >> >>> Hey all, >>> >>> In a recent conversation with Thomas Watson we touched on moving some >>> commands into their implementation bundles. For instance, log commands >>> should be in the log service impl, etc. >>> >>> However we don't want to lose the @Descriptor & @Parameter features to >>> describe the commands. On the other hand, we should not be coupled to the >>> `org.apache.felix.service.command` package. >>> >>> My first notion was to use Bundle annotations, but obviously those are >> not >>> visible at runtime when the command processor handles the commands. >>> >>> Then I was thinking of encoding the information as either an additional >>> service property on the command service. However the alignment, >>> particularly, with the property `osgi.command.function`, which is an >> array, >>> makes this a little weird. >>> >>> Then I thought maybe we could extend the encoding of >>> `osgi.command.function` to use the OSGi package syntax which would >> continue >>> to make any existing values compatible (since they would be just keys, >>> while allowing for additional "attributes", such as description and >>> parameters to be added. It's certainly not perfect. >>> >>> Anyone have thoughts on ways of encoding this? >>> >>> -- >>> *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) >>> >> >> >> -- >> >> Guillaume Nodet >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile > <http://www.liferay.com/web/raymond.auge/profile>> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com > <http://www.liferay.com/>> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org > <http://osgi.org/>> (@OSGiAlliance)
Re: osgicheck-maven-plugin and checkGreedyReferences()
If you've bothered to set the service ranking, then in theory it matters which one you get :-) I like the default of preferring greedy in order to get reproducible results. Configurable choices would be ok for experts :-) David Jencks > On Sep 25, 2018, at 11:14 PM, Carsten Ziegeler wrote: > > As a general remark: > > I guess all current checks in that plugin are debatable. It currently > contains checks that we found useful. And I think we'll make them > configurable in a future version of the plugin. > > For this specific check, it's there to ensure a reproducible system > regardless of in which order bundles and services are started. Greedy > for single cardinality only matters if you have more than one service > registered for that reference. With greedy you always get the same (with > the highest service ranking). Without greedy you get one of them and > that can vary over time. Now in theory it shouldn't matter which one you > get, in practice it often does. > > Regards > > Carsten > > > David Jencks wrote >> I’m not quite sure exactly what you are asking, and I don’t know what policy >> preference this plugin thinks is a good idea but... >> If a static reference goes away, of course the component instance will get >> deactivated, and if there’s another suitable service available a new >> instance will get activated. This happens with both static and greedy >> policies. With a greedy static reference, these will also trigger instance >> cycling: >> - single cardinality: a better match (service ranking) appearing. >> - multiple cardinality: more matches appearing. >> >> Unless you’ve set the minimum cardinality using config admin to the actual >> number of services, you probably want the greedy behavior for multiple >> cardinality references. The situation for single cardinality is more >> debatable. >> >> David Jencks >> >> >> Sent from my iPhone >> >>> On Sep 25, 2018, at 3:51 PM, Mark Derricutt >>> wrote: >>> >>> Hey all, >>> >>> A question on checkGreedyReferences() in the new osgicheck-maven-plugin, we >>> got a lot of warnings about our static @Reference's needing to be greedy. >>> >>> From the ReferecePolicy.STATIC java doc: >>> >>> If a target service is available to replace the bound service which became >>> unavailable, the component configuration must be reactivated and bound to >>> the replacement service. >>> >>> Would this imply that regardless of the RELUCTANT/GREEDY setting, for a >>> static @Reference I should see the new/updated service - and if so, should >>> the warning only trigger for non static references? >>> >>> Mark >>> >>> "The ease with which a change can be implemented has no relevance at all to >>> whether it is the right change for the (Java) Platform for all time." — >>> Mark Reinhold. >>> >>> Mark Derricutt | Senior Developer >>> Phone: +64 9 302 0515 Fax: +64 9 302 0518 >>> Mobile: +64 21 562 533 Freephone: 0800 SMX SMX (769 769) >>> Twitter: @talios >>> SMX Limited: Level 10, 19 Victoria Street West, Auckland, New Zealand >>> Web: http://smxemail.com >>> >> > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org <mailto:cziege...@apache.org>
Re: osgicheck-maven-plugin and checkGreedyReferences()
I’m not quite sure exactly what you are asking, and I don’t know what policy preference this plugin thinks is a good idea but... If a static reference goes away, of course the component instance will get deactivated, and if there’s another suitable service available a new instance will get activated. This happens with both static and greedy policies. With a greedy static reference, these will also trigger instance cycling: - single cardinality: a better match (service ranking) appearing. - multiple cardinality: more matches appearing. Unless you’ve set the minimum cardinality using config admin to the actual number of services, you probably want the greedy behavior for multiple cardinality references. The situation for single cardinality is more debatable. David Jencks Sent from my iPhone > On Sep 25, 2018, at 3:51 PM, Mark Derricutt > wrote: > > Hey all, > > A question on checkGreedyReferences() in the new osgicheck-maven-plugin, we > got a lot of warnings about our static @Reference's needing to be greedy. > > From the ReferecePolicy.STATIC java doc: > > If a target service is available to replace the bound service which became > unavailable, the component configuration must be reactivated and bound to the > replacement service. > > Would this imply that regardless of the RELUCTANT/GREEDY setting, for a > static @Reference I should see the new/updated service - and if so, should > the warning only trigger for non static references? > > Mark > > "The ease with which a change can be implemented has no relevance at all to > whether it is the right change for the (Java) Platform for all time." — Mark > Reinhold. > > Mark Derricutt | Senior Developer > Phone: +64 9 302 0515 Fax: +64 9 302 0518 > Mobile: +64 21 562 533 Freephone: 0800 SMX SMX (769 769) > Twitter: @talios > SMX Limited: Level 10, 19 Victoria Street West, Auckland, New Zealand > Web: http://smxemail.com >
Re: Session invalidation
I recall running into approximately the same situation years and years ago, although I can’t remember if it was for portlet applications or in Geronimo for ears with multiple wars with servlets that forwarded from one war to another. I think my conclusion was that the servlet spec was just wrong, and that I implemented something similar to what Felix has here. So, I think it’s quite possible that Felix’s solution is the best possible even if there are conflicts with the servlet spec. David Jencks > On Aug 22, 2018, at 7:28 PM, Rob Walker wrote: > > Carsten > > Been pondering this one some more and thrown some notes down below. Caveat to > all of them though: I am not so familiar with the recent Felix codebase in > this area; and my experience of real-world HTTP security definitely has gaps! > > So my take is that some apps (obviously not many as we're the 1st to hit this > in 6 months since the change!) would expected a session invalidate() to > destroy every aspect of that session. All attributes definitely, and also > most would expect the ID to be destroyed and not re-used. I haven't checked > the Servlet or HTTP specs for that last part, maybe it isn’t stated in a > contract anywhere. I could certainly see apps that hold their session > information in some external cache not in attributes getting tripped up with > narrow timing windows where an old session ID comes in again before a cache > is cleared. Bad coding by that app - sure, almost certainly. But also caught > out by non-standard behaviour. > > Of course it sounds like we have just as many if not more HTTP whiteboard > users that would get caught by this changed. I'm not going to argue the > current re-use of IDs is wrong, and that we need to refactor since we risk > breaking things for these users, and that is just as bad. > > So my proposal is (hopefully) a simple one. We add a property that lets users > (like us) tripped up by the wrapper behaviour, have the raw Jetty Session > object returned rather than the wrapper. That way no Felix code gets in the > way of normal Jetty handling for those not using HTTP whiteboard. > > Looking at the code, I think there's a very small number of places this would > change. Obviously getSession() is one. And then in Dispatcher we'd need to do > an instanceof test in dispatch before calling getExpiredSessionContextNames. > And I think again something similar in ServiceController. > > We could of course add a higher level wrapper, but that seems to get > heavyweight. > > One added benefit of the above is it allows use of the normal Jetty > SecureHandler code which does an automatic session invalidate/renew as part > of the auth steps. But this gets torpedoed by the use of the Felix wrapper > due to an (admittedly also nasty) instanceof test in the Jetty code. > > Cheers > > --Rob > > -Original Message- > From: Rob Walker > Sent: 22 August 2018 18:49 > To: Carsten Ziegeler ; dev@felix.apache.org > Subject: RE: Session invalidation > > I didn’t check for that, will take a look. The duplicate ID was what I > noticed, and one of the things tripping me up. > -R > > -Original Message- > From: Carsten Ziegeler [mailto:cziege...@apache.org] > Sent: 22 August 2018 17:59 > To: dev@felix.apache.org; Rob Walker > Subject: Re: Session invalidation > > The new session has the same ID (and I'm not trying to imply that this is > good), but it should be a different session object being empty > > Regards > > Carsten > > > Rob Walker wrote >> What I'm seeing is that I get the same session with the same ID back, >> and it never gets invalidated. I think it has something to do with the >> wrapper not invalidating the delegate. In our local code I've patched >> the wrapper to put the delegate.invalidate() call back, and it seems >> then to be creating a new session for me (or returning null) -R >> >> -Original Message- >> From: Carsten Ziegeler [mailto:cziege...@apache.org] >> Sent: 22 August 2018 17:33 >> To: dev@felix.apache.org; Rob Walker >> Subject: Re: Session invalidation >> >> Hmm, maybe I'm missing something here, so you call >> getSession().invalidate(). This should invalidate this session and clear all >> attributes. >> >> If another request comes in using the same session id, a >> getSession(false) should return null. >> >> A getSession() should return a new session which is empty. >> >> So this should follow the servlet API contract. >> >> Or do you experience different results here? >> >> Regards >> >> Carsten >> >> >>
[jira] [Commented] (FELIX-5844) TargetFilter adds
[
https://issues.apache.org/jira/browse/FELIX-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464978#comment-16464978
]
David Jencks commented on FELIX-5844:
-
The behavior is per spec. Think of the object name as a declared property of
the service that happens to be one of the implemented interfaces (or classes).
Filtering on objectName=null is going to return no services since a service has
to have at least one objectName, and they can't be null.
What are you trying to do? Could you have all the jaxrs resources declare they
implement Object.class.getName()?
> TargetFilter adds
> --
>
> Key: FELIX-5844
> URL: https://issues.apache.org/jira/browse/FELIX-5844
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.0
>Reporter: Stefan Bischof
>Priority: Major
>
> I tryed to get all Services only by filtering the componentpropertys with the
> @Reference Annotation using the target
> But DependencyManager.setTargetFilter(String target, int minimumCardinality)
> add a additional classfilter using the interface
>
> Or is there any other way to get all Services by using the @Referenc
> annotation?
> MyClass.java
> {code:java}
> public static final String resourceFilter = "(&(objectClass=null)(" +
> JaxrsWhiteboardConstants.JAX_RS_RESOURCE
> + "=true))";
> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policy =
> ReferencePolicy.DYNAMIC, target = resourceFilter)
> public void addResource(Object resource) {
> System.out.println("Add R " + resource);
> }
> {code}
>
> bundle.jar/OSGI-INF/org.bipolis.MyClass.xml
> {code:java}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.bipolis.MyClass" immediate="true" activate="activate">
>
> interface="java.lang.Object"
> target="((objectClass=null)(osgi.jaxrs.resource=true))"
> bind="addResource" unbind="removeResource"/>
> {code}
>
> DependencyManager.setTargetFilter -
> {code:java}
> line 2095:
> final StringBuilder classFilterSB = new StringBuilder();
> classFilterSB.append(OBJECTCLASS_CLAUSE);
> classFilterSB.append(m_dependencyMetadata.getInterface());
> classFilterSB.append(')');
> final String classFilterString = classFilterSB.toString();
>
> line 2126:
> initialReferenceFilterSB.append(classFilterString);
> {code}
> ServiceRegistry.getServiceReferences(String, SimpleFilter) line: 254
> uses correctly the empty classname;
> {code:java}
> className :null
> filter SimpleFilter
> :(&(objectClass=java.lang.Object)(&(objectClass=null)(osgi.jaxrs.resource=true))){code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Accept the "Logback integration with OSGi Log 1.4" contribution
+1 David Jencks Sent from my iPhone > On Apr 18, 2018, at 1:44 AM, Karl Pauls <karlpa...@gmail.com> wrote: > > I think the discussion of the "Logback integration with OSGi Log 1.4" > contribution ( https://github.com/rotty3000/osgi.to.logback) by > Raymond Auge has died down by now and we should bring it to a vote. > > This vote is about officially accepting the donation. If the vote is > successful I will follow-up with the incubator to get the ip-clearance > sorted-out. > > Please cast your votes: > > [ ] +1 Accept the contribution into Felix > [ ] -1 Do not
Re: [scr] persistent component disable
Ok, perhaps you didn’t get the point of my proposal, which is that there could be a scr management agent that is in control of enabling whichever components you want; I called this a whiltelist, but it could just as well be defined by “everything except this blacklist”. The point is this agent would handle the persistence, leaving all this complexity out of scr entirely. This would make something like the referenced adobe project work without the components starting first. david jencks > On Mar 26, 2018, at 3:53 PM, Raymond Auge <raymond.a...@liferay.com> wrote: > > In my original request the expression "persistent" was intended to be used > rather loosely, and perhaps I should have really said "configuration" > (which is itself persistent). > > What if the "enabled" flag was configurable (i.e. through configuration > admin)? > What if SCR's own configuration could hold component identifiers who's > value is enabled/disable (say bsn+component.name)? > > > On Mon, Mar 26, 2018 at 5:24 PM, David Jencks <david.a.jen...@gmail.com> > wrote: > >> Imnsho this might be needed only in case of terrible design. > > > Granted! I've come to the point in my career that arguments of "that's > terrible design" are pretty much microcosms of the whole software industry. > > >> If a component is quite standalone I’d expect it to be in its own bundle, >> do can not install the bundle if you don’t like it. > > > If the component is standalone, then there's surely no issue! Just stop the > bundle (which is again persistent). > > >> Otherwise it has some references or dependencies so you can use its >> configuration to set them to nonexistent dependencies. >> > > This makes people look at me strangely when I suggest this approach (almost > every day). I really want to give them a more direct and explicit way to do > it because THIS approach leads to more maintenance issues over time than I > believe a left over disable component configuration every could. > > >> >> This all being said, although I’m still firmly opposed to scr itself >> having a persistence mechanism, I wouldn’t really object to a flag causing >> the initial state of all components to be disabled. An external helper >> service could then enable any whitelisted components at its whim. >> > > Could you imagine an IBM customer getting their shinny new Websphere > Liberty server up and having to individually enable the thousands of > components just so they can turn one off... 8| > > > >>> On Mar 26, 2018, at 2:50 PM, Roy Teeuwen <r...@teeuwen.be> wrote: >>> I too have used a tool more than once to disable a component [1], most >> of the time because built in components of a system you don't have under >> control are doing unexpected behaviour (like throwing nullpointer >> exceptions / errors / ...) and we are not able to solve this unless by >> disabling the component (of which we don't control the source code so we >> can't change the configuration). You then have to get the library owners to >> fix it, which sometimes takes weeks / months to release a hotfix for it. >> What would be so bad about creating something to manage this? >>> >>> [1] https://adobe-consulting-services.github.io/acs-aem- >> commons/features/osgi-disablers/component-disabler/index.html < >> https://adobe-consulting-services.github.io/acs-aem-commons/features/osgi- >> disablers/component-disabler/index.html> >> > > Hear, Hear!!! > > >>> >>> Greets, >>> Roy >>>> On 24 Mar 2018, at 10:36, Carsten Ziegeler <cziege...@apache.org> >> wrote: >> >>> You could also simply repackage the bundle and simply change the >>>> component XML inside. This gives you full control. Can be easily done by >>>> a tool. >> > > This is not a workable solution. What if you don't handle the packaging of > the artifacts? As a system administrator this is like asking to compile the > thing from source. > >>> David Jencks wrote >>>>> Could you describe the behavior you want in a little more detail? >> > > I need to disable an individual component in a bundle which has N > components and I cannot stop the bundle. > > >>>>> Is there a global switch to turn this on, or per bundle, or per >> component? >> > > Maybe? > > Maybe I need to opt in on SCR to say "Oh, btw, here's components that > please don't enable." > > That's what I'm asking anyway. > > >>>>> What happens when
Re: [scr] persistent component disable
Sent from my iPhone Imnsho this might be needed only in case of terrible design. If a component is quite standalone I’d expect it to be in its own bundle, do can not install the bundle if you don’t like it. Otherwise it has some references or dependencies so you can use its configuration to set them to nonexistent dependencies. This all being said, although I’m still firmly opposed to scr itself having a persistence mechanism, I wouldn’t really object to a flag causing the initial state of all components to be disabled. An external helper service could then enable any whitelisted components at its whim. Thanks David Jencks > On Mar 26, 2018, at 2:50 PM, Roy Teeuwen <r...@teeuwen.be> wrote: > > Hey all, > > I too have used a tool more than once to disable a component [1], most of the > time because built in components of a system you don't have under control are > doing unexpected behaviour (like throwing nullpointer exceptions / errors / > ...) and we are not able to solve this unless by disabling the component (of > which we don't control the source code so we can't change the configuration). > You then have to get the library owners to fix it, which sometimes takes > weeks / months to release a hotfix for it. What would be so bad about > creating something to manage this? > > [1] > https://adobe-consulting-services.github.io/acs-aem-commons/features/osgi-disablers/component-disabler/index.html > > <https://adobe-consulting-services.github.io/acs-aem-commons/features/osgi-disablers/component-disabler/index.html> > > Greets, > Roy >> On 24 Mar 2018, at 10:36, Carsten Ziegeler <cziege...@apache.org> wrote: >> >> I tend to agreee, requiring a config is usually the way we solve it. >> >> You could also simply repackage the bundle and simply change the >> component XML inside. This gives you full control. Can be easily done by >> a tool. >> >> Regards >> Carsten >> >> David Jencks wrote >>> Could you describe the behavior you want in a little more detail? >>> Is there a global switch to turn this on, or per bundle, or per component? >>> What happens when you upgrade a bundle to a new version? >>> How do you clear the slate and start over with no persisted enablement info? >>> How do you get a report of the enablement overrides? >>> >>> So far I’m not thrilled with the idea of adding a persistence mechanism to >>> scr, but I haven’t run into the scenarios you mention. I’d think making the >>> components configuration required and dealing with config admin would be a >>> simpler approach. >>> >>> David Jencks >>> Sent from my iPhone >>> >>>> On Mar 23, 2018, at 7:40 AM, Raymond Auge <raymond.a...@liferay.com> wrote: >>>> >>>> Hello All, >>>> >>>> I know this topic has come up many different times. >>>> >>>> I'd like to request support for persistent component state (i.e. >>>> persistently enable/disable) components. >>>> >>>> I've created an issue for it >>>> https://issues.apache.org/jira/browse/FELIX-5817 >>>> >>>> I will also try in the next while to implement it to see what this would >>>> look like. >>>> >>>> Sincerely, >>>> -- >>>> *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) >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org >
Re: [SCR] Dropping the proprietary extensions for the R7 implementation
As I recall, the behavior of all the extensions are available in the R6 version through the use of the ds ext annotations which get compiled into Felix namespace xml attributes by bnd. What exactly are you proposing removing? I don’t think the top level xml namespaces offer much value but I’m not sure the code supporting them is complex enough to worry about. For the most part I think the behaviors of the extensions are fairly useful so I’d be reluctant to remove them. Making an osgi server that uses them not able to upgrade to r7 is a pretty big restriction. David Jencks Sent from my iPhone > On Feb 16, 2018, at 7:45 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > > I would like to simplify the upcoming R7 implementation of Declarative > Services and drop the support for the proprietary extensions. > > Currently the implementation supports two additional namespaces for the > component XML. The oldest one allows to define an updated method before > it became part of the R4.2 release. So this has only been used > temporarily until that release became official. > > Similar, there is a special namespace for the R4.3 release which can be > used to indicate that the components might return additional service > properties from the activate method. This feature has been discussed at > that time in the OSGi expert group and was not rejected. While there > might be some people using this, this is tied to the 4.3 specification. > So as soon as you want to use R5 or R6 features or in the future R7 > features, this proprietary extension is not available to your component. > > My suggestion is we drop these things for the R7 version and simplify > the implementation in some areas. If users want to use those features > the R6 implementation is still there to be used and we can maintain it. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: [GitHub] felix pull request #130: New SCR commands
As I recall (possibly wrongly) there are no ComponentConfigurationDTOs for instances created from a factory component, so a command based on DTOs would have had difficulty displaying info about them. Has this changed in the r7 spec, or, perhaps, is my recollection wrong? David Jencks Sent from my iPhone > On Jan 10, 2018, at 5:47 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > >> On Wed, Jan 10, 2018 at 7:50 AM, Neil Bartlett <njbartl...@gmail.com> wrote: >> >> I don't have much experience with Component Factories. I can try it out... >> if you have a sample bundle that I can test against that would be helpful. >> > > Ok, I can put something simple together. > > I know they are not much used, but since we made an update for these in the > latest DS spec w.r.t. factory configuration defaults I think it starts to > make more sense to include them in any reporting also. > > - Ray > > >> >> Neil >> >> On Wed, Jan 10, 2018 at 12:25 PM, Raymond Auge <raymond.a...@liferay.com> >> wrote: >> >>> +1 >>> >>> I've been meaning for a long time to improve the output. Yours looks very >>> good. >>> >>> Does it support component factory instances? I don't think the original >> one >>> does. >>> >>> - Ray >>> >>>> On Wed, Jan 10, 2018 at 4:40 AM, njbartlett <g...@git.apache.org> wrote: >>>> >>>> GitHub user njbartlett opened a pull request: >>>> >>>>https://github.com/apache/felix/pull/130 >>>> >>>>New SCR commands >>>> >>>>New SCR Commands >>>> >>>> >>>>This is a reimplementation of the `scr:list` and `scr:info` >> commands, >>>> presented in a more compact and accessible way. The proposal is to >>>> implement these commands on the R7 branch only, to be included in SCR >>> 2.1.x. >>>> >>>>Changes include: >>>> >>>>- Support for DS 1.4 failed activation state and failure message. >>>>- Provide information on any service registered by the component, >>>> including service ID and using bundles. >>>>- The `scr:list` and `scr:info` commands simply return DTO objects >> to >>>> the Gogo Shell. These objects are then formatted by an instance of the >>>> `Converter` service. This is more in keeping with the philosophy of >> Gogo, >>>> since it allows others to write commands that produce DTO objects >> without >>>> having to provide their own formatting. >>>>- Support for the legacy Felix Shell is dropped, only Gogo is >>>> supported. >>>> >>>>Example Output >>>>-- >>>> >>>>The following is an example of the output of the new commands: >>>> >>>> >>>>g! scr:list >>>>com.effectiveosgi.rt.aws.s3 in bundle [1] >>>> (com.effectiveosgi.rt.aws:2.0.0.201801100857) enabled, 0 instances. >>>>com.effectiveosgi.rt.aws.impl.S3ObjectConverter in bundle [1] >>>> (com.effectiveosgi.rt.aws:2.0.0.201801100857) enabled, 1 instance. >>>>Id: 0, State:ACTIVE >>>>com.effectiveosgi.ExampleComponent in bundle [6] >>>> (example:1.0.0.201801100858) enabled, 3 instances. >>>>Id: 1, State:ACTIVE, PID(s): [com.effectiveosgi. >>>> ExampleComponent~three] >>>>Id: 2, State:ACTIVE, PID(s): [com.effectiveosgi. >>>> ExampleComponent~two] >>>>Id: 3, State:ACTIVE, PID(s): [com.effectiveosgi. >>>> ExampleComponent~one] >>>>com.effectiveosgi.SampleRunnable in bundle [6] >>>> (example:1.0.0.201801100858) enabled, 1 instance. >>>>Id: 4, State:ACTIVE >>>> >>>>g! scr:info 4 >>>>Component Description: com.effectiveosgi.SampleRunnable >>>>=== >>>>Class: com.effectiveosgi.SampleRunnable >>>>Bundle:6 (example:1.0.0.201801100858) >>>>Enabled: true >>>>Immediate: false >>>>Services: [java.lang.Runnable] >>>>Scope: prototype >>>>Config PID(s): [com.effectiveosgi.SampleRunnable], Policy: >>>
Re: [GitHub] felix pull request #130: New SCR commands
It looks to me as if your patch results in there no longer being an ScrInfo service registered. The people using it might possibly not appreciate its removal. I think you should remove the interface and change the version appropriately to make clear what is going on, or else provide the service. I was never able to figure out how to get the Gogo annotations to work if Gogo was loaded after ds. Have you solved this problem? As I recall the commands were available in Gogo but the help about them was not. Thanks David Jencks Sent from my iPhone > On Jan 10, 2018, at 5:47 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > >> On Wed, Jan 10, 2018 at 7:50 AM, Neil Bartlett <njbartl...@gmail.com> wrote: >> >> I don't have much experience with Component Factories. I can try it out... >> if you have a sample bundle that I can test against that would be helpful. >> > > Ok, I can put something simple together. > > I know they are not much used, but since we made an update for these in the > latest DS spec w.r.t. factory configuration defaults I think it starts to > make more sense to include them in any reporting also. > > - Ray > > >> >> Neil >> >> On Wed, Jan 10, 2018 at 12:25 PM, Raymond Auge <raymond.a...@liferay.com> >> wrote: >> >>> +1 >>> >>> I've been meaning for a long time to improve the output. Yours looks very >>> good. >>> >>> Does it support component factory instances? I don't think the original >> one >>> does. >>> >>> - Ray >>> >>>> On Wed, Jan 10, 2018 at 4:40 AM, njbartlett <g...@git.apache.org> wrote: >>>> >>>> GitHub user njbartlett opened a pull request: >>>> >>>>https://github.com/apache/felix/pull/130 >>>> >>>>New SCR commands >>>> >>>>New SCR Commands >>>> >>>> >>>>This is a reimplementation of the `scr:list` and `scr:info` >> commands, >>>> presented in a more compact and accessible way. The proposal is to >>>> implement these commands on the R7 branch only, to be included in SCR >>> 2.1.x. >>>> >>>>Changes include: >>>> >>>>- Support for DS 1.4 failed activation state and failure message. >>>>- Provide information on any service registered by the component, >>>> including service ID and using bundles. >>>>- The `scr:list` and `scr:info` commands simply return DTO objects >> to >>>> the Gogo Shell. These objects are then formatted by an instance of the >>>> `Converter` service. This is more in keeping with the philosophy of >> Gogo, >>>> since it allows others to write commands that produce DTO objects >> without >>>> having to provide their own formatting. >>>>- Support for the legacy Felix Shell is dropped, only Gogo is >>>> supported. >>>> >>>>Example Output >>>>-- >>>> >>>>The following is an example of the output of the new commands: >>>> >>>> >>>>g! scr:list >>>>com.effectiveosgi.rt.aws.s3 in bundle [1] >>>> (com.effectiveosgi.rt.aws:2.0.0.201801100857) enabled, 0 instances. >>>>com.effectiveosgi.rt.aws.impl.S3ObjectConverter in bundle [1] >>>> (com.effectiveosgi.rt.aws:2.0.0.201801100857) enabled, 1 instance. >>>>Id: 0, State:ACTIVE >>>>com.effectiveosgi.ExampleComponent in bundle [6] >>>> (example:1.0.0.201801100858) enabled, 3 instances. >>>>Id: 1, State:ACTIVE, PID(s): [com.effectiveosgi. >>>> ExampleComponent~three] >>>>Id: 2, State:ACTIVE, PID(s): [com.effectiveosgi. >>>> ExampleComponent~two] >>>>Id: 3, State:ACTIVE, PID(s): [com.effectiveosgi. >>>> ExampleComponent~one] >>>>com.effectiveosgi.SampleRunnable in bundle [6] >>>> (example:1.0.0.201801100858) enabled, 1 instance. >>>>Id: 4, State:ACTIVE >>>> >>>>g! scr:info 4 >>>>Component Description: com.effectiveosgi.SampleRunnable >>>>=== >>>>Class: com.effectiveosgi.SampleRunnable >>>>Bundle:6 (example:1.0.0.201801100858) >>>>Enabled: true >>>&
[jira] [Closed] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed FELIX-5618. --- Resolution: Fixed Fixed in r7 copy with r1803595. I haven't been able to get eclipse to open the r7 branch so I have no idea if there have been related changes that might affect this behavior, but the tests all pass. > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Priority: Blocker > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108097#comment-16108097 ] David Jencks commented on FELIX-5618: - Fixed in trunk r1803592. > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Priority: Blocker > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: Provide-Capability in manifest
I’m getting more and more confused :-( Are the services you’re trying to advertise implemented with DS components? Looking at the bnd code I don’t see how it can be replacing any provide service header parts. Can you explain in detail the scenario that “won’t work”? thanks david jencks > On Jul 14, 2017, at 12:45 PM, David Leangen <o...@leangen.net> wrote: > > >>> On Jul 13, 2017, at 6:23 PM, Mark Derricutt <m...@talios.com> wrote: > >>> Which set of annotations are you using? > >> On Jul 15, 2017, at 4:02 AM, David Jencks <david.a.jen...@gmail.com> wrote: > >> I would be interested to know what the gradle magic is…. > > I am not a deep expert in bnd, but I did a quick investigation. I think that > bnd looks for @Component annotations, so actually is DS-based. So my earlier > statement was misleading: it looks like it has nothing to do with gradle > after all. > > I tried experimenting using the @Provide-Capability header. That could > potentially work. > > Note that this won’t work if you mix with DS components. Instead of adding > classes to the list of objectClass, it added a completely new > “osgi.service;objectClass…” entry. > > > Cheers, > =David >
Re: Provide-Capability in manifest
That would only be relevant if David has a DS component. DS itself is not a DS component and although I haven’t looked I rather doubt the converter service is either. I don’t know if there’s going to be a more focussed non-DS annotation for this in R7. There might be a bnd annotation. I would be interested to know what the gradle magic is…. thanks david jencks > On Jul 13, 2017, at 6:23 PM, Mark Derricutt <m...@talios.com> wrote: > > On 14 Jul 2017, at 10:53, David Leangen wrote: > > Working with gradle, these headers are generated automagically, but I’m not > sure what the magic is behind it. > > For me, with the bundle-maven-plugin - using the newer org.osgi annotations > will generate those entries, but using the felix scr annotations doesn't. > > Which set of annotations are you using? > > "The ease with which a change can be implemented has no relevance at all to > whether it is the right change for the (Java) Platform for all time." — Mark > Reinhold. > > Mark Derricutt > http://www.theoryinpractice.net <http://www.theoryinpractice.net/> > http://www.chaliceofblood.net <http://www.chaliceofblood.net/> > http://plus.google.com/+MarkDerricutt <http://plus.google.com/+MarkDerricutt> > http://twitter.com/talios <http://twitter.com/talios> > http://facebook.com/mderricutt <http://facebook.com/mderricutt>
Re: Provide-Capability in manifest
I wrote it manually (in a bnd.bnd file) for DS. If Peter has thought up some way of generating this since then you are more likely to find out about it asking on the bnd list. david jencks > On Jul 11, 2017, at 5:06 AM, David Leangen <o...@leangen.net> wrote: > > Hi! > > Without having to write it in manually, how can I change the pom to get the > Converter projects to output the Provide-Capability manifest headers > (particularly for the osgi.servic;objectClass…)? > > Currently, they are not being generated by the maven-bundle-plugin (v3.2.0). > > > Cheers, > =David >
Re: memory visibility of @Reference service references
I don’t understand your example or I don’t understand how your example relates to an osgi or ds problem. I think you are proposing that the DS component is an http server and starts threads etc. If so, it’s that components responsibility to make sure its’ internal operations are thread safe, and this has little to do with osgi or ds. If you are asking about osgi, for instance if the component exposes HttpServlet and is registered with the whiteboard http service and receives calls from it, then the whiteboard had to call getService to get the DS component instance. In this case I think that there are plenty of synchronization barriers in the service registry and in e.g. SingleComponentManager.getService to assure that the view a request thread has of the component is the same as the view the activation thread had. I could be wrong about whether there are actually enough synchronization barriers. Have you looked at the code to see? thanks david jencks > On May 2, 2017, at 10:45 AM, Dirk Hogan <dirk.ho...@forgerock.com> wrote: > > Hi Raymond- > Assume Felix does it's thing: sets all @References, activates all > components, publishes all services. It has resolved all dependencies, and > set references accordingly. > > Thus, in the example above, myOSGiComponent has its @Reference to > SomeOtherOSGiService resolved - Felix has set this reference. At the > conclusion of the activate method, myOSGiComponent has exposed some > functionality via http, even successfully dereferenced myOSGiComponent, and > now requests start to come it, serviced by the http-server's thread-pool. > Part of servicing this request involves dereferencing (reading) the > @Reference myServiceReference, which, I agree has been set (written) by a > Felix thread. > > The point of the Java Memory Model is that memory state, including > references, read and written across threads, do not have to have > determinate state, unless there is a Synchronization Action which ensures > that the state written by thread A is visible to any other thread - a > volatile reference provides such a Synchronization Action. So code in > myOSGiComponent activate method can successfully dereference the > SomeOtherOSGiService reference, because the same thread which set the > reference is calling activate. But this does NOT mean that another thread, > reading the SAME reference, will see a properly initialized reference. > > Again, this should be self-evident, and the various rules of the JMM model > are defined in section 17.4 of the Java Language Specification. If it is > not clear, then an understanding if the JMM is required. This understanding > can be gained by reading the JLS, reading the links above, the chapter > in *Concurrency > in Practice* on the JMM, or http://gee.cs.oswego.edu/dl/cpj/jmm.html > provides a good intro. > > The bottom line: memory state, including references, shared among multiple > threads can have indeterminate state when written/read, unless explicit > steps, defined in the JMM, are taken to ensure this visibility and thus > coherent state. This is not an opinion. > > Thanks > > Dirk > > > > On Tue, May 2, 2017 at 10:23 AM, Raymond Auge <raymond.a...@liferay.com> > wrote: > >> On Tue, May 2, 2017 at 1:18 PM, Raymond Auge <raymond.a...@liferay.com> >> wrote: >> >>> >>> >>> On Tue, May 2, 2017 at 1:14 PM, Raymond Auge <raymond.a...@liferay.com> >>> wrote: >>> >>>> >>>> On Tue, May 2, 2017 at 11:46 AM, Dirk Hogan <dirk.ho...@forgerock.com> >>>> wrote: >>>> >>>>> But no similar guarantee applies when another thread hits the >>>>> component, >>>>> >>>> >>>> I believe the discussion boils down to why you believe the above is >>>> possible? >>>> >>>> If SCR has not yet made the component available to other threads (which, >>>> to my knowledge, it only does by registering it as a service to the >> service >>>> registry) how can _another_ thread access the component at all? >>>> >>>> I don't even see a way for components within the same DS bundle to >>>> interact with each other other than via the service registry because >>>> @Reference only works through the registry. >>>> >>> >>> Correction, components could interact with each other via the >>> ComponentContext.. but I guess we'd have to know if that's part of your >> use >>> case. >>> >> >> Actually, no, it's not even possible via the ComponentContext. It only >> allows access to Services. >> >
Re: memory visibility of @Reference service references
Step 5 happens before step 1.
I’m not sure that java by itself has sufficient synchronization to assure that
a requesting thread gets the fully correct memory set up by thread T1. However
I Think that with the synchronization in Felix DS requesting threads will get
correct information.
thanks
david jencks
> On Apr 28, 2017, at 1:13 AM, Julian Sedding <jsedd...@gmail.com> wrote:
>
> My theory is as follows:
>
> 1. DS creates a new instances of the service S1 in thread T1
> 2. DS injects the (static) @Reference service in thread T1
> 3. DS calls activate() in thread T1
> 4. at this time no other thread has a reference to service S1
> 5. DS publishes the service in the OSGi service registry
> 6. at this time other thread can get a fully initialized reference to service
> S1
>
> I believe that because up to 4. the reference to S1 is "private" to
> thread T1. In 5. S1 is "published" and thus first allowed to cross a
> thread boundary (I assume Java internally creates some sort of copy of
> S1's memory for a new thread T2). However, at that point S1 is fully
> initialized and immutable. Should the static @Reference on S1 change,
> it is deactivated and a new instance S1' is created, activated and
> registered.
>
> In contrast, with a dynamic @Reference, the field's value may change
> after it is published. Thus it needs to be volatile.
>
> As I said, this is a theory ;) I have no references to back me up.
>
> Regards
> Julian
>
>
> On Thu, Apr 27, 2017 at 7:06 PM, David Jencks <david.a.jen...@gmail.com>
> wrote:
>> My theory about why this is ok is as follows, perhaps you can see something
>> wrong with it.
>>
>> Felix DS has some synchronization after activate is called, therefore the
>> state of the static reference is definitely written to memory. This
>> reference field won’t change after that, since it’s (SCR) static.
>> Any getService call on the service reference also has sufficient
>> synchronization that it happens after the above write. Therefore any other
>> thread which obtained the referenced service will get an object with the
>> correct field value. Therefore any access to this possibly cached object by
>> any thread will have the correct value.
>>
>> thanks
>>
>> david jencks
>>
>>> On Apr 27, 2017, at 9:33 AM, Dirk Hogan <dirk.ho...@forgerock.com> wrote:
>>>
>>> I have been puzzled about the visibility of references written/read across
>>> threads in Felix.
>>>
>>> Scenario:
>>>
>>> public class myOSGiComponent {
>>>
>>> @Reference
>>>
>>> SomeOtherOSGiService myServiceReference;
>>>
>>> public void activate(ComponentContext cc) {
>>>
>>> // myServiceReference will be set - use it to initialize other
>>> dependencies, etc
>>>
>>> }
>>>
>>> public void clientRequestViaEmbeddedJetty() {
>>>
>>> myServiceReference.foo();
>>>
>>> }
>>>
>>> The bottom line is that a STATIC reference does not have to be volatile. I
>>> can see that the write to myServiceReference is guaranteed to be visible in
>>> the activate method, provided that same Felix thread which set
>>> myServiceReference invokes activate, and thus the visibility is guaranteed
>>> by program order (17.4.3 of the Java Language Spec).
>>>
>>> However, in the absence of the synchronization action provided by e.g. a
>>> volatile @Reference declaration, I do not see how Felix can provide a Java
>>> Memory Model compliant guarantee that myServiceReference will be visible in
>>> clientRequestViaEmbeddedJetty, as the thread which set the reference, and
>>> the thread which invokes clientRequestViaEmbeddedJetty, will be distinct.
>>> In the absence of a volatile @Reference declaration, there is no
>>> synchronization action (17.4.2 of JLS) which would guarantee that the
>>> reference write is visible to the reference read, as they are being
>>> performed by distinct threads.
>>>
>>> Perhaps an explanation as to why a DYNAMIC @Reference does need to be
>>> volatile would be helpful - e.g. why does component
>>> de-activation/re-activation provide memory visibility guarantees for STATIC
>>> references?
>>>
>>>
>>> Thanks
>>>
>>>
>>> Dirk
>>
Re: memory visibility of @Reference service references
My theory about why this is ok is as follows, perhaps you can see something
wrong with it.
Felix DS has some synchronization after activate is called, therefore the state
of the static reference is definitely written to memory. This reference field
won’t change after that, since it’s (SCR) static.
Any getService call on the service reference also has sufficient
synchronization that it happens after the above write. Therefore any other
thread which obtained the referenced service will get an object with the
correct field value. Therefore any access to this possibly cached object by
any thread will have the correct value.
thanks
david jencks
> On Apr 27, 2017, at 9:33 AM, Dirk Hogan <dirk.ho...@forgerock.com> wrote:
>
> I have been puzzled about the visibility of references written/read across
> threads in Felix.
>
> Scenario:
>
> public class myOSGiComponent {
>
> @Reference
>
> SomeOtherOSGiService myServiceReference;
>
> public void activate(ComponentContext cc) {
>
> // myServiceReference will be set - use it to initialize other
> dependencies, etc
>
> }
>
> public void clientRequestViaEmbeddedJetty() {
>
> myServiceReference.foo();
>
> }
>
> The bottom line is that a STATIC reference does not have to be volatile. I
> can see that the write to myServiceReference is guaranteed to be visible in
> the activate method, provided that same Felix thread which set
> myServiceReference invokes activate, and thus the visibility is guaranteed
> by program order (17.4.3 of the Java Language Spec).
>
> However, in the absence of the synchronization action provided by e.g. a
> volatile @Reference declaration, I do not see how Felix can provide a Java
> Memory Model compliant guarantee that myServiceReference will be visible in
> clientRequestViaEmbeddedJetty, as the thread which set the reference, and
> the thread which invokes clientRequestViaEmbeddedJetty, will be distinct.
> In the absence of a volatile @Reference declaration, there is no
> synchronization action (17.4.2 of JLS) which would guarantee that the
> reference write is visible to the reference read, as they are being
> performed by distinct threads.
>
> Perhaps an explanation as to why a DYNAMIC @Reference does need to be
> volatile would be helpful - e.g. why does component
> de-activation/re-activation provide memory visibility guarantees for STATIC
> references?
>
>
> Thanks
>
>
> Dirk
[jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983797#comment-15983797 ] David Jencks commented on FELIX-5618: - I'm proposing this solution: https://github.com/djencks/felix/commit/764c6636cef9d02dbb869ec6e29f1754d43700da This is after a proposed code reformat. I might be able to figure out how to apply the change to current trunk instead if necessary. > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Priority: Blocker > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Re: DS code formatting
I’ve investigated further. I think that at some point I must have modified the imported felix eclipse template. However, - the template is out of date, there are a lot of new language features with formatting settings. - the template doesn’t match the scr code very well. I’ve pushed a couple branches to GitHub: commit https://github.com/djencks/felix/commit/bbc1bcff31c0d375701dc8ef7a8c0d2c51a958b3 is the result of reformatting scr with a freshly imported v11 template. There seem to me to be an unreasonable number of changes. commit https://github.com/djencks/felix/commit/2724700da4699c1428e8779e7e35a08a4622f368 is the result of reformatting scr with a proposed updated template. Exporting the v11 template and the proposed v12 template, sorting, and diffing I get MacBook-Pro-2:felix david$ diff template-11-exported-s.xml template-12-a-exported-s.xml 158,159c158,159 < < --- > id="org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_cast" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_catch" > value="insert"/> 162,163c162,163 < < --- > id="org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_for" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_if" > value="insert"/> 165,170c165,170 < < < < < < --- > id="org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_method_invocation" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_parenthesized_expression" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_switch" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_synchronized" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_try" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_while" > value="insert"/> 189,190c189,190 < < --- > id="org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_cast" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_catch" > value="insert"/> 193,194c193,194 < < --- > id="org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_for" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_if" > value="insert"/> 196,201c196,201 < < < < < < --- > id="org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_method_invocation" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_parenthesized_expression" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_switch" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_synchronized" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_try" > value="insert"/> > id="org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_while" > value="insert"/> 283c283 < --- > I think it’s a bit odd that constructor and method declarations don’t have spaces (Type var) whereas invocations do ( new Foo( x ) ) There is a lot of inconsistency in the code but I think there are more uses without spaces than with at the moment. I’d prefer they all have spaces. I’d suggest that whether or not we adopt my proposed changes we should: - put the template in source control so we can track changes to it - sort it so diffs make sense. If anyone thinks proceeding is a good idea I’ll open an issue and attach the two sorted updated templates. thanks david jencks > On Apr 25, 2017, at 2:51 PM, Thomas Watson <tjw...@gmail.com> wrote: > > I much prefer we use the eclipse formatting template. I have that template > setup for my workspace that I use for felix. I have also noticed the code > gets formatted on save. Looking at my workspace settings it does seem this > is enabled to format the code on save. I am unsure if I set that myself or > of the act of importing the formatting template did it. > > Tom. > > On Tue, Apr 25, 2017 at 11:09 AM, David Jencks <david.a.jen...@gmail.com> > wr
Re: [VOTE] Release Apache Felix SCR 2.0.10
> On Apr 25, 2017, at 9:24 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > > David Jencks wrote >> Maybe I missed it, but in the future could you announce that you plan a >> release? I would have liked to get FELIX-5618 >> <https://issues.apache.org/jira/browse/FELIX-5618> and the warning for >> FELIX-5621 <https://issues.apache.org/jira/browse/FELIX-5621> in. >> > Sure, sorry for that. > > But I'm happy to cut another release right after you have the fixes in. > When will that be? > Hopefully shortly after we decide what our code formatting policy actually is :-) However I can’t make any promises…. thanks david jencks > Carsten > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: DS code formatting
Hi Christian, Felix has such an eclipse fomatting template, apparently my problem is that I tried to use it. Perhaps it should be put in a more accessible place? I think we should either use it or remove it, I’m a bit in favor of using it. at the end of http://felix.apache.org/documentation/development/coding-standards.html there is a link to a template at https://issues.apache.org/jira/secure/attachment/12419890/Apache+Felix+Eclipse+Template.xml which is the one I’ve been using. There’s also https://issues.apache.org/jira/browse/FELIX-1406 which has two attachments…. https://issues.apache.org/jira/secure/attachment/12419862/ApacheFelixEclipseTemplate.xml https://issues.apache.org/jira/secure/attachment/12419890/Apache%20Felix%20Eclipse%20Template.xml (this is the one linked from the coding-standards page) Reading the comments and checking links, I think that this issue has resulted in the current target of the coding-standards page link being the 2nd attachment to the issue. thanks david jencks > On Apr 24, 2017, at 11:43 PM, Christian Schneider <ch...@die-schneider.net> > wrote: > > Hi David, > > this might be an eclipse config. > Open preferences and go to Java / Editor / Save Actions. > There you can select to format the code on save of a file. > Maybe this option is switched on for you. > > That said I think it would make sense to have a common formatter for the > code. In CXF we have checkstyle checks for the formatting as well > as an eclipse formatter. It helps a lot to make sure that the code is > formatted in the same way by everyone and makes it easier to spot actual > changes. > On the other hand the cxf formatting rules are a bit strange regarding > imports so without all the formatters installed it is a pain... So like > most of the time it is a two edged sword ... > > Christian > > > > On 25.04.2017 03:51, David Jencks wrote: >> For reasons unclear to me Eclipse has started saving modified files >> reformatted with the felix eclipse code template. This, to put it mildly, >> has shown that the code isn’t formatted with the template, and I can’t fish >> out my actual changes by hand. >> >> What would people think if I reformatted the entire DS project and checked >> in the result? I’m hoping that I can convince git to end up showing me my >> actual changes after this exercise. >> >> In a somewhat separate issue, I have so far been unable to convince Eclipse >> to let me open the R7 branch, so it’s possible someone else may have to >> apply similar changes to that. >> >> thanks >> david jencks >> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
Re: [VOTE] Release Apache Felix SCR 2.0.10
Maybe I missed it, but in the future could you announce that you plan a release? I would have liked to get FELIX-5618 <https://issues.apache.org/jira/browse/FELIX-5618> and the warning for FELIX-5621 <https://issues.apache.org/jira/browse/FELIX-5621> in. thanks david jencks > On Apr 24, 2017, at 11:59 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > > Hi, > > We solved 4 issues in this release > https://issues.apache.org/jira/browse/FELIX/fixforversion/12340440 > > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-1177/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1177 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
DS code formatting
For reasons unclear to me Eclipse has started saving modified files reformatted with the felix eclipse code template. This, to put it mildly, has shown that the code isn’t formatted with the template, and I can’t fish out my actual changes by hand. What would people think if I reformatted the entire DS project and checked in the result? I’m hoping that I can convince git to end up showing me my actual changes after this exercise. In a somewhat separate issue, I have so far been unable to convince Eclipse to let me open the R7 branch, so it’s possible someone else may have to apply similar changes to that. thanks david jencks
Re: Modifying service properties in lifecycle and bind methods
I opened FELIX-5621 <https://issues.apache.org/jira/browse/FELIX-5621> about
this. I still think returning service properties from event methods cannot be
made thread safe.
As noted in the issue, I think ExtComponentContext can be used safely with code
like:
final AtomicReference<Dictionary<String, Object>> propRef;
...
Dictionary<String, Object> oldProps;
Dictionary<String, Object> newProps;
do {
synchronized(propRef) {
oldProps = propRef.get();
newProps = new Hashtable<>(oldProps);
}
//update newProps with new information
extComponentContext.setServiceProperties(newProps);
} while ( propsRef.compareAndSet( oldProps, newProps)}
I think all we can do in code now is to say not to use the annotation on event
methods.
thanks
david jencks
> On Apr 11, 2017, at 9:09 PM, David Jencks <david.a.jen...@gmail.com> wrote:
>
> We seem to be thinking along similar lines…. earlier today I wrote this but
> got distracted before sending:
>
> At the moment I don’t see how returning the new service properties from
> bimd/updated/unbind methods can be thread safe. I think the
> activate/modify/deactivate methods are ok.
>
> I wonder if using the ExtComponentContext to modify the properties and
> synchronizing access would lead to deadlocks. Better than this would be a
> compare-and-set method of some sort on ExtComponentContext, perhaps based on
> a change count
>
> int cc;
> Dictionary<String, Object> newProps;
> do {
> cc = etc.getChangeCount();
> newProps = new Hashtable<>(ecc.getProperties());
> //update properties
> } while (!ecc.compareAndSet(cc, newProps)}
>
> david jencks
>
>
>> On Apr 11, 2017, at 10:25 AM, Brent Daniel <brenthdan...@gmail.com> wrote:
>>
>> I agree that serializing everything would be counterproductive (though the
>> impact could be reduced by limiting synchronization to methods with the Map
>> return signature.) I wonder if it would be possible to implement a
>> lightweight scheme using update counts, though.
>>
>> Otherwise it's probably a bad idea to ever have lifecycle and bind methods
>> that both update service properties. And, unfortunately, that may not be
>> all that obvious because the updates will happen in the expected order most
>> of the time. I'm not sure if modifying service properties is documented
>> somewhere (I couldn't find anything), but if it is this should probably be
>> mentioned there.
>>
>> On Mon, Apr 10, 2017 at 3:28 PM, David Jencks <david.a.jen...@gmail.com>
>> wrote:
>>
>>> I don’t think this is a bug. To avoid this behavior I think we’d have to
>>> serialize all lifecycle method invocations which I believe to be very
>>> undesirable.
>>>
>>> I could be wrong.
>>>
>>> david jencks
>>>
>>>> On Apr 10, 2017, at 2:39 PM, Brent Daniel <brenthdan...@gmail.com>
>>> wrote:
>>>>
>>>> Should there be any guarantees on the ordering of service property
>>> updates
>>>> across methods?
>>>>
>>>> For example, say I have an activate method that simply returns the
>>> current
>>>> service properties and a bind method that adds "active=true" to the
>>> current
>>>> properties and returns the updated properties. Both methods are
>>>> synchronized.
>>>>
>>>> Let's say activate() is invoked first and exits. Before Felix updates the
>>>> service properties, another thread calls the bind method, and Felix
>>> updates
>>>> the service properties to contain "active=true". Then the first thread
>>>> updates the service properties to the set returned from the activate()
>>>> method, thus blowing away the changes from the bind method.
>>>>
>>>> Is this a bug? Or should we not be relying on the property updates from
>>> the
>>>> first method being called taking effect before the second method's
>>> updates?
>>>
>>>
>
