This sounds good, Igor. But I have a question.
If I only use EJB 3.0/JPA with http://code.google.com/p/fdiotalevi/ (no Spring, no Guice, no Salve), then how would I let a session object hold on to references to services and yet remain lightweight? Is there any information about best Wicket practices, patterns for session objects and pages that need EJB references? What would be in your opinion the most robust approach to this starting with the technologies that I am already using? Would it be better to use look-ups like InitialContext#lookup("java:comp/env/.....");instead of @EJB injection? I thought Wicket and EJB 3.0 makes a fairly robust and compact and easy to learn set of technologies, but I understand your concerns, and I have been looking for an answer in this area for a while. I use @EJB session bean injection in pages but I wonder what happens to the references as these are pooled resources that have a price. Many thanks, Bernard On Tue, 28 Apr 2009 23:42:02 -0700, you wrote: >there is absolutely nothing wrong with having authenticate() on >session. this kind of thinking is exactly what is wrong with the >current state of java technology. > >session is an object in wicket, why should it fall prey to the anemic >data model antipattern? why should it contain data only and no >behavior? > >what looks better? > >session.setuserid(long id); >session.getuserid(); > >or > >session.authenticate(credentials cred); >session.getuserid(); > >the former has absolutely no encapsulation or protection of data, >anyone can set whatever id they want via a simple call to setuserid(). >the latter properly encapsulates the user id and protects against code >abuse. > >there are a number of technologies that allow you to break out of the >anemic data model mold by allowing, in this case the session, objects >to hold on to references to services and yet remain lightweight. > >wicket provides the lightweight serializable proxies which can be used >inside any object. > >class mysession extends websession { > @SpringBean/@Inject > private SessionFactory sf; > private long id; <== id is private with no direct setter > public mysession(webrequest req) { > super(req); > injectionholder.getinjector().inject(this); <== injects sf var > } > public void authenticate(credentials creds) throws AuthException { > user u=sf.getnamedquery("auth").......... > id=u.getid(); > } > >salve.googlecode.com removes the reference field altogether and >rewrites field access with a lookup. > >class mysession extends websession { > @Dependency > private SessionFactory sf; <== field will be removed via bytecode >instrumentation leaving the session object lightweight and >serializable > private long id; <== id is private with no direct setter > public mysession(webrequest req) { > super(req); > } > public void authenticate(credentials creds) throws AuthException { > user u=sf.getnamedquery("auth") <== this access to the removed sf >field will be rewritten as a lookup from configured ioc container > ....... > id=u.getid(); > } > >-igor > >On Tue, Apr 28, 2009 at 9:49 PM, Marc Ende <mli...@e-beyond.de> wrote: >> Hmm... I'm not sure why it's done this way in the >> AuthenticatedWebSession but >> nevertheless it's the only task of a session object to keep informations >> between >> two requests. From this point of view a authenticate(String,String) >> doesnt' really >> make sense in the Class. May be there is someone here who can explain this >> point. I wouldn't say that this is wrong, but unusual... :) >> >> May be you can get the database connection from inside the method for >> authentication purposes, >> Then you haven't got any private or public members which should be >> serialized and contains a database connection. >> >> m. >> >> >> Jan Torben Heuer schrieb: >>> Marc Ende wrote: >>> >>> >>>> webapps do. In this case you've got to serialize the connection. I don't >>>> think that's easy/possible to seralize a database connection. >>>> I would go another approach which uses the session only as a >>>> information-container and get those needed information from the >>>> database in the page-lifecycle. That keeps the session-object small >>>> (which is also an aspect). >>>> >>> >>> Hmm, following your argumentation, would you say that the >>> AuthenticatedWebSession is implemented wrong because it contains a >>> #authenticate method (which clearly needs a reference to some kind of >>> database)? >>> >>> Or would marking the field as "transient" be fine? >>> >>> >>> Cheers, >>> >>> Jan >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >For additional commands, e-mail: users-h...@wicket.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
