--- Bob Lee <[EMAIL PROTECTED]> wrote:

> On 2/26/07, Konstantin Priblouda
> <[EMAIL PROTECTED]> wrote:
> >
> > Hi Bob,
> > I'd like to say that I'm codeveloper of
> > pico/nanocontainer.
> 
> 
> I've used Pico and Nano. Nano uses my AOP framework.
> You should try Guice.

It's dificult to keep track on all the people ;)



> 
> Using these key objects is more verbose than using
> annotations with Guice.

Not necessarily.  There are no references to keys in
my code,  only in container buildup.  And only in
cases where this is necessary.  Pico can autowire
objetcs if there is no ambiguity. 

And annotation introduces explicit dependency to
framework - kind of uncool. 


> > Basically I just register this session component -
> > and my HibernateUserManager receives it in
> > constructor.
> >
> > Why do I need an annotation to achieve this?
> 
> 
> The annotation indicates which constructor you want
> injected (to the
> framework as well as other programmers). What
> happens if you forget to
> configure a PasswordHasher in Pico? No hashing?
> That's not very secure.

In this particular case ( as there is ocnstructor 
which uses default hasher ) default hasher will be
used. ( which is in  turn empty hasher, but can be
changed to MD5, I think I will do this right now, 
thanks for pointing ) 

If I choose to not to provide such constructor - 
then container can not instantiate this component -
there will be an ugly telling you to provide 
dependency.


> If you can't annotate a constructor (because you
> don't control the code),
> you can use a custom provider. For example:
> 
> class HibernateUserManagerProvider implements
> Provider<HibernateUserManager>
> {
>   @Inject Session session;
>   @Inject PasswordHasher passwordHasher;
>   public HibernateUserManager get() {
>     return new HibernateUserManager(session,
> passwordHasher);
>   }
> }

Well, in pico I do not need to write such provider
at all. I can just register component in container and
let pico guess ( not pico to be honest, but component
adapter in question ).  If default behaviour does not
suit me ( say, I have more than one hibernate session
)
I'll have to resolve ambiguity by configuration:

------------%<---------------
     <!--
        security and user management components
    -->

    <implementation key="securitySession"
class="org.nanocontainer.persistence.hibernate.FailoverSessionDelegator">
        <dependency key="userSessionFactory"/>
    </implementation>

    <implementation key="securityLifecycle"
class="org.nanocontainer.persistence.hibernate.SessionLifecycle">
        <dependency key="securitySession"/>
    </implementation>


    <!--
        user manager
    -->
    <implementation key="userManager"
class="de.jtec.user.hibernate.HibernateUserManager">
        <dependency key="securitySession"/>
        <dependency key="hasher"/>
    </implementation>
   
--------------%<----------------

( if there is only one hasher & session - just leave
dependecies out ) 

Now any WW2/S2 action wishing to have reference to 
UserManager needs to declare it as constructor
parameter.

> Well, there is still a question why it is better
> than
> > pico ;)
> 
> 
> Write less code, and get better up front checking
> and better performance.
> What more do you want?

No that less code...  But I would take a closer look
tonight.

> Bob

Konstantin

PS: is project space on code.google.com available only
for employees or also for mere mortals? 

regards,



----[ Konstantin Pribluda http://www.pribluda.de ]----------------
Still using XDoclet 1.x?  XDoclet 2 is released and of production quality.
check it out: http://xdoclet.codehaus.org


 
____________________________________________________________________________________
Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to