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 15:31:39 GMT
   Date: 2004-06-24T08:31:39
   Editor: HowardLewisShip <hlship@apache.org>
   Wiki: Jakarta HiveMind Wiki
   Page: UsingJNDIToObtainHiveMindServices
   URL: http://wiki.apache.org/jakarta-hivemind/UsingJNDIToObtainHiveMindServices

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -1,8 +1,13 @@
+#pragma section-numbers off
+
 = Q.  Using JNDI To Obtain HiveMind Services =
 ''(DanielFeist 24/06/2004)'' 
 
 
-I have been experimenting with the use of JNDI as a facade to HiveMind by implementing a
simple JNDI SPI. The lookup method of a JNDI Context takes just a Name, yet to obtain a HiveMind
service i need to be able to specifiy the interface expected. What i have found is that i
can, in place of the interface expected put Object.class and everything works ok. Object is
not an interface so i'm not quite sure why this works. Is this intentional? Will HiveMind
continue to support this?
+I have been experimenting with the use of JNDI as a facade to !HiveMind by implementing a
simple JNDI SPI. The lookup method of a JNDI Context takes just a Name, yet to obtain a !HiveMind
service i need to be able to specifiy the interface expected. What i have found is that i
can, in place of the interface expected put Object.class and everything works ok. Object is
not an interface so i'm not quite sure why this works. Is this intentional? Will !HiveMind
continue to support this?
 
 == A. ==
 
+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.

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