You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Jan Torben Heuer <jt...@mail2004.dnsalias.org> on 2009/04/28 13:46:21 UTC
Wicket-Guice: Inject into Session
Hi,
I'm a Wicket and Guice beginner. I successfully managed Guice to Inject my
dependency into a WebPage. Can Guice also inject the dependency into an
AuthenticatedWebSession? I'd need a reference to my database in the
#authenticate(String, String) method.
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Steve Flasby <st...@flasby.org>.
I do this:
@Override
public Session newSession(Request request, Response response) {
Session s = new MySession(request);
mInjector.inject(s);
return s;
}
Cheers - Steve
Jan Torben Heuer wrote:
> Hi,
>
> I'm a Wicket and Guice beginner. I successfully managed Guice to Inject my
> dependency into a WebPage. Can Guice also inject the dependency into an
> AuthenticatedWebSession? I'd need a reference to my database in the
> #authenticate(String, String) method.
>
> Jan
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Eduardo Nunes <es...@gmail.com>.
I use Guice to control my servlets, so I can just add objects to session scope.
http://code.google.com/p/google-guice/wiki/Servlets
On Tue, Apr 28, 2009 at 8:46 AM, Jan Torben Heuer
<jt...@mail2004.dnsalias.org> wrote:
> Hi,
>
> I'm a Wicket and Guice beginner. I successfully managed Guice to Inject my
> dependency into a WebPage. Can Guice also inject the dependency into an
> AuthenticatedWebSession? I'd need a reference to my database in the
> #authenticate(String, String) method.
>
> Jan
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Eduardo S. Nunes
http://e-nunes.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Jan Torben Heuer <jt...@mail2004.dnsalias.org>.
Jeremy Thomerson wrote:
> You shouldn't be using database connections. Use a service from your
> service layer. Inject the service with wicket-ioc / wicket-guice - it
> will insert a serializable proxy.
It is a controller class that hides the database implementation details and
it is injected by guice. It is not a connection in terms of a tcp connection
to a mysql database or alike.
Cheers,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Jeremy Thomerson <je...@wickettraining.com>.
You shouldn't be using database connections. Use a service from your
service layer. Inject the service with wicket-ioc / wicket-guice - it
will insert a serializable proxy.
--
Jeremy Thomerson
http://www.wickettraining.com
On Tue, Apr 28, 2009 at 11:49 PM, Marc Ende <ml...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Igor Vaynberg <ig...@gmail.com>.
i dont know of any myself. re elephas, i also dont know, i dont really
work on it.
-igor
On Thu, Apr 30, 2009 at 12:58 AM, Maarten Bosteels
<mb...@gmail.com> wrote:
> 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 <ig...@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, <Be...@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 <ml...@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-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Maarten Bosteels <mb...@gmail.com>.
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 <ig...@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, <Be...@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 <ml...@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-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Igor Vaynberg <ig...@gmail.com>.
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, <Be...@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 <ml...@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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Be...@actrix.co.nz.
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 <ml...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ml...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Marc Ende <ml...@e-beyond.de>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Jan Torben Heuer <jt...@mail2004.dnsalias.org>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket-Guice: Inject into Session
Posted by Marc Ende <ml...@e-beyond.de>.
Hi Jan,
the Session (org.apache.wicket.Session) implements Serializable. So I
think that wicket is also serializing the session object as other
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).
just my 5 cent... :)
Marc
Jan Torben Heuer schrieb:
> Hi,
>
> I'm a Wicket and Guice beginner. I successfully managed Guice to Inject my
> dependency into a WebPage. Can Guice also inject the dependency into an
> AuthenticatedWebSession? I'd need a reference to my database in the
> #authenticate(String, String) method.
>
> Jan
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org