Re: [DS] How about an SCR 1.6.2 release ?
Since I haven't seen any requests for pre-java-5 support I may spend a couple minutes tomorrow cleaning up the pom and possibly removing the dependency on backport-util-concurrent. thanks david jencks On Nov 1, 2012, at 1:10 AM, Felix Meschberger wrote: > Hi > > Am 31.10.2012 um 21:31 schrieb David Jencks: > >> DS 1.2: AFAIK we've completely implemented the DS 1.2 spec. > > Excellent. > >> I don't really understand the location binding and targeted PID bits. > > It comes from the Configuration Admin spec and must be replicate in SCR since > we basically act like a Configuration Admin service (the configuration > provisioning part) towards the components. > > I think we can live without this for the 1.6.2 relase. > >> >> Java 5: I'm certainly happy with not temporarily removing the java 5-isms, >> but I could still do it if anyone else asks. I havent' done any basic >> housekeeping like removing the pre-java-5 concurrency compatibility code. I >> have no strong feeling about releasing with or without this stuff. > > Ok, lets release with this cruft in and cleanup after the release. > > I just started a thread on the users list asking for opinions regarding our > itended use to just use Java 5 features and API going forward. > > Regards > Felix > >> >> thanks! >> david jencks >> >> On Oct 31, 2012, at 12:32 PM, Felix Meschberger wrote: >> >>> Hi >>> >>> Am 31.10.2012 um 19:54 schrieb David Jencks: >>> I updated the changelog from the svn log hopefully I didn't miss anything. >>> >>> Just updated the changelog from the JIRA release notes. >>> >>> Another question crossing my mind: Since the current state passes the most >>> recent CT and checking the changes section in the 4.3 compendium spec I >>> would assume this version also implements Version 1.2 of the DS spec. >>> Correct ? >>> >>> The only thing not fully implemented for the most recent specs is support >>> for the most recent Configuration Admin features like relaxed location >>> binding and targetted PIDs. I can live with that. >>> >>> Regards >>> Felix >>> waiting for advice on the other two questions thanks david jencks On Oct 31, 2012, at 8:44 AM, David Jencks wrote: > At the moment the code uses some java 5. How important is it that this > release not require java 5? It would not be very difficult to remove the > java 5-isms and put them back after the release. > > I've been marking defects as applying to and fixed in scr-1.8.0. I guess > we should go back and change them to 1.6.2? > > I have not been maintaining the changelog that will be a bit of work. > > If I don't discover any giant problems before we get the above done I'm > fine with a release. > > thanks > david jencks > > On Oct 31, 2012, at 3:05 AM, Felix Meschberger wrote: > >> Hi all, >> >> I see the current trunk build passes our own as well as the OSGi CT >> tests and there are no open issues marked with 1.6.2. >> >> Shall I go ahead and cut a release ? >> >> This would IMHO also enable David to continue his refactorings. >> >> Regards >> Felix > >>> >> >
[jira] [Commented] (FELIX-3745) [DS] A component setting its service properties should be able to set target filters
[ https://issues.apache.org/jira/browse/FELIX-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491944#comment-13491944 ] David Jencks commented on FELIX-3745: - I needed a way to set a target filter based on some of the other configuration properties. I eventually found another way to do this, but don't really see why this shouldn't work. It's a simple change but I don't need it for 1.6.2 > [DS] A component setting its service properties should be able to set target > filters > - > > Key: FELIX-3745 > URL: https://issues.apache.org/jira/browse/FELIX-3745 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: scr-1.6.2 > > > There's some chance of infinite cycles but a lifecycle method returning new > service properties ought to be able to set target filters on the dependencies. > Unless this is a bad idea and we shouldn't implement it this should be > proposed for the DS 1.3 spec. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3744) [DS] Component should set implementation object before propagating changed service properties
[ https://issues.apache.org/jira/browse/FELIX-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks resolved FELIX-3744. - Resolution: Fixed r1406395 This is easy to fix and IMO a release blocker. > [DS] Component should set implementation object before propagating changed > service properties > - > > Key: FELIX-3744 > URL: https://issues.apache.org/jira/browse/FELIX-3744 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: scr-1.6.2 > > > A component needs to set its implementation object before propagating the > service property changes from the activate method. Otherwise the new service > properties could satisfy a target filter and result in a getService() request > before the implementation object is set but after it has been created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3624) Performance tuning solution for BundleRepository/ResolverImpl
[
https://issues.apache.org/jira/browse/FELIX-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491834#comment-13491834
]
Jarek Gawor commented on FELIX-3624:
I think there might be a potential problem with the patch with the
searchResources(Requirement, Set) function. The function is supposed to search
for matching resources within a specified set of resources. With caching
enabled that means the m_capabilitiesCache will be checked first - a cache of
local and remote resources only. Once a matching resource is found in the cache
it will be checked against the specified set. That's good but there is at least
one case where the cache might not contain a resource in the specified set. For
example, the m_addedSet - which user can add resources to before resolve() is
called. So in this case, with caching, searchResources() would return null
instead of a matching resource from the m_addedSet.
> Performance tuning solution for BundleRepository/ResolverImpl
> -
>
> Key: FELIX-3624
> URL: https://issues.apache.org/jira/browse/FELIX-3624
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
> Environment: Geronimo3 + BundleRepository 1.6.6
>Reporter: SheldonShao
>Priority: Critical
> Attachments: Felix_ResolverImpl_AfterTuning.png,
> Felix_ResolverImpl.png, repo_for_resolver_perf.xml, ResolverImpl.diff,
> ResolverImpl.java, ResolverImplTest.diff
>
>
> There are too many numebers of method calling about checking whether
> capabities are matched with requiment in ResolverImpl.searchResources.
> This is a performance issue of ResolverImpl.resolve.
> If it creates a capabity to resource+capabity mapping first. Then leverage
> this cache to do requirment matching. It will get better performance.
> Here is part of code. More details please check attachments.
> private final Map m_capabilitiesCache = new HashMap(8192);
> private String getKey(String filter, String prefix) {
> if (filter != null) {
> int index = filter.indexOf(prefix);
> if (index > 0) {
> int end = filter.indexOf(SUFFIX, index +
> prefix.length());
> if (end > index) {
> return filter.substring(index, end);
> }
> }
> }
> return null;
> }
> private String getKey(Requirement requirement) {
> String key = null;
> String name = requirement.getName();
> String filter = requirement.getFilter();
> if (Capability.BUNDLE.equals(name)) {
> key = getKey(filter, PREFIX_SYMBOLICNAME);
> } else if (Capability.PACKAGE.equals(name)) {
> key = getKey(filter, PREFIX_PACKAGE);
> } else if (Capability.SERVICE.equals(name)) {
> key = getKey(filter, PREFIX_SERVICE);
> } else if (Capability.FRAGMENT.equals(name)) {
> key = getKey(filter, PREFIX_HOST);
> } else {
> key = PREFIX_CAPABILITY + name;
> }
> return key;
> }
> private static final String PREFIX_SYMBOLICNAME = "symbolicname=";
> private static final String PREFIX_PACKAGE = "package=";
> private static final String PREFIX_SERVICE = "service=";
> private static final String PREFIX_HOST = "host=";
> private static final String PREFIX_CAPABILITY = "capability=";
> private static final char SUFFIX = ')';
> private void initCache(Capability[] capabilities, Resource resource) {
> Capability cap;
> Map properties;
> String name;
> for (int j = 0; j < capabilities.length; j++) {
> cap = capabilities[j];
> String key = null;
> properties = cap.getPropertiesAsMap();
> name = cap.getName();
> if (Capability.BUNDLE.equals(name)) {
> key = PREFIX_SYMBOLICNAME +
> properties.get("symbolicname");
> } else if (Capability.PACKAGE.equals(name)) {
> key = PREFIX_PACKAGE +
> properties.get("package");
> } else if (Capability.SERVICE.equals(name)) {
> key = PREFIX_SERVICE +
> properties.get("service");
> } else if (Capability.FRAGMENT.equals(name)) {
> key = PREFIX_HOST + properties.get("host");
> } else {
>
[jira] [Updated] (FELIX-3452) Extending maven-ipojo-plugin with directoryManipulation support.
[ https://issues.apache.org/jira/browse/FELIX-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-3452: - Fix Version/s: (was: ipojo-manipulator-1.8.6) ipojo-manipulator-1.8.8 > Extending maven-ipojo-plugin with directoryManipulation support. > > > Key: FELIX-3452 > URL: https://issues.apache.org/jira/browse/FELIX-3452 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.4 >Reporter: Göktürk Gezer > Labels: ipojo, ipojo-manipulator, maven > Fix For: ipojo-manipulator-1.8.8 > > Attachments: org.apache.felix.ipojo.manipulator-project.patch > > > Currently maven-ipojo-plugin leaves the compiled classes and MANIFEST.MF file > in project folder unmanipulated. By the help of ipojo-manipulator's new > directory manipulating ability, maven-ipojo-plugin can be extended to provide > more lifecycle operations and keep project folder synched with generated > ipojo-bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3286) Update POM to use the new parent
[ https://issues.apache.org/jira/browse/FELIX-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-3286: - Fix Version/s: (was: ipojo-manipulator-1.8.6) ipojo-manipulator-1.8.8 > Update POM to use the new parent > > > Key: FELIX-3286 > URL: https://issues.apache.org/jira/browse/FELIX-3286 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.4 >Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: ipojo-manipulator-1.8.8 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3451) "instance.name" attribute not recognized
[ https://issues.apache.org/jira/browse/FELIX-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-3451: - Fix Version/s: (was: ipojo-composite-1.8.4) ipojo-runtime-1.8.6 > "instance.name" attribute not recognized > > > Key: FELIX-3451 > URL: https://issues.apache.org/jira/browse/FELIX-3451 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-composite-1.8.2 > Environment: Mac OS X Lion 10.7.3, Java 1.6.0_31, System Bundle > (4.0.2), Apache Felix Bundle Repository (1.6.6), Apache Felix iPOJO > (1.9.0.SNAPSHOT), Apache Felix iPOJO API (1.7.0.SNAPSHOT), Apache Felix iPOJO > Arch Command (1.7.0.SNAPSHOT), Apache Felix iPOJO Composite (1.9.0.SNAPSHOT), > Apache Felix Shell Service (1.4.2), Apache Felix Shell TUI (1.4.1) >Reporter: Fabio Lattario Fonseca >Priority: Minor > Labels: composite, instance, ipojo, name, newbie, xml > Fix For: ipojo-runtime-1.8.6 > > Attachments: bad_pom.xml, comanche_iPOJO_composite.tgz, good_pom.xml > > > When using the attribute "instance.name" to give a name for a component > instance inside a composite, the name is not being assigned properly. On the > other hand, if the deprecated attribute "name" is used, the instance gets the > right name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RESULT][VOTE] Release of iPOJO Manipulator 1.8.6 and iPOJO Runtime 1.8.4
Perfect - thanks! /Bengt 2012/11/6 Clement Escoffier > Hi, > > It's time to close the vote. The vote is successful. > > I will upload the artifacts right now. > > Thanks and regards, > > Clement > On 28 oct. 2012, at 17:30, Clement Escoffier > wrote: > > > Hi, > > > > It's time to cut a release of the iPOJO Manipulator (1.8.6) and runtime > project (1.8.4). > > > > This releases contains: > > * iPOJO Manipulator 1.8.6 > > * maven-ipojo-plugin 1.8.6 > > * iPOJO Ant Task 1.8.6 > > * iPOJO BND Plugin 1.8.6 > > * iPOJO Core 1.8.4 > > * iPOJO Composite 1.8.4 > > * iPOJO Annotations 1.8.4 > > * iPOJO Runtime Project 1.8.4 > > > > Those releases contain a lot of bugs fixes. The changelogs are below. > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachefelix-172/ > > > > 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 172 /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 (at least). > > > > Regards, > > > > Clement > > > > Changelog of the manipulator project (1.8.6): > > * [FELIX-3461] - Re-manipulation with annotated component produces > corrupted MANIFEST > > * [FELIX-3466] - Pojoization.directoryManipulation() does not take > MANIFEST file location into account. > > * [FELIX-3508] - IPojo Manipulator left out 'array of enums' in > generated metadata > > * [FELIX-3539] - iPOJO Manipulator failed on classes containing > expanded frames > > * [FELIX-3573] - IPojo bytecode manipulation generates a duplicate > local variable > > * [FELIX-3574] - IPojo bytecode manipulation looses method argument > names > > * [FELIX-3621] - Two dimensional array as argument to a method in a > component > > > > Changelog of the runtime project (1.8.4): > > * [FELIX-3451] - "instance.name" attribute not recognized > > * [FELIX-3500] - InstanceManager concurrency issue: "A methodID > cannot be associated with a method from the POJO class" > > * [FELIX-3501] - IPojo FactoryStateListener doesn't get notified > while stopping factory > > * [FELIX-3545] - Memory leak when unregistering a component used by > an aggregate dependency with an unbind callback > > * [FELIX-3548] - Concurrent access during startup > > * [FELIX-3567] - iPOJO Configuration Handler should not reuse the > dictionary object from the configuration admin > > * [FELIX-3576] - iPOJO fails when using constructor injection and > expecting BundleContext in ctor > > * [FELIX-3599] - Problem with 'subservice action="instantiate"' in > ipojo composite > > * [FELIX-3621] - Two dimensional array as argument to a method in a > component > > * [FELIX-3672] - Potential Concurrent Modification Exception when a > bundle is stopped > > * [FELIX-3560] - Extensions to IPojo's Factory and ComponentInstance > documentation for custom handlers > >
Re: [RESULT][VOTE] Release of iPOJO Manipulator 1.8.6 and iPOJO Runtime 1.8.4
Hi, It's time to close the vote. The vote is successful. I will upload the artifacts right now. Thanks and regards, Clement On 28 oct. 2012, at 17:30, Clement Escoffier wrote: > Hi, > > It's time to cut a release of the iPOJO Manipulator (1.8.6) and runtime > project (1.8.4). > > This releases contains: > * iPOJO Manipulator 1.8.6 > * maven-ipojo-plugin 1.8.6 > * iPOJO Ant Task 1.8.6 > * iPOJO BND Plugin 1.8.6 > * iPOJO Core 1.8.4 > * iPOJO Composite 1.8.4 > * iPOJO Annotations 1.8.4 > * iPOJO Runtime Project 1.8.4 > > Those releases contain a lot of bugs fixes. The changelogs are below. > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-172/ > > 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 172 /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 (at least). > > Regards, > > Clement > > Changelog of the manipulator project (1.8.6): > * [FELIX-3461] - Re-manipulation with annotated component produces > corrupted MANIFEST > * [FELIX-3466] - Pojoization.directoryManipulation() does not take > MANIFEST file location into account. > * [FELIX-3508] - IPojo Manipulator left out 'array of enums' in generated > metadata > * [FELIX-3539] - iPOJO Manipulator failed on classes containing expanded > frames > * [FELIX-3573] - IPojo bytecode manipulation generates a duplicate local > variable > * [FELIX-3574] - IPojo bytecode manipulation looses method argument names > * [FELIX-3621] - Two dimensional array as argument to a method in a > component > > Changelog of the runtime project (1.8.4): > * [FELIX-3451] - "instance.name" attribute not recognized > * [FELIX-3500] - InstanceManager concurrency issue: "A methodID cannot be > associated with a method from the POJO class" > * [FELIX-3501] - IPojo FactoryStateListener doesn't get notified while > stopping factory > * [FELIX-3545] - Memory leak when unregistering a component used by an > aggregate dependency with an unbind callback > * [FELIX-3548] - Concurrent access during startup > * [FELIX-3567] - iPOJO Configuration Handler should not reuse the > dictionary object from the configuration admin > * [FELIX-3576] - iPOJO fails when using constructor injection and > expecting BundleContext in ctor > * [FELIX-3599] - Problem with 'subservice action="instantiate"' in ipojo > composite > * [FELIX-3621] - Two dimensional array as argument to a method in a > component > * [FELIX-3672] - Potential Concurrent Modification Exception when a > bundle is stopped > * [FELIX-3560] - Extensions to IPojo's Factory and ComponentInstance > documentation for custom handlers
Re: [VOTE] Release of iPOJO Manipulator 1.8.6 and iPOJO Runtime 1.8.4
+1, Regards, Clement On 30 oct. 2012, at 20:43, Karl Pauls wrote: > +1 > > regards, > > Karl > > On Mon, Oct 29, 2012 at 6:03 PM, Carsten Ziegeler > wrote: >> +1 >> >> Carsten >> >> 2012/10/29 Felix Meschberger : >>> +1 >>> >>> Regards >>> Felix >>> >>> Am 28.10.2012 um 17:30 schrieb Clement Escoffier: >>> Hi, It's time to cut a release of the iPOJO Manipulator (1.8.6) and runtime project (1.8.4). This releases contains: * iPOJO Manipulator 1.8.6 * maven-ipojo-plugin 1.8.6 * iPOJO Ant Task 1.8.6 * iPOJO BND Plugin 1.8.6 * iPOJO Core 1.8.4 * iPOJO Composite 1.8.4 * iPOJO Annotations 1.8.4 * iPOJO Runtime Project 1.8.4 Those releases contain a lot of bugs fixes. The changelogs are below. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-172/ 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 172 /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 (at least). Regards, Clement Changelog of the manipulator project (1.8.6): * [FELIX-3461] - Re-manipulation with annotated component produces corrupted MANIFEST * [FELIX-3466] - Pojoization.directoryManipulation() does not take MANIFEST file location into account. * [FELIX-3508] - IPojo Manipulator left out 'array of enums' in generated metadata * [FELIX-3539] - iPOJO Manipulator failed on classes containing expanded frames * [FELIX-3573] - IPojo bytecode manipulation generates a duplicate local variable * [FELIX-3574] - IPojo bytecode manipulation looses method argument names * [FELIX-3621] - Two dimensional array as argument to a method in a component Changelog of the runtime project (1.8.4): * [FELIX-3451] - "instance.name" attribute not recognized * [FELIX-3500] - InstanceManager concurrency issue: "A methodID cannot be associated with a method from the POJO class" * [FELIX-3501] - IPojo FactoryStateListener doesn't get notified while stopping factory * [FELIX-3545] - Memory leak when unregistering a component used by an aggregate dependency with an unbind callback * [FELIX-3548] - Concurrent access during startup * [FELIX-3567] - iPOJO Configuration Handler should not reuse the dictionary object from the configuration admin * [FELIX-3576] - iPOJO fails when using constructor injection and expecting BundleContext in ctor * [FELIX-3599] - Problem with 'subservice action="instantiate"' in ipojo composite * [FELIX-3621] - Two dimensional array as argument to a method in a component * [FELIX-3672] - Potential Concurrent Modification Exception when a bundle is stopped * [FELIX-3560] - Extensions to IPojo's Factory and ComponentInstance documentation for custom handlers >>> >> >> >> >> -- >> Carsten Ziegeler >> cziege...@apache.org > > > > -- > Karl Pauls > karlpa...@gmail.com > http://twitter.com/karlpauls > http://www.linkedin.com/in/karlpauls > https://profiles.google.com/karlpauls
[jira] [Commented] (FELIX-3746) Deadlock around SCR AbstractComponentManager and DelayedComponentManager
[ https://issues.apache.org/jira/browse/FELIX-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491304#comment-13491304 ] Bertrand Delacretaz commented on FELIX-3746: You're right, I compared that revision 1236132 with trunk and there's been a lot of changes, I should have done that earlier. I'll run my torture tests against trunk and report here. > Deadlock around SCR AbstractComponentManager and DelayedComponentManager > > > Key: FELIX-3746 > URL: https://issues.apache.org/jira/browse/FELIX-3746 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 >Reporter: Bertrand Delacretaz > Attachments: stack-trace.txt > > > The exact affected version is org.apache.felix.scr trunk revision 1236132 > I'm running my stress tests from https://github.com/bdelacretaz/osgi-stresser > which repeatedly and concurrently change the start level, update a bundle and > stop/start bundles, and sometimes seeing a deadlock between threads that use > the AbstractComponentManager and DelayedComponentManager. > I'll attach a stack trace that's slightly incomplete, where I removed > product-specific threads. I can provide the full stack trace privately if > needed. > I'll try running the latest trunk of that module to see if that makes a > difference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
