Date: 2004-06-24T08:31:39
Editor: HowardLewisShip <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
