You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Jake Fear <fe...@grifware.com> on 2002/12/29 20:13:55 UTC

Subclassing Actions (particularly LoginUser)

I am using Turbine2.2 and I am attempting to subclass the LoginUser
class in order to add some cookie handling ability (so that it does not
always redirect to the default page).  However, even when I simply call
super.doPerform(data) in my own doPerform method it seems to break the
login functionality and I can never get logged in.  I tried moving my
functionality to the protected perform(RunData data) method and that
seems to have the same results.  Can anyone tell about any known issues
subclassing actions?

Cheers,
Jake
-- 
Jake Fear <fe...@grifware.com>
Grifware.Com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Subclassing Actions (particularly LoginUser)

Posted by CP Lim <cp...@redsheriff.com>.
Hi Jake,

As far as I know (and I've only had a chance to look at the code 
briefly), I think it is used by the Turbine (servlet) class to determine 
whether or not the submitted action is a login/logout and processes them 
differently from normal actions.  If you'd like to know more about how 
Turbine works under the covers you can download the source and debug 
with it (I highly recommend it actually :).

Have a look at:

http://jakarta.apache.org/builds/jakarta-turbine/turbine-2/release/2.2/

cheers,
CP

Jake Fear wrote:
> I see, the module packages item had been taken care of.  I was unaware
> of the action.login property.  This makes some sense, because without
> changing the property things seemed to work when I changed the name of
> my custom class (but not its package).  It seems strange to me that this
> particular action must be named explicitly.  Are you aware of the exact
> purpose this serves?
> 
> Thanks again,
> Jake
> 
> On Sun, 2002-12-29 at 20:52, CP Lim wrote:
> 
>>Hi Jake,
>>
>>Did you update your TR.properties file?  You'll need to update the 
>>'action.login' to reference your version of the login class.  You'll 
>>also have to include your package so that turbine can find it in the 
>>'module.packages' properties as well.
>>
>>Let me illustrate with an example.  Assuming your new login class is 
>>'MyLogin' and it exists in the package 'com.mycompany.modules', then 
>>you'd edit the TR.properties entries as follows:
>>
>>--------------------------------------------
>>#this will include your MyLogin class to the path to search for modules.
>>module.packages=com.mycompany.modules,org.apache.turbine.modules
>>
>>#replace the previous 'LoginUser' class with your own.
>>action.login=MyLogin
>>--------------------------------------------
>>
>>HTH,
>>CP
>>
>>Jake Fear wrote:
>>
>>>I am using Turbine2.2 and I am attempting to subclass the LoginUser
>>>class in order to add some cookie handling ability (so that it does not
>>>always redirect to the default page).  However, even when I simply call
>>>super.doPerform(data) in my own doPerform method it seems to break the
>>>login functionality and I can never get logged in.  I tried moving my
>>>functionality to the protected perform(RunData data) method and that
>>>seems to have the same results.  Can anyone tell about any known issues
>>>subclassing actions?
>>>
>>>Cheers,
>>>Jake
>>


-- 
R E D S H E R I F F
C.P. Lim - Software Engineer
Level 1, 10 Queens Road    +61 3 9864 0733 tel
Melbourne VIC              +61 3 9864 0778 fax
Australia                  +61 413 781 846 mob

This message and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the intended recipient, you are hereby 
notified that any use or dissemination of this communication is strictly 
prohibited. If you have received this message in error please notify us 
immediately by return email or telephone +61 (3) 9659 0432, then delete 
this message. Any views expressed in this message are those of the 
individual sender and many not necessarily reflect the views of Red 
Sheriff.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Subclassing Actions (particularly LoginUser)

Posted by Chris K Chew <ch...@fenetics.com>.
> From: Jake Fear [mailto:fear@grifware.com]
> Is there some special reason this responsibility of clearing out session
> specific data was not left to the action itself?  I don't really want to
> start a debate, but it seems like a kludge to me.  The potential for a
> name collision seems like reason enough not to do things that way.
> Thanks for all of your help.

I agree this is a questionable thing to do.  For example, there was a
problem mentioned recently on the list about session tools being cleared
when a user logs in.  I think this became issue TTWS22 in scarab.  Simply
moving the clearing-the-session to the action, and specifying which keys to
remove, would be a good solution.

Chris


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Subclassing Actions (particularly LoginUser)

Posted by Jake Fear <fe...@grifware.com>.
Is there some special reason this responsibility of clearing out session
specific data was not left to the action itself?  I don't really want to
start a debate, but it seems like a kludge to me.  The potential for a
name collision seems like reason enough not to do things that way.
Thanks for all of your help.

