We used a similar approach but our global, static, factory was hidden behind a JNDI object provider (lighweight, doesn't require any app server resources). Then in all our non-Service code we perform initial context lookups on the Service interface. (patch for this feature has been provided in HIVEMIND-30).
The is took our entire .ear file's dependency on HIvemind down to zero (except where we wished to actually use Hivemind provided services such as BeanFactory and ThreadEventNotifier). This way we can write apps that only have dependencies on the service interface and the strategy for providing them can be plugged in (the client can be unit tested without hivemind - just like the service implementations). We also found that in general non service code lookups of interfaces be they web services, ejbs, or hivemind services started to all look the same. Perhaps there can be some "grand unified lookup" similar to "grand unified logging interface" from log4j discussions? ----- Original Message ----- From: Pablo Lalloni <[EMAIL PROTECTED]> Date: Fri, 03 Sep 2004 10:34:53 -0300 Subject: RE: Thoughts on how to put Hivemind inside a J2EE Container or Web Container? To: "[email protected]" <[email protected]> Cc: Jian Wu <[EMAIL PROTECTED]> We used to go the servlet-filter way but not any more... it's not useful enough for a multi-artifact J2EE app with various wars, ejbs, sars, etc.. So we currently have an MBean that takes care of the registry lifecycle by building it, putting it on a static holder and firing a "startup event" on it so services that need to do something can. Later when the MBean is stopped/undeployed, it also sends the appropriate event to the registry (and its contained services). This way we have the advantage of using the MBean class loader to get all hivemodule descriptors, with the servlet filter approach you need to get in the war class loader all descriptors even if the webapp will never need to have that modules on its classpath. For the "static holder" we made a class with the same interface as org.apache.hivemind.Registry but with all the methods being static and delegating its execution to a static field that contains the real registry, it also has the needed lifecycle event firing methods to be invoked from the MBean. El jue, 02-09-2004 a las 22:51, James Carman escribi�: There is a servlet filter (http://jakarta.apache.org/hivemind/filter.html) built into the HiveMind framework that will put a HiveMind registry (the "default registry") on each servlet request as it comes in. Then, your servlets can use the HiveMind-managed services by looking them up in the registry... // Inside your servlet... Registry registry = HiveMindFilter.getRegistry( request ); MyService svc = ( MyService )registry.getService( MyService.class ); svc.someServiceMethod( someParameter ); -----Original Message----- From: Jian Wu [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 9:19 PM To: [email protected] Subject: Thoughts on how to put Hivemind inside a J2EE Container or Web Container? Hi, Usually, J2EE/Web Container will instantiate EJB/Servlet Object for you. Now, Hivemind will also instantiate these service object. To integrate these two together, I can think that Hivemind is invoked through ServletContextListener to set up the basic services before Servlet get instantiated. Any suggestion or best practice? Thanks a lot! Jian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pablo I. Lalloni <[EMAIL PROTECTED]> Tel�fono +54 (11) 4347-3177 Proyecto Cuenta Corriente Tributaria Direcci�n Inform�tica Tributaria AFIP > In 2010, M$ Windows will be a quantum processing emulation layer for a > 128-bit mod of a 64-bit hack of a 32-bit patch to a 16-bit GUI for an > 8-bit operating system written for a 4-bit processor from a 2-bit > company that can't stand 1 bit of competition. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
