Hello Igor, I really like the idea behind Salve. Are there any open source applications using it, except elephas [1] ?
I already got a lot of inspiration from the elephas source code, but that project seems to have stalled a bit, right ? [1] http://code.google.com/p/elephas/ Thanks, Maarten On Wed, Apr 29, 2009 at 6:39 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > i dont know how fdiotalevi works. > > you can do it however you want as long as you either dont add a > serializable field to the session or you do add a field but it > contains some sort of serialization-safe proxy. > > -igor > > On Wed, Apr 29, 2009 at 1:18 AM, <bern...@actrix.co.nz> wrote: >> 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 >> >> > > --------------------------------------------------------------------- > 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
