Gotcha. I'll do as you suggest. I myself don't like to be prohibited
from doing things, even if they're "not ideal". So in a way I was a
little hipocrytic.
I will use hivemind throughout, promote DAO usage thru it, but getting
specific instance of a dao will be technically possible. I will go the
documentation route.
Thanks again,
Adam
On 3/16/06, Mike Snare <[EMAIL PROTECTED]> wrote:
> Maybe James' approach will work, I'm not sure.
>
> I will say this. If you're writing a library that will be used
> outside your organization you'll have a tough time making sure people
> use it right. Spend some extra time documenting the proper use and
> move on to the next thing on your list.
>
> If what you're really worried about is other people within your
> organization using the APIs incorrectly you can use a tool like PMD to
> enforce correct usage.
>
> -Mike
>
> On 3/16/06, Adam Zimowski <[EMAIL PROTECTED]> wrote:
> > Well, the restriction I'm trying to impose is that entire codebase
> > refernces DAO interfaces only. The goal I'm striving to achieve, is
> > not to have a single place in the entire codebase where specific DAO
> > instance is used.
> >
> > The application will be open source, and eventually it will be harder
> > and harder to check the incomming code for usage of specific instances
> > of DAOs. A far better way would be to flat out prohibit getting a
> > specific instance, and allow it only thru Hivemind.
> >
> > I could be totally wrong with what I'm trying to achieve. But because
> > the application eventually will be large, I think it would be very
> > beneficial to use DAOs only thru interfaces within the codebase.
> >
> > Adam
> >
> > On 3/16/06, Mike Snare <[EMAIL PROTECTED]> wrote:
> > > 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]
> >
> >
>
> ---------------------------------------------------------------------
> 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]
