THanks for your patch Bob, it's applied. The next release of the event admin will have the version 1.4.0.
I would like to cut a release as soon as possible, or do you think something needs to changed before? Carsten 2014-08-18 13:22 GMT+02:00 Carsten Ziegeler <cziege...@apache.org>: > Hi Bob, > > I think there is no good reason to keep it separate, I guess I just forgot > to merge them into trunk :) > Therefore, patches welcome :) > > Carsten > > > 2014-08-17 20:31 GMT+02:00 Bob Paulin <b...@bobpaulin.com>: > > Hi, >> >> Carsten would it make sense to move the IT test from the whiteboard to >> the regular code base? These tests only take about a minute and require a >> profile to run anyways so I think include them would be a good idea. I'd >> be happy to integrate the poms to allow this unless there's a reason they >> must be separate. I also have a patch to upgrade it to Pax-Exam 4 which I >> had to do for it to work with my OS. >> >> I'll work with those with the TCK for the performance/readability >> enhancements but the IT test has been helpful already for some tinkering. >> Thanks for the direction! >> >> - Bob >> >> >> On 8/15/2014 10:40 AM, Carsten Ziegeler wrote: >> >>> Hi, >>> >>> >>> 2014-08-15 15:28 GMT+02:00 Jan Willem Janssen < >>> janwillem.jans...@luminis.eu> >>> : >>> >>> On 15/08/14 14:58, Bob Paulin wrote: >>>> >>>>> I noticed in https://issues.apache.org/jira/browse/FELIX-3511 Java >>>>> Concurrency is being introduced to the code base. A couple of >>>>> thoughts on this. >>>>> >>>>> 1) With this not being backwards compatible with earlier versions >>>>> does it make sense to increment at least the minor version (ie 1.3 >>>>> -> 1.4). Java 8 introduces a slew of incompatibility with prior >>>>> releases with the changes to the collection libraries so I'm >>>>> curious how other projects are handling this. >>>>> >>>> As I understand the issue, it talks about going from Java 5 to Java 6 >>>> as required version, but yes, strictly speaking this would mean a >>>> minor bump at least. We should be more strict on this, I agree (made >>>> the same mistake in the Felix HTTP project as well). >>>> >>>> Actually, as far as I remember the idea was that the version number >>> reflects the specification version it implements - but this might not >>> really make sense, so bumping the minor version is a good thing. >>> >>> 2) Event admin has no tests. I would be interested in working on >>>>> creating some tests for this project. Any thoughts on where to >>>>> begin with this effort? >>>>> >>>> I think the current implementation is written (and maintained) by >>>> people that have access to the OSGi TCK, so they can tests the >>>> implementation against the specification, which might explain the lack >>>> of unit and integration tests. >>>> >>>> Yepp, the implementation passes the OSGi TCK which I believe tests a >>> lot of >>> aspects already. >>> >>> >>> But to get started: just start writing unit tests against the code in >>>> trunk and provide them as patches. It is always good to have tests >>>> written by somebody else, as they most often have new/fresh insights >>>> in the use cases... >>>> >>>> Absolutely, we also have some additional tests in the whiteboard area >>> for >>> event admin. It's basically a stress test. >>> >>> 3) It appears there maybe other areas of the event admin code that >>>>> might benefit from the Concurrency objects. Perhaps the use of one >>>>> of the Queue constructs for holding some of the asynchronous >>>>> events. Thoughts on this? >>>>> >>>> As long as it has positive effect on the performance, I think nobody >>>> will complaint about this, if you're willing to provide patches ;) >>>> >>>> Right :) This has all been written initially on Java 1.4 so there might >>>> be >>>> >>> areas which can be improved. >>> However, a nicer implementation is one thing, the other one is >>> performance. >>> The goal should be to have a minimum on synchronization between threads >>> to >>> get the best performance. I'm not saying the current implementation is >>> perfect though :) >>> >>> Carsten >>> >>> >>> - -- >>>> Met vriendelijke groeten | Kind regards >>>> >>>> Jan Willem Janssen | Software Architect >>>> +31 631 765 814 >>>> >>>> /My world is revolving around INAETICS and Amdatu/ >>>> >>>> Luminis Technologies B.V. >>>> Churchillplein 1 >>>> 7314 BZ Apeldoorn >>>> +31 88 586 46 00 >>>> >>>> http://www.luminis-technologies.com >>>> http://www.luminis.eu >>>> >>>> KvK (CoC) 09 16 28 93 >>>> BTW (VAT) NL8169.78.566.B.01 >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>>> Comment: GPGTools - http://gpgtools.org >>>> >>>> iQIcBAEBAgAGBQJT7gruAAoJEKF/mP2eHDc4vO8QANxPmNAzlgzUbhxD0VfLN2++ >>>> SlFrTqAGxaIS3rI3fzacBn5Z/v12azwyKLE39WfUEak+i5539LrcQYu8b2mOg4ML >>>> rtz2Yz6r/IcSDixO5y17HrdHyGle58u/gPzJecQqz5j3iqHi4P8eKtNx8FWrG91c >>>> 3X56VsP0sb718YswDnu8WXwy8V8I6p1h5vJdYJRx2DcOml+TEcxHxGTH6h7pDePt >>>> DcsPF7E3XaHGWpPvJ5GX8JYjzl80TM5xV4d47VAGdeVCY+JewsC6OlDtxhargGFG >>>> O0wEM9RqI2/R9OTB1K6STIwQZvglyjvUp1odgGEvgl8B/kbSh7WHprtUWIrG+D8Z >>>> cIEBjS9mYIkPEQQo0NMZIqt1XfEMiK5qElqa7v0z8IDGbhaPHy+vGpK84uhItz6M >>>> ++tEZ66OGfNaVJG9ueY+093M/J70V57ylw3Mz1Vhf7yChNa1iuT+sCU0OLOPom4K >>>> 4UL3H59m9SCXGzg5EoVEglpggdWZCaQ//73mWp7CLob6Kwk8xCvRtC5yVzbxIAgh >>>> UUVcltvSvIDklu9l9k4Di15Q4VyDz9HSu2ZilJJcWln4ZnaanGqxdoRu4tORw7fg >>>> jchVs8Bcw1TmSGTjAwzZkKlFoZfGPPkLpa9/SXYDPfsgeU43hqJyazQ7a7ll0SpP >>>> 62oji7tQ0LgRHEnbuZcs >>>> =PraV >>>> -----END PGP SIGNATURE----- >>>> >>>> >>> >>> >> > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
