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-----
