hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hivemind-...@jakarta.apache.org
Subject [Jakarta HiveMind Wiki] Updated: UsingJNDIToObtainHiveMindServices
Date Thu, 24 Jun 2004 16:13:21 GMT
   Date: 2004-06-24T09:13:21
   Editor: 200.69.248.193 <>
   Wiki: Jakarta HiveMind Wiki
   Page: UsingJNDIToObtainHiveMindServices
   URL: http://wiki.apache.org/jakarta-hivemind/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: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org


Mime
View raw message