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
