tapestry-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: POJO dependency injection (with interface) into TAP4 application
Date Thu, 16 Mar 2006 16:48:54 GMT
The good thing is HiveMind enforces the interface requirement for you.  If
you put your DAOs into a module that only exposes them via their interfaces,
then they can only access them via their interfaces.  That's one of the
benefits of HiveMind is that it only lets you access the objects via their
"service interface", since it generates a proxy from the interface and
doesn't really give you the actual implementation object.  Note: if you use
bean-based services (which we don't suggest), this all goes out the window.
The bean class is extended to create the proxy class, so you pretty much
have access to anything the implementation object can do.

-----Original Message-----
From: Mike Snare [mailto:mikesnare@gmail.com] 
Sent: Thursday, March 16, 2006 11:45 AM
To: Tapestry users
Subject: Re: POJO dependency injection (with interface) into TAP4
application

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 <zimowski74@gmail.com> 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 <mikesnare@gmail.com> 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 <zimowski74@gmail.com> 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 <mikesnare@gmail.com> 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 <zimowski74@gmail.com> 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 <mikesnare@gmail.com> 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 <zimowski74@gmail.com> 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 <mikesnare@gmail.com> 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 <mikesnare@gmail.com>
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 <zimowski74@gmail.com>
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
<kristian.marinkovic@porsche.co.at> wrote:
> > > > > > > > > > > hi Adam,
> > > > > > > > > > >
> > > > > > > > > > > @InjectState("sessionDAO")
> > > > > > > > > > > public abstract ISessionDAO getSessionDAO();
> > > > > > > > > > >
> > > > > > > > > > > works fine too; i'm using it with tapestry-spring
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >              "Adam Zimowski"
> > > > > > > > > > >              <zimowski74@gmail
> > > > > > > > > > >              .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
> > > > > > > > > > >              <tapestry-user@ja
> > > > > > > > > > >              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:
tapestry-user-unsubscribe@jakarta.apache.org
> > > > > > > > > > > For additional commands, e-mail:
tapestry-user-help@jakarta.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail:
tapestry-user-unsubscribe@jakarta.apache.org
> > > > > > > > > > > For additional commands, e-mail:
tapestry-user-help@jakarta.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail:
tapestry-user-unsubscribe@jakarta.apache.org
> > > > > > > > > > For additional commands, e-mail:
tapestry-user-help@jakarta.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
tapestry-user-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail:
tapestry-user-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
tapestry-user-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail:
tapestry-user-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
tapestry-user-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
tapestry-user-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
tapestry-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
tapestry-user-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
tapestry-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Mime
View raw message