From river-commits-return-qgross@example.net Tue Jan 05 07:34:21 2010 Return-Path: <river-commits-return-qgross@example.net> Delivered-To: qgross@example.net Received: (qmail 91642 invoked from network); 5 Jan 2010 07:34:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Jan 2010 07:34:20 -0000 Received: (qmail 53541 invoked by uid 500); 5 Jan 2010 07:34:20 -0000 Delivered-To: qgross@example.net Received: (qmail 53484 invoked by uid 500); 5 Jan 2010 07:34:20 -0000 Mailing-List: contact qgross@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:qgross@example.net> List-Unsubscribe: <mailto:qgross@example.net> List-Post: <mailto:qgross@example.net> List-Id: <river-commits.incubator.apache.org> Reply-To: qgross@example.net Delivered-To: mailing list qgross@example.net Received: (qmail 53475 invoked by uid 99); 5 Jan 2010 07:34:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 07:34:20 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eris.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 07:34:19 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id CC82023889D2; Tue, 5 Jan 2010 07:33:58 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r895927 - /incubator/river/jtsk/trunk/KEYS Date: Tue, 05 Jan 2010 07:33:58 -0000 To: qgross@example.net From: qgross@example.net X-Mailer: svnmailer-1.0.8 Message-Id: <qgross@example.net> Author: peter_firmstone Date: Tue Jan 5 07:33:57 2010 New Revision: 895927 URL: http://svn.apache.org/viewvc?rev=895927&view=rev Log: QA build has a minimum requirement of JDK1.6, although the current River release supports Java 1.4, this commit reverts back to java 1.4 language feaures, methods changed to avoid depreciated method .toURL(); Modified: incubator/river/jtsk/trunk/KEYS Modified: incubator/river/jtsk/trunk/KEYS URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/KEYS?rev=895927&r1=895926&r2=895927&view=diff ============================================================================== --- incubator/river/jtsk/trunk/KEYS (original) +++ incubator/river/jtsk/trunk/KEYS Tue Jan 5 07:33:57 2010 @@ -13,110 +13,61 @@ ========================================================================= -pub 1024R/86124FBC 2007-12-19 -uid Frank Barnaby <qgross@example.net> -sig 3 86124FBC 2007-12-20 Frank Barnaby <qgross@example.net> -sig 75E20239 2007-12-20 [User ID not found] -sig 3 7DDF5B95 2007-12-20 Jim Hurley <qgross@example.net> -sig A355A63E 2007-12-21 Jukka Zitting <qgross@example.net> -uid Frank Barnaby <qgross@example.net> -sig 3 86124FBC 2007-12-20 Frank Barnaby <qgross@example.net> -sig 75E20239 2007-12-20 [User ID not found] -sig 3 7DDF5B95 2007-12-20 Jim Hurley <qgross@example.net> -sig A355A63E 2007-12-21 Jukka Zitting <qgross@example.net> -uid Frank Barnaby (CODE SIGNING KEY) <qgross@example.net> -sig A355A63E 2007-12-21 Jukka Zitting <qgross@example.net> -sig 3 86124FBC 2007-12-19 Frank Barnaby <qgross@example.net> +pub 4096R/1CC8406F 2010-01-01 [expires: 2012-01-01] +uid Peter Firmstone (Engineer) <qgross@example.net> +sig 3 1CC8406F 2010-01-01 Peter Firmstone (Engineer) <qgross@example.net> +sub 4096R/DBF67B3D 2010-01-01 [expires: 2012-01-01] +sig 1CC8406F 2010-01-01 Peter Firmstone (Engineer) <qgross@example.net> -----BEGIN PGP PUBLIC KEY BLOCK----- -Version: GnuPG v2.0.4 (FreeBSD) +Version: GnuPG v1.4.10 (SunOS) -mI0ER2lPLQEEAMD8GEy2mN9Nr3Ogo5GMy8JwljgRN3o+WTwHu8uz5iG4XgpSfwrj -OdMy424UaNd6/xTdlV3NMnG+HWFF8TaVsiusEFhMa0ep/ChGjXwfXmnzp/xMj915 -LHzRWnTF1JMQa5Mg6zvGZUqpLozcsuyGOhW/GwsphDUI0buDcrUCc5ERABEBAAG0 -I0ZyYW5rIEJhcm5hYnkgPGZiYXJuYWJ5QGFwYWNoZS5vcmc+iLYEEwECACAFAkdq -rbgCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAZov9HhhJPvCtJA/9kWkWF -N5BDb1v8Fddj14YcWw6TJfXoeMc4B56Od78XEYLV73GKEcqAy0Dpgm4Jo4GYa2q5 -dqQYjCnFEZmOqWB6pniOJtyEJqpx1rSwjUUrZE/drssfZhj0D6NaBhKRA80u7Fhs -tpAbZWzXrNHsWEpz0L6kaXp3Y7WkVkLxDWzHrYkBHAQQAQIABgUCR2q3lwAKCRCd -Tv1TdeICOU8HB/9NqEibTe6GsY1rCRwsg/isHqJl6d6ne8pudL05KzzTC/RZJWAn -AZp6XHXr/FN+UfB2kQccXPwcoUddN/qOQbf1jixinTfoEWuvC+iFWHczWSa4Nxug -czdzHxTRD2BbEKj8J3Z1emqllT1UKECNDE4nG1v8iFZ1ibmyjpr7i5qGKiPZBIS8 -JaB1XZ19GYbLQZVkM/wAHmOVd3MjstnDDJHpyYSqWA/hryEwkRQ9HFSZWdbar6ih -89p/xQlxf45l+QnAF+DNEAddvUTd52H+d4RvFmn66cJWw08Q7/RvGc0U515P8Up6 -nRL4ybj8j2PEWthKz4AEZ5qQs8Clq0J40BUwiQEcBBMBAgAGBQJHatHtAAoJEF6p -akp931uVgVYH/3aEYIQRuqr9xkdmWbAJdnpiopPFgTLLMqe2EWDVKOWVEwiZqSa9 -aEFRPruvG5KSB4ujftNUzHhpTCkTvBe5vHGeZRc3xhf62NUEEbOng/W3AKklIzDd -3np5V2OqiJUjJlcTk3418h5b336I87yeXmM9Y2WPoZwVj6tOtLHCYsAnPxgQJ74B -uci9NPbZOsG4hvQHoA7QCirMGl1cKrhGhi3iAltu5gmPWSqPnjaPmk1uLm5vs0Tb -/Z7IA33Jp8I27NUBe6NXB/u4AdjMXxyPb9IVdRDFTJVA96ayeZuo/iusxAegskvn -TGRhqrUjJi+epGpiWrT3QKtl12eDrPMJTYWIRgQQEQIABgUCR2sCEgAKCRCnMFKc -o1WmPu2qAJ9MqUCBar/LZ8qggFA8t6jdCDAMvgCfYtpzQM/yIWyIx5WsysG1KiNg -5lq0JUZyYW5rIEJhcm5hYnkgPEZyYW5rLkJhcm5hYnlAU3VuLkNvbT6ItgQTAQIA -IAUCR2qsUQIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEBmi/0eGEk+8PFcE -AInJ2c8QeSZSnmCmUibFxsPXJAHtTeDoNqArlCVjV+W79QlZxgE+jEkdsC870a5K -yYNiN8QOttkn85mYIsKYYKcFazuaWh227Bljs3ot7c+CIMzlYdonP3XuZmWV2gOe -uVvtvyekCAM36W4xs6suuZUFND4TVuP2AyDTzDCxNUvaiQEcBBABAgAGBQJHareX -AAoJEJ1O/VN14gI5QZoH/0DvyjObQ4hUVvg7UI+2dnfFj3NmcyseVATQODo2qVA7 -PvfZQ4xFJbC633vnih7I39kWy+hcPidugrbi8A7rMUPjkP3U3L/a4DIDwItmh3d2 -K8yOaJagx0Hg0E80Krfo9khROUjMD2AUJnH9gZbJYsVpVP2ajAPX6t9cZ3R+ZVit -za+cFL7lh6B9TMo8UmdueC7IWFNKqhhL1sYa5fik6/VhLCDka0tXAu/hsU7eaiyU -aY/DiPmvg/Wx75/UYsR6G9X6K5k6wI5Xs+ZOXrXD9/BrJv17kZMY3mvdNmuInBm1 -qyng34aQz3+Jp5iw5aLersC62nsNzb68FdWcz+0FFXeJARwEEwECAAYFAkdq0e0A -CgkQXqlqSn3fW5VZFgf9H9ro0Q5XTj/A3ChLg5XenCO3Slp4g5XtuYZRxumld1AF -YxQkQComYfzxb/RdbWcjBm5iMsOb4malXx3Fu7r7WEAnLY/59FPpyCXd35zihoTB -bo6DBDobeznZmLak5ZNCSVSZq2sJDhXUE3mNJ5JtsU7QkRPLgC62cemAxOUuAkly -w0a0vlFgArJqA0kDDKEahZHjG4YHrZ1nH5uh4zsAxgJY1crnwJuQ3ihoDn35ZyBX -OCIC6w/it8FpKFBap7UDNSy/Wo4/hDnlYCBRDiLmnHUznOLrrZYsz/KIApQzMDEP -FP+rZu031SHXWTcOQqkiM5hZtug9XAvsLifBl7FHtYhGBBARAgAGBQJHawISAAoJ -EKcwUpyjVaY+RsEAnAwRMdRo+/dP8t325XZIlQIVjtYoAJsFXTRZ0zS+OyiPKkWO -5N4juUNw97Q2RnJhbmsgQmFybmFieSAoQ09ERSBTSUdOSU5HIEtFWSkgPGZiYXJu -YWJ5QGFwYWNoZS5vcmc+iEYEEBECAAYFAkdrBTUACgkQpzBSnKNVpj7GGwCeOvY3 -7d7Hr0ZTOIRTU4SEWTfUzt4An0jNRif3oQsWZcqakgGntG19dMCXiLYEEwECACAF -AkdpTy0CGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAZov9HhhJPvGf7A/4i -n0jAXIeyZWJtz+Ibfl6rDZYpfjlcBM43PcTnQZzzw1+rCR2j++N2gTfiYSi+evgv -wiRLW/1oZp9+PHZc+ybTV+7Mx4VoqhIet2AzcCHyA2TeXcF1stPPCIF0IEu4obCP -Cn6W1Ra/3siQqhdJOKecoMaYsP/g4Zjd2YvIFon+qw== -=qxoJ ------END PGP PUBLIC KEY BLOCK----- -pub 1024D/4E085E41 2009-09-30 -uid Jonathan Costers <qgross@example.net> -sig 3 4E085E41 2009-09-30 Jonathan Costers <qgross@example.net> -uid Jonathan Costers <qgross@example.net> -sig 3 4E085E41 2009-09-30 Jonathan Costers <qgross@example.net> -sub 2048g/A8F9D574 2009-09-30 -sig 4E085E41 2009-09-30 Jonathan Costers <qgross@example.net> - ------BEGIN PGP PUBLIC KEY BLOCK----- -Version: GnuPG v1.4.9 (GNU/Linux) - -mQGiBErDpSYRBACrN4aNpmUINLYq4ztGA9NP405PeJjWALdXJE8HbYTQsfBgZG6W -KYgwcJ3nm34DFsN/PEhP6HYNByJS9Cj84OnpWiYOkLkn7uNFTRJ71Jy5cwhjaTZs -9oByoqc9d13KoW4ERk9mlIyp/BcfRFHgwfHC4TKyFC1c9ysl6fXuKcB5NwCg5fOx -SNnVVW4vO7HBMutxQC/KUF8D/jlfOl9Kf7bTF6zpz8yggCTRiOuYRkN3xzvVKNhs -dY1wQKlGNdQiGRAbRrdDPBtsiee5YOwmVXMZNQEdxkr7h/hbUa1EoPZ5oR6gBZtG -zCqGUKGnX110jNifCYg4FE6hnvS+Cg3z6N7p/jTxjx0dGGokKKtiYliz2nAsQvwM -IyBLA/9wmzZ/gmFwEwUtw30cmGUXhkG9h6Nkw3ZHJsrOL7v5VyolsD7PL7q684U/ -FcDZzqB8tYaQVm1OOyUpfjxGQ7DOBLsEwXeh/SGBFJapA0WpwpML++xtlseXixCI -qRQEPPO0lS6qMAhIQgl3GF/l+jYiSmcz6bRGAst47mW/NKjAhLQySm9uYXRoYW4g -Q29zdGVycyA8am9uYXRoYW4uY29zdGVyc0Bnb29nbGVtYWlsLmNvbT6IYAQTEQIA -IAUCSsOtmAIbIwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEO9Y3/NOCF5Bmv8A -oINw/ZCQ7Ms8aVRxeHvnyZtL/1gCAJ9wO9uzqK8ccHQ9VLzmeQk5Odk3/bQmSm9u -YXRoYW4gQ29zdGVycyA8amNvc3RlcnNAYXBhY2hlLm9yZz6IYwQTEQIAIwIbIwYL -CQgHAwIEFQIIAwQWAgMBAh4BAheABQJKw63eAhkBAAoJEO9Y3/NOCF5BzPQAoNVi -56F19/sfbtVw5Cxk5ZOieDWHAKDcyrKSf5Rr4VW06Px8JoGpntRmYrkCDQRKw6Um -EAgAvpNY/NgLoXsKI+PpuhZZ9oO8Eq6ZZMGHdr6eOJZymgeyHDNfc2nLol0+Cqef -zzRqiyeoVyB9WKSMbTdD44oQ37fNGEIcQLFyBXDBFvz17UR7OmYTBHs7K2if39Ve -tQizQ1/QBw67j3uXeEEG5J4LZ3hNfoWgLAf3+wL3khPT8VIL1rs56fX+i4zO6VHw -SK5fLqXU2pmCJs+WkPMTWON3+CX+D6cqI2k7U15OJ5TmhVW9E20MzurLI6XbwGsQ -SE5o2TKBARwMSx2sxFoHLE8bkS4ErAwzz7cu3MXfXpwtcZup8tHE3ZisO7FHfhDe -ncvxu8rXgC/qr3iMpA1zFQWJowADBQgAlvr1ueALUM7kvcAF4HGu6qonhM3bhfOH -Wzo5mO1gWbPzORhbFMi3rTIuNyUPl8l5ZSDshjqzFHBgbRXVlsBpDLBn51OzkiUs -UKSxBpQJjUTsar8ml1BddDvvQ35dAsYFJj8w3mIDcE0BzkVlxo7mPEI3K0KerTRV -F/VgucCHyzhGdFTkrmKHyPsDs9tM0zeLB7vlPIz8uNoC+3K7JfUI4awNVWxVxvan -lKujOMXLAVFUlSwk6LvxsT/Kbx0drsoJtk7q/gRwVADuPh4gFAbT6Y7YUs17eJim -vK6kwYlEf9ZQFw5V/jsnOFuRb/o6VNBbGFlBycvYC3YvbvZQao0k0ohJBBgRAgAJ -BQJKw6UmAhsMAAoJEO9Y3/NOCF5Bg+cAoIbfAMFAD5USRG9UawNzpmmQtEeaAJ9N -Ps/ry6MDIWiLuvTdJasluvvayw== -=AHkc +mQINBEs9bugBEAC3/yixSTPJPJpazwLriR8h+a4HNzSh0IIroiMHHXr71w8NiED/ +IGITdJPo6VSuc1xZ+5Ztf2sK3bGmWjkdcNwdERZBNw3oZEHu8LAwLRsnKcGi9Jyd +lIAOv9cSEWz2hjXB1fbm6BtqoGQYwBqkNOT29f4icSWojY8Scfk5i5yYmUxCQAC+ +/CHkbC6JHbkjCgs/5cw3GWaWFmt4OWh0dEyj3FRdxKfhAwWCuYSDV0jtaLo9CHIR +p5ge1r5FL2nKxhYV9IcTWlLKnhAxZXiUFejeMCATmRDIa5iAHRWS6GNitA7dxdLp +HGcSKjqcOmS9xaqn2cMY/OMOhIoUTi/PdS8gfV35pc0Ve/vNSrn++jWNFVnp23ni +oD0E2b8GNU2dGDeLbg9I+5deVZugHih4BM1hUAdGO1AuBtNNfs0LfaczfSP6gxBV +on4qU3vWZKo+ZxRGMd2uv20oaedWFGWZUOmN3G17LIfanINW053Yx7okGppiH9De +YBkqJr2uNrXkRggcZBGq26rFvh5KSpHXfz7dwbU/ShNknmsIy2Af12E89mOnCJuc +dFcneItlhbbTwKAt2XLhrIeDVTAXkY4cMOmvgiMlr/FPPuEi9dZ6NNzgD9nLtZ94 +PJRltQsYJZg6AgrTHm29OI9e7Jbb/G4TfHzbpWV67+9UO2su0yOoTsg5rQARAQAB +tDhQZXRlciBGaXJtc3RvbmUgKEVuZ2luZWVyKSA8cGV0ZXIuZmlybXN0b25lQHpl +dXMubmV0LmF1PokCPgQTAQIAKAUCSz1u6AIbAwUJA8JnAAYLCQgHAwIGFQgCCQoL +BBYCAwECHgECF4AACgkQrkbnJRzIQG+UQBAAsAdgFne9Mkq22t4a0Xu7EeP3XM1y +h8z1xdViOkGLM/fCsz6EyoCkXw3I6O1bqbgKLdDlVJ4u7Zp+u6ETsBZ600CO+YUa +2/03dy0ChIWArmLGK/GCV3cIt1F1FcHMfuczbRjsxwDgXsJzR0m0JeVaIZFiPMYw +Y0gqHtB0SWmUB5oTAbc7o/6i3oyX7UB1XqzgHJQ480MYnANxwHyOrl35IJhZvGAJ +/trWTgVhvRSWClAjYsRpawEPIjI5tvnMK5Ej09esnSy56ohyejM0sqzDE59U2uK8 +PilYmfav2aoYPI0sUlkOK7UvdqlADhiGqpexzo2s/kroVn8NLsWrvMzY7oyL7rSk +oUCuAvHLk9aFHM36/0DxoVhNYe0NO74wRJFGKAqoXdAzHypAD5ki/Horghp+xGas +14jC6snDNH7TV181X4ZDY8pI9sTlxzoGiOe+3nPt/joinrjHnyh8ZYPkSN7V/j/t +4qZ4+YB/tMYmorW1Eea+0FKEpw7BbmMzKedyZPRW7GQXu2c6umcOk/KfGlZYLgSR +oZeIikjDSVFWgl0/RlbWGiTPxQGig7+Zpr3rE7HvD6TdD7yNWi+FPVu9zMtNlkpb +F48A1j5fEjd7dhI6Rbi+2JB5Cl7Wugbv9IoH4sYlmwOQ5RzfcXdRfo6o9q9S7saA +euLeWK2rqoBWJda5Ag0ESz1u6AEQAKipHlPxYPMSU/PYA/9/VrO2em7RXdaRMlSB +bIHy59X/p/2SLxNuhuo8viWlHFRm/DooZW6Bzq9SV5UF+NvHFHhY04y1wQ8/CfVq +CLNXax/6zbs7kKIbrc6rXnaL1F+ibPR+Nx6SE8la336ZLf4oxBmLaI6Uyhvt+eet +QF55+XbEVpwrM7VlGoBJbeQcyQIqkhObu8ZguktvOGaQsHwUTwyis7YwHCQLNMyO +m9Wb6xjEnWYyT2N4w+KA2krs785tFXkXy+/M49jpjSb0arBFItun1l/PJOVVsKkc +2pO8iuQL6D9I/hOVf/CdzHeLXsQ8NB6B+vTWE7/BnSS58dqmeYRUgDlUy/0FB0n+ +GdrLk0GHumunqO1d+SP2JxybBq96CZXxeYpZHULaTnY+86EXQywP9VPVribF1D4y +sBn6QOyXWTWWmz7zScC7gCkY50awhFrJyOyjdYX9R6l+HjDekNezeVH9/g8Yc31j +4MyWtUlJHigLYl16GmMQpU2yb4DFtgmRfE1VgyoxbJ3PxTu6KEyD0GcZ0ijMY9rg +l+yxGiXwEtA1WZg5zi9YC7raHsdEf3LFDo5Lbu1xB8R9HyPl+HocPgNclmRKuhLQ +BVbpzOHVt397MEIpsUuqyCR9PbR/ze3rgfPogfigorVxyxnglo7cTm/J3F9tgnta +L4u1HNdJABEBAAGJAiUEGAECAA8FAks9bugCGwwFCQPCZwAACgkQrkbnJRzIQG+v +EA/9EG7M2xcO4bj3EQdMxb6yZ450soDsGZlFXKV42SKsMTEPXUATnGIdymMzldaz +eXqWj2cqddJydK9XIu8SqbDvHDLbFzdZm4FUwil8VNX6aSrQ++MDQKzvhFSeXEnO +NQXrBjTHGUbx+jL9+BRUQm007JTk3GMahs6d2532dXxDcnUMVVJEwsmSaVjSbMX8 +1HHYNyRWp4TKOoTOu6HRSZFdF0x40QfV4DfbJmyWlR55QX9JvHTdboh8Lv0nwfDj +VzjwUxtFMZ8nIZnZd6M+bdA7jceNonTqCVoXltrjnKZpQ6O03ptqy7wdW6YiCX4f +Ec5mB+WEzErRwiymQSO3Ste4+zHpT1+Hb+W8R2JEutWY2w3KI60U6uihQroVAZPR +sWQ/Q7mk3gltVeW6jj/25nQ/ZgjQW50jd+azyAvpFdcS5JhBUK84B3YOG73wl1hR +39GPLXY7KFq6WKW/GBDW9t/tSE9gsCkkTEhdRPKBpfCL+usIskzwPVn02C9kr8cG +/ftPyM+UtojFOXAZrb6cKDeMP9NSEzg6HHZMCVm/p2EhG2vSA9Sxxfur4B8zhcur +MQXRc9qXv/NlMJ72Rsn50QDfQQ2tzv+e+kGnKeOijjC8iMWpCkmYuZ3A1gY/2TS6 +qXuRAc0pKewnUvktQab/UjNcd7jNIJhc8WC8DsCTESeZEBc= +=levA -----END PGP PUBLIC KEY BLOCK----- From river-commits-return-qgross@example.net Tue Jan 05 15:15:06 2010 Return-Path: <river-commits-return-qgross@example.net> Delivered-To: qgross@example.net Received: (qmail 69164 invoked from network); 5 Jan 2010 15:15:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Jan 2010 15:15:06 -0000 Received: (qmail 60568 invoked by uid 500); 5 Jan 2010 15:15:06 -0000 Delivered-To: qgross@example.net Received: (qmail 60512 invoked by uid 500); 5 Jan 2010 15:15:05 -0000 Mailing-List: contact qgross@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:qgross@example.net> List-Unsubscribe: <mailto:qgross@example.net> List-Post: <mailto:qgross@example.net> List-Id: <river-commits.incubator.apache.org> Reply-To: qgross@example.net Delivered-To: mailing list qgross@example.net Received: (qmail 60503 invoked by uid 99); 5 Jan 2010 15:15:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 15:15:05 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eris.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 15:15:05 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 06CC823888CF; Tue, 5 Jan 2010 15:14:45 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r896087 - in /incubator/river/jtsk/trunk/doc: arch2_0.html info-index.html manpages-index.html spec-index.html Date: Tue, 05 Jan 2010 15:14:44 -0000 To: qgross@example.net From: qgross@example.net X-Mailer: svnmailer-1.0.8 Message-Id: <qgross@example.net> Author: thobbs Date: Tue Jan 5 15:14:44 2010 New Revision: 896087 URL: http://svn.apache.org/viewvc?rev=896087&view=rev Log: Updated version numbers ready for new release Modified: incubator/river/jtsk/trunk/doc/arch2_0.html incubator/river/jtsk/trunk/doc/info-index.html incubator/river/jtsk/trunk/doc/manpages-index.html incubator/river/jtsk/trunk/doc/spec-index.html Modified: incubator/river/jtsk/trunk/doc/arch2_0.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/arch2_0.html?rev=896087&r1=896086&r2=896087&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/arch2_0.html (original) +++ incubator/river/jtsk/trunk/doc/arch2_0.html Tue Jan 5 15:14:44 2010 @@ -19,14 +19,14 @@ <body text="#000000" bgcolor="#ffffff" link="#9b37cc" vlink="#cc1877" alink="#ffffff"> -<title>Apache River Release Overview, v2.1.1</title> +<title>Apache River Release Overview, v2.2.0</title> <a name="TOP"> -<center><h1>Apache River Release Overview<br>v2.1.1</h1></center> +<center><h1>Apache River Release Overview<br>v2.2.0</h1></center> <br> <p>This document provides an overview of the new components of -the Apache River v2.1.1 release and +the Apache River v2.2.0 release and explains how the components fit together and fit within the existing Jini technology infrastructure. Much of this information is available in the package, interface, and class Modified: incubator/river/jtsk/trunk/doc/info-index.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/info-index.html?rev=896087&r1=896086&r2=896087&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/info-index.html (original) +++ incubator/river/jtsk/trunk/doc/info-index.html Tue Jan 5 15:14:44 2010 @@ -20,7 +20,7 @@ <title>Apache River Release Getting Started & More</title> -<center><h1>Apache River Release<BR>Getting Started & More with v2.1.1</h1></center> +<center><h1>Apache River Release<BR>Getting Started & More with v2.2.0</h1></center> <UL><UL> <LI><a href="#examine">Examining the distribution</a> <LI><a href="#install">Installing the <code>jsk-policy.jar</code> file</a> Modified: incubator/river/jtsk/trunk/doc/manpages-index.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/manpages-index.html?rev=896087&r1=896086&r2=896087&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/manpages-index.html (original) +++ incubator/river/jtsk/trunk/doc/manpages-index.html Tue Jan 5 15:14:44 2010 @@ -22,7 +22,7 @@ <h1><center>Apache River Release -<br>v2.1.1 Manual Pages</center></h1><br> +<br>v2.2.0 Manual Pages</center></h1><br> <hr> Modified: incubator/river/jtsk/trunk/doc/spec-index.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/spec-index.html?rev=896087&r1=896086&r2=896087&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/spec-index.html (original) +++ incubator/river/jtsk/trunk/doc/spec-index.html Tue Jan 5 15:14:44 2010 @@ -21,10 +21,10 @@ <body text="#000000" bgcolor="#ffffff" link="#9b37cc" vlink="#cc1877" alink="#ffffff"> -<h1><center>Apache River Specifications<br>v2.1.1</center></h1> +<h1><center>Apache River Specifications<br>v2.2.0</center></h1> <UL> <p> -The following specifications are available in HTML in this v2.1.1 release. +The following specifications are available in HTML in this v2.2.0 release. <P> <ul> From river-commits-return-qgross@example.net Tue Jan 05 15:52:43 2010 Return-Path: <river-commits-return-qgross@example.net> Delivered-To: qgross@example.net Received: (qmail 83589 invoked from network); 5 Jan 2010 15:52:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Jan 2010 15:52:43 -0000 Received: (qmail 16531 invoked by uid 500); 5 Jan 2010 15:52:43 -0000 Delivered-To: qgross@example.net Received: (qmail 16505 invoked by uid 500); 5 Jan 2010 15:52:43 -0000 Mailing-List: contact qgross@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:qgross@example.net> List-Unsubscribe: <mailto:qgross@example.net> List-Post: <mailto:qgross@example.net> List-Id: <river-commits.incubator.apache.org> Reply-To: qgross@example.net Delivered-To: mailing list qgross@example.net Received: (qmail 16496 invoked by uid 99); 5 Jan 2010 15:52:43 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 15:52:43 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eris.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 15:52:39 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 380C9238898B; Tue, 5 Jan 2010 15:52:17 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r896106 [2/2] - /incubator/river/jtsk/trunk/doc/release-notes/ Date: Tue, 05 Jan 2010 15:52:16 -0000 To: qgross@example.net From: qgross@example.net X-Mailer: svnmailer-1.0.8 Message-Id: <qgross@example.net> X-Virus-Checked: Checked by ClamAV on apache.org Modified: incubator/river/jtsk/trunk/doc/release-notes/servicediscovery.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/servicediscovery.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/servicediscovery.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/servicediscovery.html Tue Jan 5 15:52:15 2010 @@ -25,7 +25,7 @@ <center> <h1>Jini Service Discovery Utilities - <BR>v2.1.1 Release Notes + <BR>v2.2.0 Release Notes </h1> </center> <HR> @@ -48,428 +48,8 @@ <H3>Changes since the v2.0.1 release</H3> <dl> - <dt> <b>Configuration</b> - <dd> In this release, no new configuration entries have been added, nor have any other - changes occurred with respect to the configuration. - <p> - A full list of supported configuration entries is given in this utility's - <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html#sdmConfigEntries"> class documentation</a>. - <p> - - <dt> <b>Logging</b> - <dd> In this release, no changes have occurred with respect to the logging mechanism - employed by the service discovery manager implementation, which logs diagnostic information to the - <a href="http://java.sun.com/j2se/1.4/docs/api/java/util/logging/Logger.html"> <code>Logger</code></a> - named <code>net.jini.lookup.ServiceDiscoveryManager</code>. For a description of the - information that is logged, as well as the associated logging levels, refer to the - <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html#sdmLogging"> class documentation</a>. - <p> - - <dt> <b>Bug Fixes of Interest</b> - <dd> A number of bugs have been addressed in this release of the - service discovery manager. What follows is a description of those - bugs that might be of interest: - <p> - - <dt><b>4972100: SDM NPE in getServiceItems when blocking lookup called before filter is applied</b><dt> - <dd> When one of the blocking versions of the <code>lookup</code> method is - invoked, there are conditions in which a <code>NullPointerException</code> - can occur. One possible scenario in which this bug can occur is as follows: - -<pre><code>SDM.lookup(duration) - SDM creates cache ----- RegisterListenerTask(wait for events) - LookupTask begins - get snapshot (lookup state) - -- done -- -wait(duration) - *** start targetted service *** - NOMATCH_MATCH event received - NotifyEventTask (process event) - NewOldServiceTask (new service) - addToMap -- (item,null) -exit wait -call cach.lookup() - filterMaybeDiscard() -getServiceItems() -map(item,null) ===> NPE - filter -- map(item,filteredItem)</code></pre> - - If the timing is right, <code>getServiceItems</code> can be entered - before the filter is applied and the non-<code>null</code> - <code>filteredItem</code> is placed in the map. If this occurs, - <code>getServiceItems</code> will attempt to access - <code>filteredItem.srvc</code>, which will result in a - <code>NullPointerException</code>. - </dd> - <p> - <dt><b>5102733: SDM cache.notifyServiceMap does not use event ID in its decision process</b><dt> - <dd> Prior to this release, in the method - <code>ServiceDiscoveryManager.LookupCacheImpl.notifyServiceMap</code>, - only the sequence number of the new event and the sequence number stored - in the <code>EventReg</code> element of the <code>eventRegMap</code> were - compared when determining whether or not there is a "gap" in the event - sequence; in which case, a snapshot would be requested from the associated - lookup service. This could result in multiple unnecessary snapshots being - requested; and thus, unnecessary network traffic and resource usage. - <p> - To understand how this problem could occur, consider the following scenario: - -<pre>1 activatable lookup service registered with Phoenix (or RMID) -4 services registered with that lookup service -1 client using a cache to discover the services - ->>> phoenix -stop (or rmid -stop) to stop the lookup service ->>> all 4 services eventually discard the lookup service ->>> the client eventually discards the lookup service ->>> restart phoenix (or rmid) before 30 minutes have expired - (to restart the lookup service and recover its state before - the client's original event registration [E0] has a chance - to expire)</pre> - - When the client rediscovers the lookup service, its cache requests - a new event registration [E1]. But the lookup service still has E0 - in its state. - <p> - When the services rediscover the lookup service, they reregister with - the lookup service, and the lookup service sends a serviceAdded - (<code>NOMATCH_MATCH</code>) event to both E0 and E1 for each of the - services. The cache's event listener receives both sets of events. - <p> - Prior to fixing this bug, <code>notifyServiceMap</code> only analyzed the - sequence numbers of the events. It did not distinguish which event - registration each event corresponded to. Because E0 was recovered after - the lookup service went down and was restarted, the sequence numbers - of the events sent to that registration were greater than - <code>Integer.MAX_VALUE</code>, which resulted in a "gap" in the sequence so - that clients would know that they might have missed events. Because E1 was - not interrupted by a shutdown/restart, its sequence numbers started at 0. - Thus, when serviceAdded events arrived for E0 and for E1, the sequence - looked something like the following to <code>notifyServiceMap</code>: - -<pre>event 0 --> Service0 added: Event ID = 0 - seq# 219.879.2683 -event 1 --> Service0 added: Event ID = 1 - seq# 0 - -event 2 --> Service1 added: Event ID = 0 - seq# 219.879.2683 -event 3 --> Service1 added: Event ID = 1 - seq# 1 - -event 4 --> Service2 added: Event ID = 0 - seq# 219.879.2683 -event 5 --> Service2 added: Event ID = 1 - seq# 2 - -event 6 --> Service3 added: Event ID = 0 - seq# 219.879.2683 -event 7 --> Service3 added: Event ID = 1 - seq# 3</pre> - - Because <code>notifyServiceMap</code> did not consider the event ID, - it appeared to <code>notifyServiceMap</code> that it was receiving a - stream of events in which the sequence numbers looked like: - -<pre>{ 219.879.2683, 0, 219.879.2683, 1, 219.879.2683, 2, 219.879.2683, 3 }</pre> - - To <code>notifyServiceMap</code>, the sequence appeared to be - alternately "moving backward" and "moving forward" with a large - gap. In each case though, <code>notifyServiceMap</code> interpreted - the difference between sequence numbers as a gap; that is, - -<pre>(if event_(n+1)_seq# != 1 + event_n_seq#, then a gap is declared).</pre> - - Thus, as each event was received, <code>notifyServiceMap</code> - declared a gap, and a new snapshot was requested; which meant that for - the four services, there were eight total snapshots requested. - - To address this bug, the method <code>notifyServiceMap</code> was - modified to consider the event ID when determining whether or not - an event sequence contains a gap; which now results in the appropriate - behavior. - </dd> - <p> - <dt><b>6208587: SDM should create default LDM only when no DiscoveryManagement is configured</b><dt> - <dd> Prior to interrogating the configuration for a - <a href="../api/net/jini/discovery/DiscoveryManagement.html"> <code>DiscoveryManagement</code></a> - item (entry name = <b><i>discoveryManager</i></b>), a default - <a href="../api/net/jini/discovery/LookupDiscoveryManager.html"> <code>LookupDiscoveryManager</code></a> - is first created. Although that manager is initialized to discover no groups and no locators, - the <a href="../api/net/jini/discovery/LookupDiscovery.html"> <code>LookupDiscovery</code></a> - instance used by the default discovery manager to perform group discovery creates - a thread to listen for and process multicast announcements, as well as - additional, related threads. Thus, if a deployer configures a <i>discoveryManagement</i> - item, the creation of the default lookup discovery manager -- and the threads - that manager ultimately creates -- is unnecessary, and wastes resources. - <p> - This bug has been fixed. - </dd> - <p> - <dt> <b>Notes Of Interest</b> - <dd> - <p> - <b>Note 1: Service Reference Comparison</b> - <p> - The ability to appropriately compare two different service references - is very important to the - <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a> - in general, and the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - in particular. Currently, there are three mechanisms used to accurately - compare service references. Each mechanism is applied in different situations, - to achieve different goals. - <p> - When storing and managing service references, it is important to be able - to determine when two different references (proxies) refer to the same - back-end service (such references are referred to as <i>duplicates</i>) - so that the storage and management of any duplicate references can be - avoided. In addition to identifying duplicate references, the ability to - determine when a previously discovered service has been replaced with a - new version is also important so that consistent state may be maintained, - and entities that wish to know about such events can be informed. - Finally, when an entity wishes to discard (make eligible for rediscovery) - a particular service reference received from the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>, - it is important for the <code>LookupCache</code> to be able to compare the - reference provided by the entity to each of the previously stored references - so that the appropriate reference can be accurately selected for discard. - <p> - <b>Comparison by <a href="../api/net/jini/core/lookup/ServiceID.html"> <code>net.jini.core.lookup.ServiceID</code></a></b> - <p> - To identify, and thus avoid storing, duplicate service references, the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - compares the instances of <a href="../api/net/jini/core/lookup/ServiceID.html"> <code>ServiceID</code></a> - associated with each reference. Recall that an individual well-behaved service of - interest will usually register with multiple lookup services, and for - each lookup service with which that service registers, the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - will receive a separate event containing a reference to the service. When the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - receives events from multiple lookup services, the - <a href="../api/net/jini/core/lookup/ServiceID.html"> <code>ServiceID</code></a> - (retrieved from the service reference in the event) is used to distinguish the - service references from each other. In this way, when a new event arrives containing - a reference associated with the same service as an already-stored reference, - the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - can determine whether or not the new reference is a duplicate; in which case, the - duplicate is ignored. - <p> - <b>Comparison by <a href="../api/net/jini/io/MarshalledInstance.html"> <code>net.jini.io.MarshalledInstance.fullyEquals</code></a></b> - <p> - With respect to determining when a previously discovered service has been - replaced with a new version, the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> typically relies - on the event mechanism of the lookup service(s) with which that service is - registered to indicate that such an event has occurred. But there are - situations where the events from the lookup services do not provide enough - information to make such a determination. In those cases, the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> employs - <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a> - to make the determination. - <p> - When a well-behaved service is replaced with a new version, the new - version is typically reregistered with each lookup service with - which the old version is registered. As described in the - <a href="../specs/html/lookup-spec.html"><i>Jini Lookup Service Specification</i></a>, - each lookup service with which this reregistration process occurs first - sends a service-removed event (<code>TRANSITION_MATCH_NOMATCH</code>), and - then sends a separate service-added event (<code>TRANSITION_NOMATCH_MATCH</code>). - In this case, there is no ambiguity, and thus no need for the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - to compare the new and old service references. This is because the - combination of service-removed and service-added events from each - lookup service is an explicit indication that the service has been - replaced. Note that, as described in the specification, the lookup - service only sends a service-changed event (<code>TRANSITION_MATCH_MATCH</code>) - when the attributes of the service have been modified; not when the - service itself has been changed (replaced). Thus, if the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - receives a <code>TRANSITION_MATCH_MATCH</code> event, then it is guaranteed - that the service referenced in that event has not been replaced with a new - version. - <p> - Whenever the following conditions are satisfied, the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - will use <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a> - to compare two service references: - <p> - <ul> - <li> The references are duplicates (same <a href="../api/net/jini/core/lookup/ServiceID.html"> <code>ServiceID</code></a>) - <li> The <b><i>possibility</i></b> exists that the references may refer to different versions of the service - </ul> - <p> - When determining whether or not these conditions (in particular, the - second condition) are satisfied, the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> generally - takes a conservative approach. That is, only when it is absolutely - sure that two duplicates refer to the same version (such as when a - <code>TRANSITION_MATCH_MATCH</code> event is received), will the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - refrain from using - <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a> - to compare the duplicate references; otherwise, duplicate references are - always compared using - <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a>. - <p> - One example of a situation where the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - employs <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a> - is the situation - where a lookup service of interest is newly discovered or rediscovered. - In this situation, the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - retrieves a snapshot of the services of interest that currently reside in that - lookup service. This is done so that previously undiscovered service references, - as well as new versions of previously discovered service references, can - both be stored, duplicates can be ignored, and clients can be sent the - appropriate notifications. Whenever a reference from the snapshot is a - duplicate of a previously discovered service reference, the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - always compares the two references using - <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a>. - This is because the possibility always exists that the references may refer to different - versions of the service. - <p> - Another example of a situation where the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - employs <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a> - is when a <code>TRANSITION_NOMATCH_MATCH</code> event is received that - contains a reference that is a duplicate of a previously discovered - reference. When such an event is received, the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - must allow for the possibility that the reference contained - in the event refers to a different version of the service - than that referenced by the previously discovered service reference. - This is because the event may represent either the second half of a - <code>TRANSITION_MATCH_NOMATCH</code>/<code>TRANSITION_NOMATCH_MATCH</code> - (remove/add) event pair, or it may be a notification of the initial - registration of a new version of the service with one of the (multiple) - lookup services targeted by the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - during the service discovery process. - <p> - To understand the last example described above, consider the situation - where a service initially registers with one lookup service and then - registers with a second lookup service. If the same version of the - service is registered with each lookup service, both lookup services - will send the same event -- a <code>TRANSITION_NOMATCH_MATCH</code> - event -- to indicate that a new service has registered with the - associated lookup service. In this case, there is no ambiguity for the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>; - the second reference can be safely ignored because the references are - duplicates that refer to the exact same service. - <p> - But suppose that prior to registering with the second lookup service, - the service is replaced with a new version. In that case, the second - lookup service will still send a <code>TRANSITION_NOMATCH_MATCH</code> event, but - if the appropriate action is not taken to determine that the old version - of the service has been replaced, the new version of the service will - be ignored by the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>. - This is because the two references will have the same - <a href="../api/net/jini/core/lookup/ServiceID.html"> <code>ServiceID</code></a>, - and thus the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - will identify the two references as duplicates; ultimately ignoring the new reference. - Of course, if the service is well-behaved, because the new version of the service will - eventually reregister with the first lookup service, that lookup service will - eventually send a <code>TRANSITION_MATCH_NOMATCH</code> event followed by a - <code>TRANSITION_NOMATCH_MATCH</code> event to indicate that the service has been - replaced. But the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - must still identify and handle this situation in order to prevent possible state - corruption, even though that corruption may be only temporary. - <p> - Thus, whenever a <code>TRANSITION_NOMATCH_MATCH</code> event is received and the - associated service reference is a duplicate of a previously discovered - reference, the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - will always compare the two references using - <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a> - to determine whether or not the references refer to the same version of the service. - When they do reference the same version, the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - ignores the duplicate reference; otherwise, the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - sends a service-removed event followed by a service-added event to indicate - that the old version of the service has been replaced. - <p> - <b>Comparison by <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a></b> - <p> - The mechanism employed by the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> to select (from - storage) a given reference for discard is the - <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a> - method provided by the discovered service itself. The - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - relies on the provider of each service to override the - <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a> - method with an implementation that allows - for the identification of the service reference an entity wishes to - be discarded. Although the default implementation of - <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a> - often times may be sufficient for proper identification, service providers - are still encouraged to provide each service with its own well-defined - implementation of <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a>. - <p> - In addition to the - <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a> - method, each service should also - provide a proper implementation of the - <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode"> <code>hashCode</code></a> method. - This is because references to the service may be stored in, or interact with, - container classes (for example, - <a href="http://java.sun.com/j2se/1.4/docs/api/java/util/HashMap.html"> <code>HashMap</code></a>) - where the service's <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a> - and <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode"> <code>hashCode</code></a> - methods may be invoked "under the covers" by the container object with - which the service is interacting. From the point of view of the - <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a> - and the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>, - providing an appropriate implementation for both the - <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a> - method and the - <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode"> <code>hashCode</code></a> - method is a key characteristic of good behavior in a Jini service. - - <p> - <b>Note 2: The Service Discovery Filtering Mechanism</b> - <p> - The specification of the - <a href="../api/net/jini/lookup/ServiceItemFilter.html"> <code>ServiceItemFilter</code></a> - interface specifies what it means to <i>filter</i> a service reference selected as a - candidate for discovery. In particular, instances of - <a href="../api/net/jini/lookup/ServiceItemFilter.html"> <code>ServiceItemFilter</code></a> - can be defined to perform proxy preparation. Thus, through the client-defined filter - (through the - <a href="../api/net/jini/lookup/ServiceItemFilter.html#check"> <code>check</code></a> - method), clients can request that the - <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a>, - rather than the client itself, perform any desired proxy preparation - as part of the service discovery process. - <p> - To understand why this is important, consider what can happen when - the client performs preparation of its discovered proxies outside of the - <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a>. - When proxy preparation is performed outside of the service discovery - manager, the client risks encountering a cycle where a matching service is - discovered by the - <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a>, - is found to be untrusted when the client prepares the proxy, is discarded - by the client because it is untrusted, and is then ultimately rediscovered - because it still matches the original discovery criteria. Such a cycle - will generally repeat indefinitely because the service is not likely to - become trusted at any point in the future. Supplying the - <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a> - with the means to perform proxy preparation on the client's behalf - provides the client with a mechanism for avoiding such a cycle. - <p> - For more information, please refer to the section titled, - <i>SD.5.2 The <code>ServiceItemFilter</code> Interface</i>, contained in the - <a href="../specs/html/servicediscutil-spec.html"><i>Jini Service Discovery Utilities Specification</i></a>. - - <p> - <b>Note 3: The Service Discovery Event Mechanism</b> - <p> - The specification of the - <a href="../api/net/jini/lookup/ServiceDiscoveryListener.html"> <code>ServiceDiscoveryListener</code></a> - interface describes how the filtering mechanism and the event mechanism provided by instances of - <a href="../api/net/jini/lookup/LookupCache.html"> <code>net.jini.lookup.LookupCache</code></a> - interact. - <p> - Additionally, this specification specifies that instances of the - <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> - use the method - <a href="../api/net/jini/io/MarshalledInstance.html"> <code>net.jini.io.MarshalledInstance.fullyEquals</code></a> - to determine when a service has changed in some fundamental way (for example, - when a service is replaced with a new version). - <p> - For more information, please refer to the section titled, - <i>SD.5.4 The <code>ServiceDiscoveryListener</code> Interface</i>, contained in the - <a href="../specs/html/servicediscutil-spec.html"><i>Jini Service Discovery Utilities Specification</i></a> - <p> + <dt> <b>None</b> + </dl> <!-- No issues for now Modified: incubator/river/jtsk/trunk/doc/release-notes/servicestarter.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/servicestarter.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/servicestarter.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/servicestarter.html Tue Jan 5 15:52:15 2010 @@ -25,7 +25,7 @@ <center> <h1><code>com.sun.jini.start</code><br> -v2.1.1 Release Notes</h1> +v2.2.0 Release Notes</h1> </center> <HR> <UL> @@ -34,76 +34,10 @@ used to launch the contributed services provided in the Apache River release. -<H3>Changes since the v2.0.1 release</H3> +<H3>Changes since the v2.1.1 release</H3> <dl> - <dt> <b>Bug Fixes of Interest</b></dt> - <dd> The following bugs have been addressed in this release: - <p> - <dl> - <dt><b> - 4835830: Add per-service proxy preparer support - </b></dt> - <dd>Per-service proxy preparer support has been added to - <code>NonActivatableServiceDescriptor</code> and - <code>SharedActivatableServiceDescriptor</code> via constructor - overloads that take proxy preparer parameters. This allows users - to individually prepare the service proxies returned by service - starter framework. - <P> - <dt><b> - 4856937: Service starter should permit specifying dynamic policy provider - </b></dt> - <dd><code>ActivateWrapper</code> supports the - the <code>java.security.Security</code> property - <code>com.sun.jini.start.servicePolicyProvider</code>, which allows users - to specify the fully qualified class name of a dynamic policy provider to - use for wrapping individual service policies in a "shared" environment. - A custom service policy provider can be very useful when trying to - debug security related issues. See the start package documentation for - more detail. - <P> - <dt><b> - 4858623: change ExportClassLoader to use context class loader for parent - </b></dt> - <dd><code>ActivateWrapper.ExportClassLoader</code> now uses the calling context's - class loader as its parent (versus the application classpath, used previously). - This allows "container" applications more control over the class loader - hierarchy used when launching services. - <P> - <dt><b> - 6211452: change ActivateWrapper.ExportClassLoader to subclass PreferredClassLoader - </b></dt> - <dd><code>ActivateWrapper.ExportClassLoader</code> now extends - <code>PreferredClassLoader</code> instead of <code>URLClassLoader</code>. - A service can now specify a preferred list for its import class path, - to ensure that any classes that need to be annotated with the server's - codebase get loaded by the server's class loader rather than accidentally - being resolved in the container. - <P> - <dt><b> - 4868839: Make utility class constructors private - </b></dt> - <dd>The following utility classes simply contain static methods and - are not meant to be instantiated: - <UL> - <LI><code>ClassLoaderUtil</code> - <LI><code>DestroySharedGroup</code> - <LI><code>HTTPDStatus</code> - </UL> - To ensure this, private constructors have been added to each of the - above classes. - <P> - <dt><b> - 4936006: ServiceDescriptor's should support non-file-based classpath entries - </b></dt> - <dd>The <code>importCodebase</code> parameter in the constructors for - <code>NonActivatableServiceDescriptor</code> and - <code>SharedActivatableServiceDescriptor</code> now support either: - <UL> - <LI>a space delimited set of <code>URL</code>(s) representing a codebase or - <LI>a <code>File.pathSeparator</code> delimited set of class paths. - <UL> - <P> + <dt> <b>None</b></dt> + </dl> <!-- N/A <p> From river-commits-return-qgross@example.net Tue Jan 05 15:52:46 2010 Return-Path: <river-commits-return-qgross@example.net> Delivered-To: qgross@example.net Received: (qmail 83628 invoked from network); 5 Jan 2010 15:52:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Jan 2010 15:52:46 -0000 Received: (qmail 16625 invoked by uid 500); 5 Jan 2010 15:52:46 -0000 Delivered-To: qgross@example.net Received: (qmail 16587 invoked by uid 500); 5 Jan 2010 15:52:46 -0000 Mailing-List: contact qgross@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:qgross@example.net> List-Unsubscribe: <mailto:qgross@example.net> List-Post: <mailto:qgross@example.net> List-Id: <river-commits.incubator.apache.org> Reply-To: qgross@example.net Delivered-To: mailing list qgross@example.net Received: (qmail 16575 invoked by uid 99); 5 Jan 2010 15:52:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 15:52:46 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eris.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 15:52:37 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 32B2623888CF; Tue, 5 Jan 2010 15:52:17 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r896106 [1/2] - /incubator/river/jtsk/trunk/doc/release-notes/ Date: Tue, 05 Jan 2010 15:52:16 -0000 To: qgross@example.net From: qgross@example.net X-Mailer: svnmailer-1.0.8 Message-Id: <qgross@example.net> Author: thobbs Date: Tue Jan 5 15:52:15 2010 New Revision: 896106 URL: http://svn.apache.org/viewvc?rev=896106&view=rev Log: Changed the release notes to read "none" since this is the common case for the difference between 2.1.1 and 2.2.0. Expecting developers to fill details back in again of any work they may have done since. Modified: incubator/river/jtsk/trunk/doc/release-notes/activate.html incubator/river/jtsk/trunk/doc/release-notes/browser.html incubator/river/jtsk/trunk/doc/release-notes/classdep.html incubator/river/jtsk/trunk/doc/release-notes/classserver.html incubator/river/jtsk/trunk/doc/release-notes/comsunjinithread.html incubator/river/jtsk/trunk/doc/release-notes/discovery.html incubator/river/jtsk/trunk/doc/release-notes/fiddler.html incubator/river/jtsk/trunk/doc/release-notes/index.html incubator/river/jtsk/trunk/doc/release-notes/jeri.html incubator/river/jtsk/trunk/doc/release-notes/join.html incubator/river/jtsk/trunk/doc/release-notes/lease.html incubator/river/jtsk/trunk/doc/release-notes/loader.html incubator/river/jtsk/trunk/doc/release-notes/mahalo.html incubator/river/jtsk/trunk/doc/release-notes/mercury.html incubator/river/jtsk/trunk/doc/release-notes/netjinientry.html incubator/river/jtsk/trunk/doc/release-notes/norm.html incubator/river/jtsk/trunk/doc/release-notes/outrigger.html incubator/river/jtsk/trunk/doc/release-notes/reggie.html incubator/river/jtsk/trunk/doc/release-notes/security.html incubator/river/jtsk/trunk/doc/release-notes/servicediscovery.html incubator/river/jtsk/trunk/doc/release-notes/servicestarter.html Modified: incubator/river/jtsk/trunk/doc/release-notes/activate.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/activate.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/activate.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/activate.html Tue Jan 5 15:52:15 2010 @@ -25,7 +25,7 @@ <center> <h1><code>net.jini.activation</code><br> -v2.1.1 Release Notes</h1> +v2.2.0 Release Notes</h1> </center> <HR> <UL> @@ -35,36 +35,11 @@ <code>net.jini.activation</code></a> package provides extensions to the Java(TM) Remote Method Invocation (Java RMI) activation framework. -<H3>Changes since the v2.0.1 release</H3> +<H3>Changes since the v2.1.1 release</H3> <dl> -<dt><b>Disabled permission propagation</b></dt> -<dd> -<p><a href="../api/net/jini/activation/ActivatableInvocationHandler.html"> -<code>ActivatableInvocationHandler</code></a> by default no longer attempts -to propagate dynamic permission grants from the dynamic proxy to the -underlying activation identifier. If this functionality is required, it can -be enabled by setting the -<code>com.sun.jini.activation.enableActivateGrant</code> system property to -<code>true</code>. If the -<a href="../api/net/jini/activation/package-summary.html"> -<code>phoenix</code></a> activator has been configured -to allow anonymous client activation requests, and the invocation -constraints on the underlying activation identifier have been configured -to allow anonymous activation calls, it is not necessary to enable this. -That should be the preferred configuration. However, if the activator has -been configured to use Kerberos authentication, then anonymous calls are -not supported, and you will either have to enable the activate grant in -clients and dynamically grant sufficient -<a href="../api/net/jini/security/AuthenticationPermission.html"> -<code>AuthenticationPermission</code></a> and -<a href="../api/net/jini/security/GrantPermission.html"> -<code>GrantPermission</code></a> to the proxy to permit activation calls -to succeed, or else statically grant sufficient -<code>AuthenticationPermission</code> to downloaded code in clients -to permit activation calls to succeed. -</dd> +<dt><b>None</b></dt> </dl> Modified: incubator/river/jtsk/trunk/doc/release-notes/browser.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/browser.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/browser.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/browser.html Tue Jan 5 15:52:15 2010 @@ -25,7 +25,7 @@ <center> <h1>Service Browser<br> -v2.1.1 Release Notes</h1> +v2.2.0 Release Notes</h1> </center> <HR> <UL> @@ -33,34 +33,9 @@ The Service Browser lets you discover lookup services and inspect the various services registered within those lookup services. -<H3>Changes since the v2.0.1 release</H3> +<H3>Changes since the v2.1.1 release</H3> <dl> -<dt><b>Service Starter support</b> -<dd>The Service Browser can now be run as a nonactivatable entity under -the Service Starter. -<p> -<dt><b>JAR File Changes</b> -<dd>The codebase for the Service Browser should now contain two URLs, the -first for <code>browser-dl.jar</code> and the second for -<code>jsk-dl.jar</code>. The <code>Class-Path</code> manifest attribute -for <code>browser.jar</code> now also includes <code>jsk-lib.jar</code>. -<p> -<dt><b>Security Policy File Changes</b> -<dd>The security policy file for the Service Browser must now grant -permissions to <code>jsk-lib.jar</code>. -<p> -<dt><b>Browsing JavaSpaces service entries</b> -<dd>The Service Browser can now browse the entries of a JavaSpaces -service that implements the -<a href="../api/net/jini/space/JavaSpace05.html"><code>JavaSpace05</code></a> -interface. -<p> -<dt><b>Configuration</b> -<dd>A new <code>exitActionListener</code> configuration entry has been added, -which can be used to set the action listener for the <b>Exit</b> item of the -<b>File</b> menu. The new class, -<a href="../api/com/sun/jini/example/browser/Browser.Exit.html"><code>Browser.Exit</code></a>, -is a simple action listener that calls <code>System.exit</code>. +<dt><b>None</b> </dl> </ul> <hr> Modified: incubator/river/jtsk/trunk/doc/release-notes/classdep.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/classdep.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/classdep.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/classdep.html Tue Jan 5 15:52:15 2010 @@ -25,7 +25,7 @@ <center> <h1><code>ClassDep</code><br> -v2.1.1 Release Notes</h1> +v2.2.0 Release Notes</h1> </center> <HR> <UL> Modified: incubator/river/jtsk/trunk/doc/release-notes/classserver.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/classserver.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/classserver.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/classserver.html Tue Jan 5 15:52:15 2010 @@ -25,7 +25,7 @@ <center> <h1><code>ClassServer</code><br> -v2.1.1 Release Notes</h1> +v2.2.0 Release Notes</h1> </center> <HR> <UL> @@ -33,18 +33,9 @@ <code>ClassServer</code> is a simple HTTP server for serving up JAR and class files. -<H3>Changes since the v2.0.1 release</H3> +<H3>Changes since the v2.1.1 release</H3> <dl> -<dt><b>Multiple Directory Support</b> -<dd>The class server can now serve up files from multiple directories. -The <code>-dir</code> (or <code>-dirs</code>) command line option -and the <code>dirlist</code> constructor parameter now accept a list -of directories to serve files from, with entries separated by the -system path-separator character. -<p> -<dt><b>Executable JAR file</b> -<dd>There is a new executable JAR file, <code>classserver.jar</code>, -that can be used to run the class server. +<dt><b>None</b></dt> </dl> </ul> <hr> Modified: incubator/river/jtsk/trunk/doc/release-notes/comsunjinithread.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/comsunjinithread.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/comsunjinithread.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/comsunjinithread.html Tue Jan 5 15:52:15 2010 @@ -26,7 +26,7 @@ <body text="black" bgcolor="white" link="#9b37cc" vlink="#cc1877" alink="white"> <center> <h1><code>com.sun.jini.thread</code> package<br> -v2.1.1 Release Notes</h1> +v2.2.0 Release Notes</h1> </center> <hr> <ul> @@ -38,70 +38,11 @@ the Apache River release. Some of these classes and interfaces are exposed via the configuration mechanism. -<H3>Changes since the v2.0.1 release</H3> - -A number of improvements have been made to the <a -href="../api/com/sun/jini/thread/WakeupManager.html"> -<code>com.sun.jini.thread.WakeupManager</code></a>. -<code>WakeupManager</code> instances are used to schedule tasks that need -to be run in the future. Many of the services and utilities in the release -obtain the required <code>WakeupManager</code> instances from their -configuration. <p> +<H3>Changes since the v2.1.1 release</H3> <dl> -<dt><b>The <code>WakeupManager.ThreadDesc</code> Class Can Now Be More -Usefully Subclassed and Has Been Made More Accessible</b> -<dd> -Instances of the <a -href="../api/com/sun/jini/thread/WakeupManager.ThreadDesc.html"><code> -<code>WakeupManager.ThreadDesc</code></a> class are used by -<code>WakeupManager</code> to create threads. A <code>ThreadDesc</code> -can be specified optionally when a <code>WakeupManager</code> is created, -and/or when a task is scheduled that needs to be run in its own thread. -The <a -href="../api/com/sun/jini/thread/WakeupManager.ThreadDesc.html#thread(java.lang.Runnable)"><code> -ThreadDesc.thread</code></a> method has been made public, which gives -subclasses of <code>ThreadDesc</code> complete control over how threads are -created and allows subclasses of <code>WakeupManager</code> to invoke -the <code> ThreadDesc.thread</code></a> method. -Also, public <a -href="../api/com/sun/jini/thread/WakeupManager.ThreadDesc.html#getGroup()"><code>getGroup</code></a>, -<a -href="../api/com/sun/jini/thread/WakeupManager.ThreadDesc.html#isDaemon()"><code>isDaemon</code></a>, -and <a -href="../api/com/sun/jini/thread/WakeupManager.ThreadDesc.html#getPriority()"><code>getPriority</code></a> -methods have been added to <code>ThreadDesc</code> and the default -implementation of <code>ThreadDesc.thread</code> has been changed to use -them. This work had been assigned issue numbers 5091282 and 6308590. -<p> - -<dt><b>Protected Factory Method for -<code>WakeupManager.Ticket</code>s Has Been Added to <code>WakeupManager</code></b> -<dd> - -When a task is added to a <code>WakeupManager</code>, the caller gets a <a -href="../api/com/sun/jini/thread/WakeupManager.Ticket.html"><code>WakeupManager.Ticket</code></a> -object than can be used to remove the task if necessary. The protected -method, <a -href="../api/com/sun/jini/thread/WakeupManager.html#newTicket"><code>WakeupManager.newTicket</code></a>, -has been added so subclasses of <code>WakeupManager</code> can create -<code>Ticket</code> instances. This work had been assigned issue number -6264220. -<p> - - -<dt><b><code>WakeupManager</code> Only Keeps Internal Thread Running When -There Are Tasks Pending</b> -<dd> - -Previous versions of <code>WakeupManager</code> always had one running -(though often waiting) thread even if there were no pending tasks. This -version of <code>WakeupManager</code> only creates its internal thread when -the first task is enqueued. It will let this thread end, after a -configurable timeout, if there are no tasks pending. This work had been -assigned issue number 6190278. -<p> +<dt><b>None</b></dt> </dl> Modified: incubator/river/jtsk/trunk/doc/release-notes/discovery.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/discovery.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/discovery.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/discovery.html Tue Jan 5 15:52:15 2010 @@ -25,7 +25,7 @@ <center> <h1>Jini Discovery Utilities<BR> -v2.1.1 Release Notes</h1> +v2.2.0 Release Notes</h1> </center> <HR> <UL> @@ -67,73 +67,12 @@ <a href="../specs/html/discoveryutil-spec.html">html</a>. <p> -<H3>Changes since the v2.0.1 release</H3> +<H3>Changes since the v2.1.1 release</H3> <dl> - <dt> <b>API additions and changes</b> - <dd> Changes to the <a href="../api/net/jini/discovery/package-summary.html"> - <code>net.jini.discovery</code></a> package. - <ul> - <li>Parsing of the input URL and host name arguments in the corresponding - <a href="../api/net/jini/discovery/ConstrainableLookupLocator.html"> - <code>ConstrainableLookupLocator</code></a> and - <a href="../api/net/jini/core/discovery/LookupLocator.html"> - <code>LookupLocator</code></a> constructors has been made stricter; - this may generate new <code>MalformedURLException</code>s. Note that - the implementation does not conform to the DJ 3.0 specification, which - requires parsing according to RFC 2396. The implementation is more - permissive and allows characters such as <code>'_'</code> in host names - to minimize backward incompatibility issues and anticipate compliance - with RFC 3986 (which obsoletes RFC 2396). - <li> - <code>ConstrainableLookupLocator</code> handles - <a href="../api/net/jini/core/constraint/ConnectionAbsoluteTime.html"> - <code>ConnectionAbsoluteTime</code></a> and - <a href="../api/net/jini/core/constraint/ConnectionRelativeTime.html"> - <code>ConnectionRelativeTime</code></a> constraints, enabling the - specification of timeouts on unicast discovery connection attempts. - <li> - <a href="../api/net/jini/discovery/LookupLocatorDiscovery.html"> - <code>LookupLocatorDiscovery</code></a> handles any - <code>ConnectionRelativeTime</code> and <code>ConnectionAbsoluteTime</code> - constraints that may be set on the <code>LookupLocator</code>s passed into its - constructors. - <li>The - <a href="../api/net/jini/discovery/LookupDiscovery.html"> <code>LookupDiscovery</code></a>, - <code>LookupLocator</code>, <code>ConstrainableLookupLocator</code>, and - <code>LookupLocatorDiscovery</code></a> classes now try all the IP addresses - that a given host name may resolve to, instead of just the first one. This is as per the - recommendations in RFC 1123. - </ul> - <p> - Changes to the <a href="../api/com/sun/jini/discovery/package-summary.html"> - <code>com.sun.jini.discovery</code></a> package. - <ul> - <li> - The <a href="../api/com/sun/jini/discovery/Discovery.html"> - <code>Discovery</code></a> class now enables constraint checking to be optionally - delayed. With this change, constraint checks need not be performed as part of multicast - announcement or request decoding. - Discovery providers that support delayed constraint checking must implement the new - <a href="../api/com/sun/jini/discovery/MulticastAnnouncementDecoder.html"> - <code>MulticastAnnouncementDecoder</code></a> - and <a href="../api/com/sun/jini/discovery/MulticastRequestDecoder.html"> - <code>MulticastRequestDecoder</code></a> interfaces. - <li> - The <a href="../api/com/sun/jini/discovery/DiscoveryConstraints.html"> - <code>DiscoveryConstraints</code></a> class supports processing of - <code>ConnectionRelativeTime</code> and <code>ConnectionAbsoluteTime</code> - constraints. Note that the processed constraints will no longer return - <code>ConnectionRelativeTime</code> and <code>ConnectionAbsoluteTime</code> - as unfulfilled constraints. - </ul> - <p> - - <dt> <b>Configuration</b> - <dd> The current implementation of the <code>LookupDiscovery</code></a> - utility now allows <code>ConnectionRelativeTime</code> and - <code>ConnectionAbsoluteTime</code> as part of its discovery constraints. - + <dt>None</dt> + </dl> + <!-- No issues for now <p> Modified: incubator/river/jtsk/trunk/doc/release-notes/fiddler.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/fiddler.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/fiddler.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/fiddler.html Tue Jan 5 15:52:15 2010 @@ -23,7 +23,7 @@ <a name="top"> <title>Release Notes for Fiddler</title> <center><h1>Fiddler - <BR>v2.1.1 Release Notes + <BR>v2.2.0 Release Notes </h1></center> <hr> <UL> @@ -41,130 +41,9 @@ <a href="../api/net/jini/admin/Administrable.html"> <code>net.jini.admin.Administrable</code></a>. <p> -<H3>Changes since the v2.0.1 release</H3> +<H3>Changes since the v2.1.1 release</H3> <dl> - - <dt> <b>Configuration</b> - <dd> In this release, no new configuration entries have been added, nor have any other - changes occurred with respect to the configuration. - <p> - A full list of supported configuration entries is given in this service's - <a href="../api/com/sun/jini/fiddler/package-summary.html#fiddlerConfigEntries"> man page</a>. - <p> - - <dt> <b>Logging</b> - <dd> In this release, no changes have occurred with respect to the logging mechanism - employed by Fiddler; which logs diagnostic information using a separate - <a href="http://java.sun.com/j2se/1.4/docs/api/java/util/logging/Logger.html"> <code>Logger</code></a> - for each type of information logged. The name of each logger - is a dot-separated concatenation of the implementation package name, - <code>com.sun.jini.fiddler</code>, with a descriptive string. A description of each - logger used by this service, as well as what information is logged to which - logger, and at what logging level, is given in this service's - <a href="../api/com/sun/jini/fiddler/package-summary.html#fiddlerLoggers"> man page</a>. - <p> - - <dt> <b>Bug Fixes of Interest</b> - <dd> A number of bugs have been addressed in this release of Fiddler. - What follows is a description of those bugs that might be of - interest: - <p> - - <dt><b>4874580: FiddlerImpl throws NullPointerException in prepareNewLocators if locs is null</b><dt> - <dd> When calling the <code>register</code> method, if <code>null</code> - is passed as the value of the <code>locators</code> parameter, - a <code>NullPointerException</code> occurs. - <p> - This bug has been fixed. - </dd> - <p> - <dt><b>4979612: Fiddler relies on LookupLocator.equals to determine interest in discovered Regs</b><dt> - <dd> When Fiddler searches through its set of client registrations to - determine if any of those registrations are interested in a particular - previously discovered lookup service, it compares the locators of - interest from each registration to the locator that is returned by a call - to <code>getLocator</code> on the discovered lookup service. That - comparison is done using <code>LookupLocator.equals</code>. - <p> - <code>LookupLocator.equals</code> employs a case-insensitive string - compare of the host names of the locators to determine equality. Thus, - if one locator is associated with a hostname of "myHost", - and the other locator is associated with a fully qualified hostname like - "myHost.myCompany.com", <code>LookupLocator.equals</code> will return - <code>false</code>, and Fiddler will view as different, locators that - should actually be considered the same. - <p> - To address this bug, the implementation in this release now employs - the same strategy that <code>URL</code> currently employs. That is, - it first applies <code>LookupLocator.equals</code> (to do a case-insensitive - string compare). If the call to <code>LookupLocator.equals</code> returns - <code>false</code>, then the IP addresses associated with each locator - are retrieved and compared to determine equality. - </dd> - <p> - <dt><b>4984939: Fiddler threads should guard against lost interrupts</b><dt> - <dd> Thread subclasses in Fiddler that use logging and do not override the - <code>Thread.interrupt</code> method to set an "interrupted" field are - susceptible to lost interrupts. This is because <code>java.util.logging</code> - swallows internal <code>InterruptedIOException</code>s without setting - the receiving thread's interrupted status; effectively 'forgetting' the - interrupt that occurred. The end result is that some of Fiddler's threads - could endlessly loop instead of terminate, causing shutdown processing - in Fiddler to hang. - <p> - This bug has been fixed. - </dd> - <p> - <dt><b>5042473: FiddlerImpl.SetLocatorsTask handles NO_LOCATORS incorrectly</b><dt> - <dd> Prior to this release, when a client requested that locator discovery - be "turned off" by requesting the replacement of a registration's - locators-of-interest with the empty set (through an invocation of - the <code>setLocators</code> method), the result was the opposite - of what the specification prescribes. That is, the - locators-of-interest were <b>not</b> qgross@example.net. - <p> - This bug has been fixed. - </dd> - <p> - <dt><b>5049735: Fiddler should properly handle remote calls that arrive before init completes</b><dt> - <dd> Prior to this release, Fiddler contained no logic to ensure that - remote calls received before initialization completes would be handled - properly. Problems could occur, for example, if an instance of Fiddler is - run with a well-known endpoint that was used (and advertised) by a - previous instance of Fiddler. - <p> - To address this issue, Fiddler now handles such "early" calls by blocking - until initialization completes. - </dd> - <p> - <dt><b>6226306: Fiddler should allow null loginContext config entry, performing no JAAS login when null</b><dt> - <dd> Prior to this release, if Fiddler's configuration included a - <b><i>loginContext</i></b> entry, Fiddler would require that - entry to be non-<code>null</code>; throwing an exception if - a <code>null</code> value were entered. (Note that if the entry - were simply absent from the configuration, Fiddler interpretted - this as an indication that no JAAS login should be performed.) - <p> - To address this issue, Fiddler now interprets a <code>null</code> - value for the <i>loginContext</i> entry, as well as an absent - entry, as an indication that a JAAS login should not be performed. - </dd> - <p> - <dt> <b>Notes Of Interest</b> - <dd> - <p> - <b>Fiddler Has 3 Modes of Execution</b> - <p> - <ul> - <li> <i>Transient</i> - Fiddler does not persist its state and is not activatable - <li> <i>Nonactivatable</i> - Fiddler does persist its state but is not activatable - <li> <i>Activatable</i> - Fiddler persists its state and is activatable - </ul> - For details, see the - <a href="../api/com/sun/jini/fiddler/package-summary.html"> <code>com.sun.jini.fiddler</code></a> - package documentation. - <p> - + <dt> <b>None</b></dt> </dl> <!-- No issues for now Modified: incubator/river/jtsk/trunk/doc/release-notes/index.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/index.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/index.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/index.html Tue Jan 5 15:52:15 2010 @@ -17,14 +17,14 @@ !--> <html lang="en-US"> <head> -<title>Apache River Release Notes, v2.1.1</title> +<title>Apache River Release Notes, v2.2.0</title> </head> <body text="#000000" bgcolor="#ffffff" link="#9b37cc" vlink="#cc1877" alink="#ffffff"> <center> <h1><a name="TOP">Apache River -<br>v2.1.1 Release Notes</a></h1></center> +<br>v2.2.0 Release Notes</a></h1></center> <p> <hr> Apache River is an effort undergoing incubation at The Apache Software @@ -55,7 +55,7 @@ <ul> <li>NOTICE file and source license headers updated </li> <li>Source and documentation updated for release name ("Apache - River release") and version ("v2.1.1") </li> + River release") and version ("v2.2.0") </li> <li> Graphical installer (which was a 3rd party application in the Starter Kit) is no longer available</li> <li>The combined source and binary release in the Starter Kit has Modified: incubator/river/jtsk/trunk/doc/release-notes/jeri.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/jeri.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/jeri.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/jeri.html Tue Jan 5 15:52:15 2010 @@ -25,7 +25,7 @@ <center> <h1><code>net.jini.jeri</code><br> -v2.1.1 Release Notes</h1> +v2.2.1 Release Notes</h1> </center> <HR> <UL> @@ -36,74 +36,11 @@ package and its subpackages provide APIs for Jini extensible remote invocation (Jini ERI) and several Jini ERI transport layer providers. -<H3>Changes since the v2.0.1 release</H3> +<H3>Changes since the v2.1.1 release</H3> <dl> -<dt><b>Multihomed host support</b></dt> -<dd> -<p>As recommended by RFC 1123, the transport endpoints now attempt connections -to all the IP addresses that a given host name may resolve to, instead of just -the first one. -</dd> - -<dt><b>Trust verification restriction</b> -<dd><p><a -href="../api/net/jini/jeri/BasicJeriTrustVerifier.html"><code>BasicJeriTrustVerifier</code></a> -has been changed to trust fewer dynamic proxies. In particular, in addition to -implementing -<a href="../api/net/jini/core/constraint/RemoteMethodControl.html"><code>RemoteMethodControl</code></a>, -the dynamic proxy must now implement one or more well-formed remote interfaces -(ones that extend <code>Remote</code> and for which all methods declare -<code>RemoteException</code> or a superclass in their throws clause), and -must not implement any other interfaces except -<a href="../api/net/jini/security/proxytrust/TrustEquivalence.html"><code>TrustEquivalence</code></a>. -</dd> - -<dt><b>New <code>BasicJeriTrustVerifier</code> <code>protected</code> -methods</b> - -<dd><p><a -href="../api/net/jini/jeri/BasicJeriTrustVerifier.html"><code>BasicJeriTrustVerifier</code></a> -has five new <code>protected</code> methods to allow for more -convenient implementation of certain behaviors through subclassing: - -<ul> - -<li><a -href="../api/net/jini/jeri/BasicJeriTrustVerifier.html#hasTrustedProxyClass(java.lang.Object,%20net.jini.security.TrustVerifier.Context)"><code>hasTrustedProxyClass</code></a> -can be overridden by subclasses to control which dynamic proxy classes for -Jini ERI proxies are considered locally trusted. - -<li><a -href="../api/net/jini/jeri/BasicJeriTrustVerifier.html#hasTrustedClassLoader(java.lang.Object,%20net.jini.security.TrustVerifier.Context)"><code>hasTrustedClassLoader</code></a> -can be overridden by subclasses to control the set of class loaders -for which the class of a Jini ERI proxy, when defined by one of those -loaders, is considered locally trusted. - -<li><a -href="../api/net/jini/jeri/BasicJeriTrustVerifier.html#isTrustedProxyInterface(java.lang.Class,%20net.jini.security.TrustVerifier.Context)"><code>isTrustedProxyInterface</code></a> -can be overridden by subclasses to control which dynamic proxy interfaces for -Jini ERI proxies are considered locally trusted. - -<li><a -href="../api/net/jini/jeri/BasicJeriTrustVerifier.html#isTrustedInvocationHandler(java.lang.reflect.InvocationHandler,%20net.jini.security.TrustVerifier.Context)"><code>isTrustedInvocationHandler</code></a> -can be overridden by subclasses to support verification of invocation -handlers that have a locally trusted class other than <a -href="../api/net/jini/jeri/BasicInvocationHandler.html"><code>BasicInvocationHandler</code></a> -(such as a subclass of <code>BasicInvocationHandler</code>). - -<li><a -href="../api/net/jini/jeri/BasicJeriTrustVerifier.html#checkInvocationHandlerContent(net.jini.jeri.BasicInvocationHandler,%20net.jini.security.TrustVerifier.Context)"><code>checkInvocationHandlerContent</code></a> -can be invoked by subclasses that override -<code>isTrustedInvocationHandler</code> to perform the verification -steps that the default implementation of -<code>isTrustedInvocationHandler</code> would perform, except that the -class of the invocation handler is not required to be -<code>BasicInvocationHandler</code> exactly, so that trusted -subclasses can be supported. - -</ul> +<dt><b>None</b></dt> </dl> Modified: incubator/river/jtsk/trunk/doc/release-notes/join.html URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/join.html?rev=896106&r1=896105&r2=896106&view=diff ============================================================================== --- incubator/river/jtsk/trunk/doc/release-notes/join.html (original) +++ incubator/river/jtsk/trunk/doc/release-notes/join.html Tue Jan 5 15:52:15 2010 @@ -24,7 +24,7 @@ <title>Jini Join Utilities Release Notes</title> <center><h1>Jini Join Utilities - <BR>v2.1.1 Release Notes + <BR>v2.2.0 Release Notes </h1></center> <HR> <UL> @@ -46,176 +46,11 @@ which is available in <a href="../specs/html/joinutil-spec.html">html</a>. <p> -<H3>Changes since the v2.0.1 release</H3> +<H3>Changes since the v2.1.1 release</H3> <dl> - <dt> <b>Configuration</b> - <dd> A new configuration entry has been added to the join manager implementation - in this release: <b>maxLeaseDuration</b>. - <p> - This new entry allows one to configure the maximum lease duration - (in milliseconds) that is requested from each discovered lookup service - on behalf of the service; both when the lease is initially requested, - as well as when renewal of that lease is requested. Thus, as this value - is made smaller, renewal requests will be made more frequently while the - service is up, and lease expiration will occur sooner when the service - goes
{'source': 'Apache Software Foundation Public Mail Archives'}