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 <[EMAIL PROTECTED]> Grifware.Com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