Jake

On Mon, 2002-12-30 at 08:41, Chris K Chew wrote:
> > Jake:
> > Are you aware of the exact purpose this serves?
> 
> Take a look at the o.a.t.Turbine servlet class (in xref at:
> http://jakarta.apache.org/turbine/turbine-22/xref/index.html), at lines 475
> to 511.  Basically, Turbine removes user-related data from the session when
> logging in or out.
> 
> Chris
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- 
Jake Fear <fe...@grifware.com>
Grifware.Com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Subclassing Actions (particularly LoginUser)

Posted by Chris K Chew <ch...@fenetics.com>.
> Jake:
> Are you aware of the exact purpose this serves?

Take a look at the o.a.t.Turbine servlet class (in xref at:
http://jakarta.apache.org/turbine/turbine-22/xref/index.html), at lines 475
to 511.  Basically, Turbine removes user-related data from the session when
logging in or out.

Chris


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Subclassing Actions (particularly LoginUser)

Posted by Jake Fear <fe...@grifware.com>.
I see, the module packages item had been taken care of.  I was unaware
of the action.login property.  This makes some sense, because without
changing the property things seemed to work when I changed the name of
my custom class (but not its package).  It seems strange to me that this
particular action must be named explicitly.  Are you aware of the exact
purpose this serves?

Thanks again,
Jake

On Sun, 2002-12-29 at 20:52, CP Lim wrote:
> Hi Jake,
> 
> Did you update your TR.properties file?  You'll need to update the 
> 'action.login' to reference your version of the login class.  You'll 
> also have to include your package so that turbine can find it in the 
> 'module.packages' properties as well.
> 
> Let me illustrate with an example.  Assuming your new login class is 
> 'MyLogin' and it exists in the package 'com.mycompany.modules', then 
> you'd edit the TR.properties entries as follows:
> 
> --------------------------------------------
> #this will include your MyLogin class to the path to search for modules.
> module.packages=com.mycompany.modules,org.apache.turbine.modules
> 
> #replace the previous 'LoginUser' class with your own.
> action.login=MyLogin
> --------------------------------------------
> 
> HTH,
> CP
> 
> Jake Fear wrote:
> > I am using Turbine2.2 and I am attempting to subclass the LoginUser
> > class in order to add some cookie handling ability (so that it does not
> > always redirect to the default page).  However, even when I simply call
> > super.doPerform(data) in my own doPerform method it seems to break the
> > login functionality and I can never get logged in.  I tried moving my
> > functionality to the protected perform(RunData data) method and that
> > seems to have the same results.  Can anyone tell about any known issues
> > subclassing actions?
> > 
> > Cheers,
> > Jake
-- 
Jake Fear <fe...@grifware.com>
Grifware.Com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Subclassing Actions (particularly LoginUser)

Posted by CP Lim <cp...@redsheriff.com>.
Hi Jake,

Did you update your TR.properties file?  You'll need to update the 
'action.login' to reference your version of the login class.  You'll 
also have to include your package so that turbine can find it in the 
'module.packages' properties as well.

Let me illustrate with an example.  Assuming your new login class is 
'MyLogin' and it exists in the package 'com.mycompany.modules', then 
you'd edit the TR.properties entries as follows:

--------------------------------------------
#this will include your MyLogin class to the path to search for modules.
module.packages=com.mycompany.modules,org.apache.turbine.modules

#replace the previous 'LoginUser' class with your own.
action.login=MyLogin
--------------------------------------------

HTH,
CP

Jake Fear wrote:
> I am using Turbine2.2 and I am attempting to subclass the LoginUser
> class in order to add some cookie handling ability (so that it does not
> always redirect to the default page).  However, even when I simply call
> super.doPerform(data) in my own doPerform method it seems to break the
> login functionality and I can never get logged in.  I tried moving my
> functionality to the protected perform(RunData data) method and that
> seems to have the same results.  Can anyone tell about any known issues
> subclassing actions?
> 
> Cheers,
> Jake


-- 
R E D S H E R I F F
C.P. Lim - Software Engineer
Level 1, 10 Queens Road    +61 3 9864 0733 tel
Melbourne VIC              +61 3 9864 0778 fax
Australia                  +61 413 781 846 mob

This message and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the intended recipient, you are hereby 
notified that any use or dissemination of this communication is strictly 
prohibited. If you have received this message in error please notify us 
immediately by return email or telephone +61 (3) 9659 0432, then delete 
this message. Any views expressed in this message are those of the 
individual sender and many not necessarily reflect the views of Red 
Sheriff.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>