hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Jakarta HiveMind Wiki] Updated: UsingJNDIToObtainHiveMindServices
Date Thu, 24 Jun 2004 16:13:21 GMT
   Date: 2004-06-24T09:13:21
   Editor: <>
   Wiki: Jakarta HiveMind Wiki
   Page: UsingJNDIToObtainHiveMindServices

   no comment

Change Log:

@@ -11,3 +11,5 @@
 HowardLewisShip: Yes, this will continue work.  The idea of passing in the expected (assignable)
type is to allow !HiveMind to do a check that the service object or proxy returned is assignable.
Better a good message from inside !HiveMind than a bad !ClassCastException. Using {{{java.lang.Object}}}
is acceptible if you don't care about that test. 
 I think it's a very good idea, where practical, to do this extra step ... it supports the
''Feedback'' principle. This is insurance against a change to a 3rd party library where an
existing service's interface is changed (a bad idea!). Your existing code will fail ... but
fail with a more sophisticated message. This is why I would object to a convienience method
that takes just a service name.
+DanielFeist:  I agree completly and don't think the addition of another method which takes
just the service-id is a good idea.  I just wanted to know if the passing of {{{Object.class}}}
is acceptable if there is a situation, like in the example I gave or similair, where it is
not possible to pass the interface expected.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message