[jira] [Reopened] (ARIES-584) Blueprint Managed Service Factory Instantiates Duplicate Service
[ https://issues.apache.org/jira/browse/ARIES-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reopened ARIES-584: --- I'd like to get that fixed in 0.3.x in case we need a new release (which might happen). Also, I've learned that calling OSGi API while holding java locks is bound to lead to deadlocks, so I think we should find a better solution for that. > Blueprint Managed Service Factory Instantiates Duplicate Service > > > Key: ARIES-584 > URL: https://issues.apache.org/jira/browse/ARIES-584 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: 0.2, 0.3 > Environment: Mac OSX 10.6.6 / Equinox 3.6.1 / Felix Config Admin > 1.2.8 / Aries Blueprint 0.3 (and 0.2) >Reporter: Greg Rapp >Assignee: Guillaume Nodet > Fix For: 1.0 > > Attachments: logs.txt, org.apache.aries.blueprint.cm-0.3.1.patch, > org.apache.aries.blueprint.cm.patch-withtrunk.patch > > > Creating a simple managed service factory, two services are instantiated for > a single factory configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Apache aries blueprint core and partial application release candidate
+1 on getting these released. It would be good to fix the remaining compliance failures but that can be done as part of a subsequent release. Now that we're releasing modular we should be able to release as often as we like... David On 21 July 2012 00:12, Holly Cummins wrote: > I've staged a release candidate for the next set of application > bundles and blueprint-core (yay!). > > WHAT'S BEEN RELEASED? > > The modules are staged and tagged as follows: > > blueprint-core > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.core-1.0.0 > > application-default-local-platform > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.default.local.platform-1.0.0 > > application-obr-resolver > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.resolver.obr-1.0.0 > > application-converters > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.converters-1.0.0 > > application-install > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.install-1.0.0 > > application-itest-interface > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.itest.interfaces-1.0.0 > > application-resolve-transform-cm > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.resolve.transform.cm-1.0.0 > > application-runtime-framework > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.framework-1.0.0 > > application-runtime-isolated > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.isolated-1.0.0 > > application-runtime-repository > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.repository-1.0.0 > > application-runtime > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime-1.0.0 > > > VERIFYING THE RELEASE > > Instructions for verifying the release are at > http://aries.apache.org/development/verifyingrelease.html. > Alternately, cut and paste the following to run a full check: > > wget --no-check-certificate > https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh > chmod a+x verify_staged_release.sh > ./verify_staged_release.sh 069 mytempdirectory 2>&1 | tee verifyresults.txt > grep FAIL verifyresults.txt > grep ERROR verifyresults.txt > > > SOURCE ZIPS > > Artifacts are in one staged repo, > https://repository.apache.org/content/repositories/orgapachearies-069/. > Links to the *.zip files for each module are provided below: > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/blueprint/org.apache.aries.blueprint.core/1.0.0/org.apache.aries.blueprint.core-1.0.0-source-release.zip > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.converters/1.0.0/org.apache.aries.application.converters-1.0.0-source-release.zip > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.default.local.platform/1.0.0/org.apache.aries.application.default.local.platform-1.0.0-source-release.zip > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.install/1.0.0/org.apache.aries.application.install-1.0.0-source-release.zip > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.resolve.transform.cm/1.0.0/org.apache.aries.application.resolve.transform.cm-1.0.0-source-release.zip > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.resolver.obr/1.0.0/org.apache.aries.application.resolver.obr-1.0.0-source-release.zip > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.runtime/1.0.0/org.apache.aries.application.runtime-1.0.0-source-release.zip > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.runtime.framework/1.0.0/org.apache.aries.application.runtime.framework-1.0.0-source-release.zip > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.runtime.isolated/1.0.0/org.apache.aries.application.runtime.isolated-1.0.0-source-release.zip > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.runtime.itest.interfaces/1.0.0/org.apache.aries.application.runtime.itest.interfaces-1.0.0-source-release.zip > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.runtime.repository/1.0.0/org.apache.aries.application.runtime.repository-1.0.0-source-release.zip > > > The RAT and IANAL build checks passed. Note
Re: [VOTE] Apache aries blueprint core and partial application release candidate
+1 on this release. Ran the verification scripts and no failure nor error found. As for the modular release, have anyone tried to see whether it works? The scenario will be changing the minor package version for an API, only the impl bundle package import need to change. From my last experiment, it is not working as expected. I can be mistaken. Thanks Emily On Mon, Jul 23, 2012 at 9:04 AM, David Bosschaert < david.bosscha...@gmail.com> wrote: > +1 on getting these released. > > It would be good to fix the remaining compliance failures but that can > be done as part of a subsequent release. Now that we're releasing > modular we should be able to release as often as we like... > > David > > On 21 July 2012 00:12, Holly Cummins > wrote: > > I've staged a release candidate for the next set of application > > bundles and blueprint-core (yay!). > > > > WHAT'S BEEN RELEASED? > > > > The modules are staged and tagged as follows: > > > > blueprint-core > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.core-1.0.0 > > > > application-default-local-platform > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.default.local.platform-1.0.0 > > > > application-obr-resolver > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.resolver.obr-1.0.0 > > > > application-converters > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.converters-1.0.0 > > > > application-install > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.install-1.0.0 > > > > application-itest-interface > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.itest.interfaces-1.0.0 > > > > application-resolve-transform-cm > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.resolve.transform.cm-1.0.0 > > > > application-runtime-framework > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.framework-1.0.0 > > > > application-runtime-isolated > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.isolated-1.0.0 > > > > application-runtime-repository > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.repository-1.0.0 > > > > application-runtime > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime-1.0.0 > > > > > > VERIFYING THE RELEASE > > > > Instructions for verifying the release are at > > http://aries.apache.org/development/verifyingrelease.html. > > Alternately, cut and paste the following to run a full check: > > > > wget --no-check-certificate > > https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh > > chmod a+x verify_staged_release.sh > > ./verify_staged_release.sh 069 mytempdirectory 2>&1 | tee > verifyresults.txt > > grep FAIL verifyresults.txt > > grep ERROR verifyresults.txt > > > > > > SOURCE ZIPS > > > > Artifacts are in one staged repo, > > https://repository.apache.org/content/repositories/orgapachearies-069/. > > Links to the *.zip files for each module are provided below: > > > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/blueprint/org.apache.aries.blueprint.core/1.0.0/org.apache.aries.blueprint.core-1.0.0-source-release.zip > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.converters/1.0.0/org.apache.aries.application.converters-1.0.0-source-release.zip > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.default.local.platform/1.0.0/org.apache.aries.application.default.local.platform-1.0.0-source-release.zip > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.install/1.0.0/org.apache.aries.application.install-1.0.0-source-release.zip > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.resolve.transform.cm/1.0.0/org.apache.aries.application.resolve.transform.cm-1.0.0-source-release.zip > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.resolver.obr/1.0.0/org.apache.aries.application.resolver.obr-1.0.0-source-release.zip > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.runtime/1.0.0/org.apache.aries.application.runtime-1.0.0-source-release.zip > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.runtime.framework/1.0.0/org.apache.aries.application.runtime.framework-1.0.0-source-release.zip > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/
Re: [VOTE] Apache aries blueprint core and partial application release candidate
> > As for the modular release, have anyone tried to see whether it works? The > scenario will be changing the minor package version for an API, only the > impl bundle package import need to change. From my last experiment, it is > not working as expected. I can be mistaken. > I *think* it will be much better once we're using 1.x.x versions. The two things we need to make it work are the full range of semantic versions (that is, 1.0.0 and higher), and always building against the minimum version of a dependency, rather than the latest snapshot. But as you say, the true test will be when we start rolling out bug fix releases. Holly > > Thanks > Emily > > > > On Mon, Jul 23, 2012 at 9:04 AM, David Bosschaert < > david.bosscha...@gmail.com> wrote: > > > +1 on getting these released. > > > > It would be good to fix the remaining compliance failures but that can > > be done as part of a subsequent release. Now that we're releasing > > modular we should be able to release as often as we like... > > > > David > > > > On 21 July 2012 00:12, Holly Cummins > > wrote: > > > I've staged a release candidate for the next set of application > > > bundles and blueprint-core (yay!). > > > > > > WHAT'S BEEN RELEASED? > > > > > > The modules are staged and tagged as follows: > > > > > > blueprint-core > > > > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.core-1.0.0 > > > > > > application-default-local-platform > > > > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.default.local.platform-1.0.0 > > > > > > application-obr-resolver > > > > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.resolver.obr-1.0.0 > > > > > > application-converters > > > > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.converters-1.0.0 > > > > > > application-install > > > > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.install-1.0.0 > > > > > > application-itest-interface > > > > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.itest.interfaces-1.0.0 > > > > > > application-resolve-transform-cm > > > > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.resolve.transform.cm-1.0.0 > > > > > > application-runtime-framework > > > > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.framework-1.0.0 > > > > > > application-runtime-isolated > > > > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.isolated-1.0.0 > > > > > > application-runtime-repository > > > > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime.repository-1.0.0 > > > > > > application-runtime > > > > > > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.application.runtime-1.0.0 > > > > > > > > > VERIFYING THE RELEASE > > > > > > Instructions for verifying the release are at > > > http://aries.apache.org/development/verifyingrelease.html. > > > Alternately, cut and paste the following to run a full check: > > > > > > wget --no-check-certificate > > > > https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh > > > chmod a+x verify_staged_release.sh > > > ./verify_staged_release.sh 069 mytempdirectory 2>&1 | tee > > verifyresults.txt > > > grep FAIL verifyresults.txt > > > grep ERROR verifyresults.txt > > > > > > > > > SOURCE ZIPS > > > > > > Artifacts are in one staged repo, > > > https://repository.apache.org/content/repositories/orgapachearies-069/ > . > > > Links to the *.zip files for each module are provided below: > > > > > > > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/blueprint/org.apache.aries.blueprint.core/1.0.0/org.apache.aries.blueprint.core-1.0.0-source-release.zip > > > > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.converters/1.0.0/org.apache.aries.application.converters-1.0.0-source-release.zip > > > > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.default.local.platform/1.0.0/org.apache.aries.application.default.local.platform-1.0.0-source-release.zip > > > > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.install/1.0.0/org.apache.aries.application.install-1.0.0-source-release.zip > > > > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.resolve.transform.cm/1.0.0/org.apache.aries.application.resolve.transform.cm-1.0.0-source-release.zip > > > > > > https://repository.apache.org/content/repositories/orgapachearies-069/org/apache/aries/application/org.apache.aries.application.resolver.obr/1.0.0/org.apache.aries.application.resolver.obr-1.0.0-source-release.z
Snapshots while a release is in progress
Hi all, first many thanks to Holly for organizing the Aries release. This is really a lot of work and she is doinga great job making it possible. Btw. I hope aries can switch to a simpler release concept soon but this is not what I wanted to discuss. I have a concern about the old snapshots when a release takes place. Currently the snapshots are removed from the apache snapshot repo as soon as a release is started. This means that dependent projects like karaf have to adapt all the time. So for each part of aries that is released we first have to switch to the next snapshot version as the release is not yet there and then to the release version. Even this effort only helps for local builds at the moment as the new snapshots do not seem to work through Jenkins. So each developer also has to build the aries trunk all the time. So basically this means that the karaf build on Jenkins is now red for 24 days. So to improve this I propose to keep the old snapshots for some months so dependent projects have some time to adapt to a new release or snapshot. What do you think? Is this possible? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: Snapshots while a release is in progress
On Mon, Jul 23, 2012 at 11:16 AM, Christian Schneider < ch...@die-schneider.net> wrote: > Hi all, > > first many thanks to Holly for organizing the Aries release. This is > really a lot of work and she is doinga great job making it possible. Btw. I > hope aries can switch to a simpler release concept soon but this is not > what I wanted to discuss. > I know I keep saying it, but I do think once the 1.0.0 bundles are released, everything will be much easier. :) In particular, we'll have far fewer snapshot dependencies in our poms, so the case where we depend on an 'old' snapshot while a release is being voted through will be rarer. > I have a concern about the old snapshots when a release takes place. > Currently the snapshots are removed from the apache snapshot repo as soon > as a release is started. This means that dependent projects like karaf have > to adapt all the time. > Oh dear. I *thought* from what Dan had said that the old snapshot wasn't removed until the release was actually promoted. Certainly I can see, for example, 1.0.0-SNAPSHOT of blueprint-core at https://repository.apache.org/content/groups/snapshots/org/apache/aries/blueprint/org.apache.aries.blueprint.core/1.0.0-SNAPSHOT/. However, if the karaf builds have been red for 24 days, that suggests this understanding is wrong. :) > > So for each part of aries that is released we first have to switch to the > next snapshot version as the release is not yet there and then to the > release version. Even this effort only helps for local builds at the moment > as the new snapshots do not seem to work through Jenkins. So each developer > also has to build the aries trunk all the time. > > So basically this means that the karaf build on Jenkins is now red for 24 > days. > I agree this is not at all ideal and needs to be fixed, in some way or another. I'll investigate and see if I can figure out what's going on with the awol snapshots. > So to improve this I propose to keep the old snapshots for some months so > dependent projects have some time to adapt to a new release or snapshot. > What do you think? Is this possible? I think this is a Nexus configuration issue, and nothing to do with us directly. Maybe Dan Kulp knows more? Holly > > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > >
Re: Snapshots while a release is in progress
Following up to myself, I've just cleaned my local repo and built blueprint, and I see output like: Downloading: http://repository.apache.org/snapshots/org/apache/aries/blueprint/org.apache.aries.blueprint.core/1.0.0-SNAPSHOT/org.apache.aries.blueprint.core-1.0.0-20120719.033239-39.jar Downloaded: http://repository.apache.org/snapshots/org/apache/aries/blueprint/org.apache.aries.blueprint.core/1.0.0-SNAPSHOT/org.apache.aries.blueprint.core-1.0.0-20120719.033239-39.jar(374 KB at 124.9 KB/sec) So I think the snapshots are still there in the repo, and perhaps it's a maven or Jenkins config thing? Still something that needs to be fixed, of course ... Holly On Mon, Jul 23, 2012 at 12:53 PM, Holly Cummins < holly.k.cumm...@googlemail.com> wrote: > On Mon, Jul 23, 2012 at 11:16 AM, Christian Schneider < > ch...@die-schneider.net> wrote: > >> Hi all, >> >> first many thanks to Holly for organizing the Aries release. This is >> really a lot of work and she is doinga great job making it possible. Btw. I >> hope aries can switch to a simpler release concept soon but this is not >> what I wanted to discuss. >> > > I know I keep saying it, but I do think once the 1.0.0 bundles are > released, everything will be much easier. :) In particular, we'll have far > fewer snapshot dependencies in our poms, so the case where we depend on an > 'old' snapshot while a release is being voted through will be rarer. > > >> I have a concern about the old snapshots when a release takes place. >> Currently the snapshots are removed from the apache snapshot repo as soon >> as a release is started. This means that dependent projects like karaf have >> to adapt all the time. >> > > Oh dear. I *thought* from what Dan had said that the old snapshot wasn't > removed until the release was actually promoted. Certainly I can see, for > example, 1.0.0-SNAPSHOT of blueprint-core at > https://repository.apache.org/content/groups/snapshots/org/apache/aries/blueprint/org.apache.aries.blueprint.core/1.0.0-SNAPSHOT/. > However, if the karaf builds have been red for 24 days, that suggests this > understanding is wrong. :) > > >> >> So for each part of aries that is released we first have to switch to the >> next snapshot version as the release is not yet there and then to the >> release version. Even this effort only helps for local builds at the moment >> as the new snapshots do not seem to work through Jenkins. So each developer >> also has to build the aries trunk all the time. >> >> So basically this means that the karaf build on Jenkins is now red for 24 >> days. >> > > I agree this is not at all ideal and needs to be fixed, in some way or > another. I'll investigate and see if I can figure out what's going on with > the awol snapshots. > > >> So to improve this I propose to keep the old snapshots for some months so >> dependent projects have some time to adapt to a new release or snapshot. >> What do you think? Is this possible? > > > I think this is a Nexus configuration issue, and nothing to do with us > directly. Maybe Dan Kulp knows more? > > Holly > >> >> >> Christian >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> Talend Application Integration Division http://www.talend.com >> >> >
[jira] [Commented] (ARIES-867) Deadlock if stopping a blueprint bundle while the blueprint container is in the create state.
[ https://issues.apache.org/jira/browse/ARIES-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420703#comment-13420703 ] Marcel Hanser commented on ARIES-867: - sry forgot the threaddump. > Deadlock if stopping a blueprint bundle while the blueprint container is in > the create state. > - > > Key: ARIES-867 > URL: https://issues.apache.org/jira/browse/ARIES-867 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-0.3.1 > Environment: Felix 4.0.2, Fileinstall 3.2.4, Pax Logging 1.6.3. >Reporter: Marcel Hanser > Attachments: com.test.deadlock.1.blueprint-0.0.1-SNAPSHOT.jar, > com.test.deadlock.2.stopper-0.0.1-SNAPSHOT.jar, felix-framework-4.0.2.zip, > stripped-threaddump.txt > > > Assume a updating mechanism which installs a bundle using fileinstall. It > places a bundle in a folder watched by fileinstall. If the bundle is removed > in a short manner a deadlock may occur. This issue can occur if a bundles > blueprintcontainer is registering services during the create state and the > bundle is stopped concurrently. See attached Threaddump. We also attached a > sample environment to reproduce the deadlock. > For reproduction: > - start the container in debug mode. > - put the com.test.deadlock.1.blueprint-0.0.1-SNAPSHOT.jar into the ./load > folder and wait for GRACE_PERIOD state of the blueprint container. > - set breakpoint on line 3205 in class org.apache.felix.framework.Felix. > - put the com.test.deadlock.2.stopper-0.0.1-SNAPSHOT.jar into the ./load > folder. > - skip the breakpoint the FIRST time! > - remove the com.test.deadlock.1.blueprint-0.0.1-SNAPSHOT.jar from ./load > folder, fileinstall will now remove the bundle, wait a until fileinstall > loggs the that. > - resuming now the debugger. This leads to the deadlock and to the attached > thread dump. > Richard S.Hall does describe the problem in the comment here: > https://issues.apache.org/jira/browse/FELIX-3393?focusedCommentId=13244548&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13244548 > You might consider to register services in a open call, if > easily possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ARIES-867) Deadlock if stopping a blueprint bundle while the blueprint container is in the create state.
[ https://issues.apache.org/jira/browse/ARIES-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Hanser updated ARIES-867: Attachment: stripped-threaddump.txt > Deadlock if stopping a blueprint bundle while the blueprint container is in > the create state. > - > > Key: ARIES-867 > URL: https://issues.apache.org/jira/browse/ARIES-867 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-0.3.1 > Environment: Felix 4.0.2, Fileinstall 3.2.4, Pax Logging 1.6.3. >Reporter: Marcel Hanser > Attachments: com.test.deadlock.1.blueprint-0.0.1-SNAPSHOT.jar, > com.test.deadlock.2.stopper-0.0.1-SNAPSHOT.jar, felix-framework-4.0.2.zip, > stripped-threaddump.txt > > > Assume a updating mechanism which installs a bundle using fileinstall. It > places a bundle in a folder watched by fileinstall. If the bundle is removed > in a short manner a deadlock may occur. This issue can occur if a bundles > blueprintcontainer is registering services during the create state and the > bundle is stopped concurrently. See attached Threaddump. We also attached a > sample environment to reproduce the deadlock. > For reproduction: > - start the container in debug mode. > - put the com.test.deadlock.1.blueprint-0.0.1-SNAPSHOT.jar into the ./load > folder and wait for GRACE_PERIOD state of the blueprint container. > - set breakpoint on line 3205 in class org.apache.felix.framework.Felix. > - put the com.test.deadlock.2.stopper-0.0.1-SNAPSHOT.jar into the ./load > folder. > - skip the breakpoint the FIRST time! > - remove the com.test.deadlock.1.blueprint-0.0.1-SNAPSHOT.jar from ./load > folder, fileinstall will now remove the bundle, wait a until fileinstall > loggs the that. > - resuming now the debugger. This leads to the deadlock and to the attached > thread dump. > Richard S.Hall does describe the problem in the comment here: > https://issues.apache.org/jira/browse/FELIX-3393?focusedCommentId=13244548&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13244548 > You might consider to register services in a open call, if > easily possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-584) Blueprint Managed Service Factory Instantiates Duplicate Service
[
https://issues.apache.org/jira/browse/ARIES-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420725#comment-13420725
]
Marcel Hanser commented on ARIES-584:
-
As I understand the OSGi Configuration Admin spec garantees that we are
notified if there is already an existing configuration for a
ManagedServiceFactory as the ConfigurationWatcher is one, so there is no need
to additionally check it in the init() method? (See 104.6.2 OSGi compendium
specification V 4.3 or 4.2).
{code}"When the Configuration Admin service detects the registration of a
Managed Service Factory, it must find all configuration dictionaries for this
factory and must then sequentially call
ManagedServiceFactory.updated(String,Dictionary) for each configuration
dictionary. The first argument is the PID of the Configuration object (the one
created by the Configuration Admin service) and the second argument contains
the configuration properties."{code}
This would also reduce the critical area for a deadlock. If you call the
updated method on your own during the init() method the chance to get caught
into the deadlock described here
https://issues.apache.org/jira/browse/ARIES-867 increases. Clear: the deadlock
situation is not totally mitigated due to the service registration in the
init() method, while holding the BlueprintContainer lock...
> Blueprint Managed Service Factory Instantiates Duplicate Service
>
>
> Key: ARIES-584
> URL: https://issues.apache.org/jira/browse/ARIES-584
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: 0.2, 0.3
> Environment: Mac OSX 10.6.6 / Equinox 3.6.1 / Felix Config Admin
> 1.2.8 / Aries Blueprint 0.3 (and 0.2)
>Reporter: Greg Rapp
>Assignee: Guillaume Nodet
> Fix For: 1.0
>
> Attachments: logs.txt, org.apache.aries.blueprint.cm-0.3.1.patch,
> org.apache.aries.blueprint.cm.patch-withtrunk.patch
>
>
> Creating a simple managed service factory, two services are instantiated for
> a single factory configuration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (ARIES-877) The BeanRecipe is missing the factory recipe as a dependency
Guillaume Nodet created ARIES-877: - Summary: The BeanRecipe is missing the factory recipe as a dependency Key: ARIES-877 URL: https://issues.apache.org/jira/browse/ARIES-877 Project: Aries Issue Type: Bug Components: Blueprint Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (ARIES-878) Threading issues with
Guillaume Nodet created ARIES-878: - Summary: Threading issues with Key: ARIES-878 URL: https://issues.apache.org/jira/browse/ARIES-878 Project: Aries Issue Type: Bug Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0 The managed component does not have correct values has the ConfigAdmin configuration is only taken into account later in the build. This is problematic especially when no update strategy is defined. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (ARIES-879) can't be used as a top level bean
Guillaume Nodet created ARIES-879: - Summary: can't be used as a top level bean Key: ARIES-879 URL: https://issues.apache.org/jira/browse/ARIES-879 Project: Aries Issue Type: Bug Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (ARIES-315) Blueprint-cm and the cm-properties element
[
https://issues.apache.org/jira/browse/ARIES-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned ARIES-315:
-
Assignee: Guillaume Nodet
> Blueprint-cm and the cm-properties element
> --
>
> Key: ARIES-315
> URL: https://issues.apache.org/jira/browse/ARIES-315
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
> Environment: I was using Aries that I built myself. I had used source
> code from the trunk.
>Reporter: Bartosz Kowalewski
>Assignee: Guillaume Nodet
>
> I used to employ Spring Extender when implementing enterprise applications to
> be deployed onto an OSGi container. I've recently moved to Blueprint and it
> turned out that I'm now NOT able to do what was previously possible (with
> Spring Extender). I'm not sure if this is a bug or blueprint-cm behaves as
> designed. Let me explain ...
> I tried to use Blueprint similarly to what I did in Spring:
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0";>
>class="com.bartek.tests.paxtests.blueprint.cm.ConfigurableMock">
>
>
>
>
> {code}
> What I really want to do is to inject all the properties for a given
> persistent id into a field of my bean. This was possible for Spring Extender.
> I analyzed the Blueprint source code, because I wanted to provide a patch for
> this issue, but it turned out that there are several reasons why this cannot
> work:
> 1. blueprint-cm xsd does not allow using the 'id' attribute on the
> cm-properties element
> 2. CmNamespaceHandler is prepared to parse neither top level cm-properties
> elements, nor cm-properties inlined as a value for a property of a bean
> manager
> 3. the CmNamespaceHandler 's decorateCmProperties method and especially the
> contents of the CmProperties class suggest that cm-properties were not
> designed to be used the way I would like to use them; it is designed to
> provide a way to update properties of a registered service;
> While I can definitely patch it, so that it works the way I want :), I would
> like to know if such a usage is allowed by the spec. My first impression
> (especially after I found out how CmProperties work - #3 above) is that this
> feature of Spring DM was dropped.
> One more thing: Is there any draft of the spec that covers the blueprint-cm
> schema? I found it difficult to understand the semantics behind the
> bluepring-cm elements only provided with the xsd file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ARIES-879) can't be used as a top level bean
[ https://issues.apache.org/jira/browse/ARIES-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved ARIES-879. --- Resolution: Duplicate > can't be used as a top level bean > - > > Key: ARIES-879 > URL: https://issues.apache.org/jira/browse/ARIES-879 > Project: Aries > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ARIES-584) Blueprint Managed Service Factory Instantiates Duplicate Service
[ https://issues.apache.org/jira/browse/ARIES-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved ARIES-584. --- Resolution: Fixed See rev. http://svn.apache.org/viewvc?view=revision&revision=1364914 > Blueprint Managed Service Factory Instantiates Duplicate Service > > > Key: ARIES-584 > URL: https://issues.apache.org/jira/browse/ARIES-584 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: 0.2, 0.3 > Environment: Mac OSX 10.6.6 / Equinox 3.6.1 / Felix Config Admin > 1.2.8 / Aries Blueprint 0.3 (and 0.2) >Reporter: Greg Rapp >Assignee: Guillaume Nodet > Fix For: 1.0 > > Attachments: logs.txt, org.apache.aries.blueprint.cm-0.3.1.patch, > org.apache.aries.blueprint.cm.patch-withtrunk.patch > > > Creating a simple managed service factory, two services are instantiated for > a single factory configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ARIES-877) The BeanRecipe is missing the factory recipe as a dependency
[ https://issues.apache.org/jira/browse/ARIES-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved ARIES-877. --- Resolution: Fixed Fixed in rev. http://svn.apache.org/viewvc?view=revision&revision=1364830 > The BeanRecipe is missing the factory recipe as a dependency > > > Key: ARIES-877 > URL: https://issues.apache.org/jira/browse/ARIES-877 > Project: Aries > Issue Type: Bug > Components: Blueprint >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ARIES-877) The BeanRecipe is missing the factory recipe as a dependency
[ https://issues.apache.org/jira/browse/ARIES-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated ARIES-877: -- Fix Version/s: (was: 1.0) blueprint-core-1.0.1 > The BeanRecipe is missing the factory recipe as a dependency > > > Key: ARIES-877 > URL: https://issues.apache.org/jira/browse/ARIES-877 > Project: Aries > Issue Type: Bug > Components: Blueprint >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: blueprint-core-1.0.1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ARIES-878) Threading issues with
[ https://issues.apache.org/jira/browse/ARIES-878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved ARIES-878. --- Resolution: Fixed Fixed in rev. http://svn.apache.org/viewvc?rev=1364831&view=rev > Threading issues with > --- > > Key: ARIES-878 > URL: https://issues.apache.org/jira/browse/ARIES-878 > Project: Aries > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 1.0 > > > The managed component does not have correct values has the ConfigAdmin > configuration is only taken into account later in the build. This is > problematic especially when no update strategy is defined. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ARIES-315) Blueprint-cm and the cm-properties element
[
https://issues.apache.org/jira/browse/ARIES-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved ARIES-315.
---
Resolution: Fixed
Fix Version/s: 1.0
Fixed in rev http://svn.apache.org/viewvc?rev=1364832&view=rev
> Blueprint-cm and the cm-properties element
> --
>
> Key: ARIES-315
> URL: https://issues.apache.org/jira/browse/ARIES-315
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
> Environment: I was using Aries that I built myself. I had used source
> code from the trunk.
>Reporter: Bartosz Kowalewski
>Assignee: Guillaume Nodet
> Fix For: 1.0
>
>
> I used to employ Spring Extender when implementing enterprise applications to
> be deployed onto an OSGi container. I've recently moved to Blueprint and it
> turned out that I'm now NOT able to do what was previously possible (with
> Spring Extender). I'm not sure if this is a bug or blueprint-cm behaves as
> designed. Let me explain ...
> I tried to use Blueprint similarly to what I did in Spring:
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0";>
>class="com.bartek.tests.paxtests.blueprint.cm.ConfigurableMock">
>
>
>
>
> {code}
> What I really want to do is to inject all the properties for a given
> persistent id into a field of my bean. This was possible for Spring Extender.
> I analyzed the Blueprint source code, because I wanted to provide a patch for
> this issue, but it turned out that there are several reasons why this cannot
> work:
> 1. blueprint-cm xsd does not allow using the 'id' attribute on the
> cm-properties element
> 2. CmNamespaceHandler is prepared to parse neither top level cm-properties
> elements, nor cm-properties inlined as a value for a property of a bean
> manager
> 3. the CmNamespaceHandler 's decorateCmProperties method and especially the
> contents of the CmProperties class suggest that cm-properties were not
> designed to be used the way I would like to use them; it is designed to
> provide a way to update properties of a registered service;
> While I can definitely patch it, so that it works the way I want :), I would
> like to know if such a usage is allowed by the spec. My first impression
> (especially after I found out how CmProperties work - #3 above) is that this
> feature of Spring DM was dropped.
> One more thing: Is there any draft of the spec that covers the blueprint-cm
> schema? I found it difficult to understand the semantics behind the
> bluepring-cm elements only provided with the xsd file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-584) Blueprint Managed Service Factory Instantiates Duplicate Service
[ https://issues.apache.org/jira/browse/ARIES-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421221#comment-13421221 ] Hendy Irawan commented on ARIES-584: Thank you Guillaume ! :) BTW forgive me to ask again... is there any plans to support managed service factory properties without implementing 'updated()' ? i.e. using the same behavior as managed service (bean initially created using managed properties, if the managed properties change then the bean gets reloaded). > Blueprint Managed Service Factory Instantiates Duplicate Service > > > Key: ARIES-584 > URL: https://issues.apache.org/jira/browse/ARIES-584 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: 0.2, 0.3 > Environment: Mac OSX 10.6.6 / Equinox 3.6.1 / Felix Config Admin > 1.2.8 / Aries Blueprint 0.3 (and 0.2) >Reporter: Greg Rapp >Assignee: Guillaume Nodet > Fix For: 1.0 > > Attachments: logs.txt, org.apache.aries.blueprint.cm-0.3.1.patch, > org.apache.aries.blueprint.cm.patch-withtrunk.patch > > > Creating a simple managed service factory, two services are instantiated for > a single factory configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
