To answer some of your original questions... 2. Yes, HiveMind will give you a singleton back by default unless you specify that it's otherwise.
3. HiveMind does not currently have JDK5 annotation support. However, that's on the list of enhancements. Why are you injecting a DAO as an ASO? It's not a "state" object. It's a service (especially if you want it to be a singleton). Use the example I provided and creating DAOs in Tapestry will be VERY easy for you. Then, you can inject them into pages, component, or any other service managed by HiveMind. Enjoy! -----Original Message----- From: Mike Snare [mailto:[EMAIL PROTECTED] Sent: Thursday, March 16, 2006 11:23 AM To: Tapestry users Subject: Re: POJO dependency injection (with interface) into TAP4 application Hmm... If you make it a singleton, it's a singleton. It shouldn't really matter whether or not they access it via hivemind or directly, should it? Not sure I see much point in the exception if you make it a singleton. It won't matter how they access it -- it will always be the same instance. I think the question is, does it really *need* to be a singleton or are you trying to impose an arbitrary restriction. If it really *needs* to be a singleton then make it so and move on. Accessing it via hivemind becomes of secondary importance at that point. On 3/16/06, Adam Zimowski <[EMAIL PROTECTED]> wrote: > You're awesome. Thanks much, you clearly know this stuff well. > > I think I got 99% of what I was looking for from your answer. I'll > reply to this post with my working solution later today. > > Then, ideally what I will try is to figure out some way that if > developer tries this: > > SessionDAO dao = SessionDAO.getInstance(); > > they would get ForbiddenInvocationException or something like that. > Have you seen such approach? > > Adam > > On 3/16/06, Mike Snare <[EMAIL PROTECTED]> wrote: > > Of course, you could make the dao implementation an *actual* singleton. > > > > The purpose of the 'singleton' service model in hivemind is, as I > > understand it, to avoid needless re-creation of objects when such > > re-creation is not necessary, and NOT to provide the protection > > features of a standard java singleton. If that's correct than it's a > > bit of a misnomer, IMHO. > > > > If what you REALLY want is an object that is guaranteed to be a > > singleton no matter what, than fall back on standard java and make it > > a singleton. You can still access the singleton using some other > > hivemind service and return it. > > > > It depends on what you want to say about your library: if the > > 'proper' use is to bootstrap the registry to get the service (and the > > DAO) then it may be fine to have the DAO be a simple POJO. Failure to > > access the DAO via hivemind is a misuse of the library and the user > > gets whatever failures they deserve. If, however, it is acceptable > > (and/or expected) that the user will access the object outside of > > hivemind you may want to make it a proper singleton. > > > > As to the session issue -- yeah, I misunderstood. The simple answer > > is to just return SessionDAOImpl.Instance() -- assuming you made it an > > instance. In that scenario the request is unnecessary. The exists() > > method may be unnecessary too, I was just trying to sort of mimic the > > functionality available in standard ASO usage. > > > > On 3/16/06, Adam Zimowski <[EMAIL PROTECTED]> wrote: > > > Thank you very much Mike. I like the concept, and your point is right > > > on the money. I want to force other developers to use Hivemind to > > > obtain ISessionDAO, not the specific implementation. > > > > > > In your example my dao would be stored inside the session. Is there a > > > reason for this? I would prefer it to be a singleton, and not create a > > > session just to get the DAO. My session DAO is to provide session > > > persistence in the clustered environment, I didn't mean it to live > > > inside the session. I'm sorry if that may have been confusing, I could > > > have used another dao name, like MemberDAO and IMemberDAO. > > > > > > Anyway, I will play with your example and try to change it so that it > > > doesn't use the session. > > > > > > One last question. Let's assume I have it wired such that Hivemind > > > retuns IMemberDAO or whatever other DAO interface I specify. If my DAO > > > implementations live in some package as part of the application, what > > > there to prevent other developers from doing inevitable: > > > > > > SessionDAO dao = new SessionDAO(); > > > MemberDAO dao = new MemberDAO(); > > > etc... > > > > > > I really would like to prohibit this kind of thing totally. There may > > > be developers not familiar with IOC that would do this kind of thing, > > > yet if it weren't possible they would eventually find the right way > > > (the IOC way) to do this type of thing. > > > > > > Sincere Regards, > > > Adam > > > > > > On 3/16/06, Mike Snare <[EMAIL PROTECTED]> wrote: > > > > Try this... > > > > > > > > In hivemodule.xml: > > > > > > > > <service-point id="daoprovider" interface="com.yourcompany.ISessionDAOProvider"> > > > > <invoke-factory> > > > > <construct class="com.yourcompany.impl.SessionDAOProviderImpl" /> > > > > </invoke-factory> > > > > </service-point> > > > > > > > > ISessionDAOProvider.java: > > > > > > > > public interface ISessionDAOProvider { > > > > public ISessionDAO getDAO(); > > > > public boolean getDAOExists(); > > > > } > > > > > > > > SessionDAOProviderImpl.java: > > > > > > > > public class SessionDAOProviderImpl implements ISessionDAOProvider { > > > > > > > > private static final String DAO_KEY = "DAO_KEY"; > > > > > > > > /** > > > > * HiveMind provides you with a proxy for the real request so that every time > > > > * you call a method on it it gets routed to the request that is associated > > > > * with the current thread. magic... > > > > */ > > > > private HttpServletRequest req; > > > > > > > > public SessionDAOProviderImpl(HttpServletRequest req) { > > > > this._req = req; > > > > } > > > > > > > > /** > > > > * retrieves the DAO from the session, creating it if it doesn't exist yet. > > > > */ > > > > public ISessionDAO getDAO() { > > > > if (!exists()) { > > > > // ideally the implementation class would be specified externally... > > > > req.getSession().addAttribute(DAO_KEY, new SessionDAOImpl()); > > > > } else { > > > > return (ISessionDAO) req.getSession().getAttribute(DAO_KEY); > > > > } > > > > } > > > > > > > > public boolean getDAOExists() { > > > > return req.getSession().getAttribute(DAO_KEY) != null; > > > > } > > > > } > > > > > > > > Wherever you need the ISessionDAO, just inject the daoprovider service > > > > and call getDAO... > > > > > > > > It's not ideal because you are sort of rolling your own persistence, > > > > but it achieves the goal of hiding the implementation of the dao, and > > > > I don't know of another way to do that. > > > > > > > > -Mike > > > > > > > > On 3/16/06, Adam Zimowski <[EMAIL PROTECTED]> wrote: > > > > > How could I do this? I don't know Hivemind very well, yet because it's > > > > > integrated with Tapestry I highly prefer it over Spring IOC. Any > > > > > chance you may have an example? > > > > > > > > > > On 3/16/06, Mike Snare <[EMAIL PROTECTED]> wrote: > > > > > > By the way, if any tap developers are reading this, it would be great > > > > > > if you could declare an interface for an ASO similar to the way you > > > > > > can for a service... > > > > > > > > > > > > -Mike > > > > > > > > > > > > On 3/16/06, Mike Snare <[EMAIL PROTECTED]> wrote: > > > > > > > That will work, but doesn't enforce your intent on other developers > > > > > > > (they would be free to inject the ASO as a SessionDAO and not an > > > > > > > ISessionDAO). Perhaps a better way would be to create a service whose > > > > > > > sole purpose would be to retrieve an instance of the ISessionDAO from > > > > > > > the ApplicationStateManager, which can be auto-wired to your > > > > > > > ISessionDAORetriever service. Noone would then know the type. > > > > > > > > > > > > > > -Mike > > > > > > > > > > > > > > On 3/16/06, Adam Zimowski <[EMAIL PROTECTED]> wrote: > > > > > > > > Silly me :-) How simple and elegant ! I've been thinking in the > > > > > > > > spring context, yet Tap/Hivemind make it so simple.. > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > On 3/16/06, Kristian Marinkovic <[EMAIL PROTECTED]> wrote: > > > > > > > > > hi Adam, > > > > > > > > > > > > > > > > > > @InjectState("sessionDAO") > > > > > > > > > public abstract ISessionDAO getSessionDAO(); > > > > > > > > > > > > > > > > > > works fine too; i'm using it with tapestry-spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Adam Zimowski" > > > > > > > > > <[EMAIL PROTECTED] > > > > > > > > > .com> An > > > > > > > > > "Tapestry users" > > > > > > > > > 16.03.2006 14:11 <tapestry-user@jakarta.apache.org> > > > > > > > > > Kopie > > > > > > > > > > > > > > > > > > Bitte antworten Thema > > > > > > > > > an POJO dependency injection (with > > > > > > > > > "Tapestry users" interface) into TAP4 application > > > > > > > > > <[EMAIL PROTECTED] > > > > > > > > > karta.apache.org> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > I'd like to inject my DAOs from Hivemind as an interface such that my > > > > > > > > > app is not aware of implementation. I only know I can do this: > > > > > > > > > > > > > > > > > > <contribution configuration-id="tapestry.state.ApplicationObjects"> > > > > > > > > > <state-object name="sessionDAO" scope="application"> > > > > > > > > > <create-instance class="data.dao.SessionDAO"/> > > > > > > > > > </state-object> > > > > > > > > > </contribution> > > > > > > > > > > > > > > > > > > Then, in my class I'd do: > > > > > > > > > > > > > > > > > > @InjectState("sessionDAO") > > > > > > > > > public abstract SessionDAO getSessionDAO(); > > > > > > > > > > > > > > > > > > I have a few problems with this: > > > > > > > > > > > > > > > > > > 1) I'd like to inject an interface ISessionDAO, not the concrete > > > > > > > > > implementation. > > > > > > > > > > > > > > > > > > 2) Question: will Hivemind give me a singleton? I don't want my DAO's > > > > > > > > > be a bunch of short lived objects. I'd like to be sure they are > > > > > > > > > singletons. I think they are because the scope is application, but I'm > > > > > > > > > not sure. > > > > > > > > > > > > > > > > > > 3) I'd like to be able to inject it to other POJOs, not just Tapestry > > > > > > > > > derived objects (pages, components, etc). I probably could use > > > > > > > > > Registry object, but I really prefer to do this with annotations? They > > > > > > > > > are so elegant.. Does Hivemind has annotation support ? > > > > > > > > > > > > > > > > > > As always, I appreciate your help up front. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Adam > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
