You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Scott Eade <se...@backstagetech.com.au> on 2001/06/19 15:56:39 UTC
Frustrating problem
I am a self-confessed newbee working with turbine 2.1 on
Win2k with mysql.
I have been trying to make turbine do a few different things
over the last couple of days and I am becoming increasingly
frustrated by my lack of progress.
I abandoned my attempt at modifying turbine's security such
that TURBINE_USER.EMAIL was used for the user name
rather than TURBINE_USER.LOGIN_NAME. It looked
like this would be a simple matter of overriding
org.apache.turbine.util.db.map.TurbineMapBuilder.getUsername()
and referencing the overriding class as database.maps.builder
in TR.properties but with this change in place some of the
authorisation process code uses LOGIN_NAME and some
of it uses EMAIL and thus it did not work. I was really
impressed with the architecture when I made this change
but disappointed when it turned out that it didn't seem to
be consistently applied in the authorisation code.
Most recently I am experiencing problems attempting to modify
the login process. In newapp an incorrect login switches from
the Login.vm layout to the Default.vm layout (undesirable
behaviour) and a correct login takes you to the screen Index.vm
with the layout Default.vm (desirable behaviour). Gary Murphy
indicated that the switch back to the Default.vm layout for
incorrect logins is "deep in the Flux" but that unfortunately the
solution (or at least the reason for the switch) is lost in the mists
of time. I have actually cloned newapp to myapp for my
modifications, but somehow, with no modification to
TR.properties the behaviour is strangely different in that a
correct login now leaves me on the Login.vm screen with the
Login.vm template instead of switching me to Index.vm - i.e.
I have lost the desirable behaviour above. I have confirmed
that my login has been accepted -
$data.getUser().getFirstName() in the DefaultTop.vm
navigation displays the appropriate value. Without doing
anything else, approximately 5 to 20 seconds later the
following exception appears in the Catalina console window:
java.lang.NoClassDefFoundError: com/workingdogs/village/KeyDef
at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1631)
at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1578)
at org.apache.turbine.om.security.peer.TurbineUserPeer.doUpdate(TurbineUserPeer.java:463)
at org.apache.turbine.services.security.db.DBUserManager.store(DBUserManager.java:272)
at org.apache.turbine.services.security.BaseSecurityService.saveUser(BaseSecurityService.java:379)
at org.apache.turbine.services.security.TurbineSecurity.saveUser(TurbineSecurity.java:261)
at org.apache.turbine.om.security.TurbineUser.valueUnbound(TurbineUser.java:649)
at org.apache.catalina.session.StandardSession.removeAttribute(StandardSession.java:953)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:551)
at org.apache.catalina.session.StandardManager.processExpires(StandardManager.java:744)
at org.apache.catalina.session.StandardManager.run(StandardManager.java:815)
at java.lang.Thread.run(Thread.java:484)
This class appears to exist in village-1.5.1.jar so I don't see
why the exception is occurring or if it relates to my screen
transition problem.
Introducing my own LoginUser class with:
data.setScreenTemplate(TurbineResources.getString(
TurbineConstants.TEMPLATE_HOMEPAGE));
at the end of doPerform() (where template.homepage is
defined as /Index.vm in TR.properties) makes no difference.
Not being able to move past the login screen is slowly driving
me insane. Can anyone give me a clue as to what might be
wrong here?
One last problem. When I shutdown tomcat, I get a bunch
(5 to be exact) of exceptions like this one:
[Tue Jun 19 23:41:59 GMT+10:00 2001] -- ERROR -- TurbineUser.valueUnbobund(): Failed to save user object
[Tue Jun 19 23:41:59 GMT+10:00 2001] -- ERROR --
Exception: org.apache.turbine.util.security.DataBackendException: Failed to save user object
Stack Trace follows:
java.lang.NullPointerException
at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1635)
at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1578)
at org.apache.turbine.om.security.peer.TurbineUserPeer.doUpdate(TurbineUserPeer.java:463)
at org.apache.turbine.services.security.db.DBUserManager.store(DBUserManager.java:272)
rethrown as org.apache.turbine.util.security.DataBackendException: Failed to save user object
at org.apache.turbine.services.security.db.DBUserManager.store(DBUserManager.java:276)
at org.apache.turbine.services.security.BaseSecurityService.saveUser(BaseSecurityService.java:379)
at org.apache.turbine.services.security.TurbineSecurity.saveUser(TurbineSecurity.java:261)
at org.apache.turbine.om.security.TurbineUser.valueUnbound(TurbineUser.java:649)
at org.apache.catalina.session.StandardSession.removeAttribute(StandardSession.java:953)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:551)
at org.apache.catalina.session.StandardManager.unload(StandardManager.java:541)
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:648)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1184)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3303)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:983)
at org.apache.catalina.core.StandardHost.remove(StandardHost.java:718)
at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:422)
at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:402)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:234)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:155)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1151)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1163)
at org.apache.catalina.core.StandardService.stop(StandardService.java:400)
at org.apache.catalina.core.StandardServer.stop(StandardServer.java:487)
at org.apache.catalina.startup.Catalina.start(Catalina.java:749)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:653)
at org.apache.catalina.startup.Catalina.process(Catalina.java:177)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:196)
Again, anyone have any clues as to what the problem might be?
Thanks for any help.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Frustrating problem
Posted by Jason van Zyl <jv...@apache.org>.
On 6/20/01 7:01 PM, "Keng Wong" <ke...@verizon.net> wrote:
> I am having this problem as well. I found that to execute the proper layout
> (layout/Login.vm), I had to create a Login.class (screen/Login.class) that
> currently does not perform any functions.
> This way, I don't need to set the Layout.
I will look at this now, it's a bug and a failed login attempt
should not trigger the use of a layout for a logged in user.
Looking now.
> However, I can't seem to get anything from the context for this Login.class
> screen. (Eg set a system date in Login.class)
>
> One other way I tried is to use doRedirect(data, template) within the
> isAuthorised() method. The layout still works correctly (calling
> layout/Login.vm), and the screen/Login.class gets executed (and the context
> was filled).
>
> However, the templates/screens/Login.vm seems to get loaded twice and thus
> any $page setting in the template gets called twice. Eg. duplicate title
> when $page.setTitle() is used.
>
> Logs showed:
> ResourceManager : found screens/Login.vm with loader ......
> ResourceManager : found screens/Login.vm with loader ......
> ResourceManager : found layouts/Login.vm with loader ......
> ResourceManager : found navigations/DefaultTop.vm with loader ......
> ...
>
> Could be that the screen Login.class gets loaded twice and this is how I got
> the duplicate title ($page.setTitle("hello") in templates/screen/Login.vm
>
> Maybe this is not the proper way but can anyone enlighten me ?
> Thanks a lot.
>
> -keng wong
>
>> -----Original Message-----
>> From: Scott Eade [mailto:seade@backstagetech.com.au]
>> Sent: Wednesday, June 20, 2001 8:59 AM
>> To: turbine-user@jakarta.apache.org
>> Subject: Re: Frustrating problem
>>
>>
>> Quoting myself:
>>>
>>> Most recently I am experiencing problems attempting to modify
>>> the login process. In newapp an incorrect login switches from
>>> the Login.vm layout to the Default.vm layout (undesirable
>>> behaviour) and a correct login takes you to the screen Index.vm
>>> with the layout Default.vm (desirable behaviour). Gary Murphy
>>> indicated that the switch back to the Default.vm layout for
>>> incorrect logins is "deep in the Flux" but that unfortunately the
>>> solution (or at least the reason for the switch) is lost in the mists
>>> of time.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Frustrating problem
Posted by Keng Wong <ke...@verizon.net>.
I am having this problem as well. I found that to execute the proper layout
(layout/Login.vm), I had to create a Login.class (screen/Login.class) that
currently does not perform any functions.
This way, I don't need to set the Layout.
However, I can't seem to get anything from the context for this Login.class
screen. (Eg set a system date in Login.class)
One other way I tried is to use doRedirect(data, template) within the
isAuthorised() method. The layout still works correctly (calling
layout/Login.vm), and the screen/Login.class gets executed (and the context
was filled).
However, the templates/screens/Login.vm seems to get loaded twice and thus
any $page setting in the template gets called twice. Eg. duplicate title
when $page.setTitle() is used.
Logs showed:
ResourceManager : found screens/Login.vm with loader ......
ResourceManager : found screens/Login.vm with loader ......
ResourceManager : found layouts/Login.vm with loader ......
ResourceManager : found navigations/DefaultTop.vm with loader ......
...
Could be that the screen Login.class gets loaded twice and this is how I got
the duplicate title ($page.setTitle("hello") in templates/screen/Login.vm
Maybe this is not the proper way but can anyone enlighten me ?
Thanks a lot.
-keng wong
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Wednesday, June 20, 2001 8:59 AM
> To: turbine-user@jakarta.apache.org
> Subject: Re: Frustrating problem
>
>
> Quoting myself:
> >
> > Most recently I am experiencing problems attempting to modify
> > the login process. In newapp an incorrect login switches from
> > the Login.vm layout to the Default.vm layout (undesirable
> > behaviour) and a correct login takes you to the screen Index.vm
> > with the layout Default.vm (desirable behaviour). Gary Murphy
> > indicated that the switch back to the Default.vm layout for
> > incorrect logins is "deep in the Flux" but that unfortunately the
> > solution (or at least the reason for the switch) is lost in the mists
> > of time.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Frustrating problem
Posted by Gary Lawrence Murphy <ga...@canada.com>.
>>>>> "J" == Jason van Zyl <jv...@apache.org> writes:
>>> and a correct login takes you to the screen Index.vm with the
>>> layout Default.vm (desirable behaviour). Gary Murphy
>>> indicated that the switch back to the Default.vm layout for
>>> incorrect logins is "deep in the Flux" but that unfortunately
Not for incorrect logins, this was triggered by incorrect manipulations
of screens and templates resulting in a null layout by the time the
proper page was to be rendered, and the null layout caused a sudden
shift to a blue-framed table login screen that took me by surprise.
One important quality of Turbine it is that, when it is used
"incorrectly", very, very strange behaviours emerge, but when it is
used exactly as the developers envisage, it works just as it should.
Ergo, if you get strange behaviours, you need to ask yourself "What
assumptions have I made differently from theirs?"
My 'errant' assumption was "If I am _allowed_ to change the RunData
(ie, no assertions forbid it), I may be able to change RunData
attributes influencing screens and layouts any time up until the page
is rendered". This unfortunately conflicts with the developers'
intended role for RunData as a relay-baton that gets massaged into
shape as it runs through the rendering process.
Their assumption is "RunData is computed incrementally from the
parameters it receives from the servlet according to the context of
the processing stage; to change the RunData influence on Turbine's
behaviour, you sometimes must change the _environment_ (carried with
the RunData as attributes of its attributes) and thereby change the
future computations" --- RunData is only reliably complete _during_
the rendering of the template.
I'm still worried about finding my wrong assumption that has lead to
how other people can run heavy test loads through /usr/sbin/ab with no
ill effects, yet when I run repeated and rapid load-ignore-cycle
tests, all my template pages throw exceptions and die.
--
Gary Lawrence Murphy <ga...@teledyn.com> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless. They can only give you answers."(Pablo Picasso)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Frustrating problem
Posted by Scott Eade <se...@backstagetech.com.au>.
> The problem is indeed in an older version of Flux which
> I didn't remove from the TDK. This one is my fault.
>
> As a stop gap solution:
>
> 1) download this jar:
>
> http://www.apache.org/~jvanzyl/flux.jar
>
> 2) Place the flux.jar in your WEB-INF/lib directory
>
> 3) Erase flux classes and flux srcs in your project
>
> After doing this with the released TDK everything
> worked correctly.
Thanks heaps Jason, this makes everything just peachy.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Frustrating problem
Posted by Keng Wong <ke...@verizon.net>.
Jason,
I tried the new jar and it works fine. What I wanted to do is to call up a
screen Login.class so that the some context data can be supplied to the
Login.vm class. The default stmts in SecureScreen:isAuthorized() only loads
the template but did load the screen. I tried doRedirect() to short circuit
this and the Login.class screen gets loaded finally. However, becuase of
this, screens/Login.vm template gets loaded twice and hence the duplicate
HTML title. Is this the correct way ?
Thanks for yor quick response on the flux.jar provided earlier!
-keng wong
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@apache.org]
> Sent: Wednesday, June 20, 2001 11:05 PM
> To: turbine-user@jakarta.apache.org
> Subject: Re: Frustrating problem
>
>
>
> The problem is indeed in an older version of Flux which
> I didn't remove from the TDK. This one is my fault.
>
> As a stop gap solution:
>
> 1) download this jar:
>
> http://www.apache.org/~jvanzyl/flux.jar
>
> 2) Place the flux.jar in your WEB-INF/lib directory
>
> 3) Erase flux classes and flux srcs in your project
>
> After doing this with the released TDK everything
> worked correctly.
>
> I will start working on a 2.1.1 release tomorrow ASAP
> as this is a really annoying problem.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Frustrating problem
Posted by Jason van Zyl <jv...@apache.org>.
On 6/21/01 1:45 AM, "Scott Eade" <se...@backstagetech.com.au> wrote:
>> It appears to be something in the template service ... It doesn't
>> appear to be even looking for the correct layout template after
>> a failed login.
>>
>> We must have fixed this inadvertently in HEAD because what you
>> are seeing as a problem isn't the case with TDKs I build with
>> the HEAD code.
>>
>> I will try to sort this out and I will try to get a 2.1.1
>> release out with a bunch of fixes including one for the matching
>> layout problem.
>
> To be complete, would you mind also confirming the behaviour
> when the user's session has timed out. What I get is the
> Login.vm screen in the Default.vm layout instead of the
> Login.vm layout. Pretty much the same problem as with a
> failed login attempt.
>
> Scott
The problem is indeed in an older version of Flux which
I didn't remove from the TDK. This one is my fault.
As a stop gap solution:
1) download this jar:
http://www.apache.org/~jvanzyl/flux.jar
2) Place the flux.jar in your WEB-INF/lib directory
3) Erase flux classes and flux srcs in your project
After doing this with the released TDK everything
worked correctly.
I will start working on a 2.1.1 release tomorrow ASAP
as this is a really annoying problem.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Frustrating problem
Posted by Scott Eade <se...@backstagetech.com.au>.
> It appears to be something in the template service ... It doesn't
> appear to be even looking for the correct layout template after
> a failed login.
>
> We must have fixed this inadvertently in HEAD because what you
> are seeing as a problem isn't the case with TDKs I build with
> the HEAD code.
>
> I will try to sort this out and I will try to get a 2.1.1
> release out with a bunch of fixes including one for the matching
> layout problem.
To be complete, would you mind also confirming the behaviour
when the user's session has timed out. What I get is the
Login.vm screen in the Default.vm layout instead of the
Login.vm layout. Pretty much the same problem as with a
failed login attempt.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Frustrating problem
Posted by Jason van Zyl <jv...@apache.org>.
On 6/20/01 10:54 PM, "Jason van Zyl" <jv...@apache.org> wrote:
> On 6/20/01 10:27 PM, "Scott Eade" <se...@backstagetech.com.au> wrote:
>
>>
>> File attached.
>>
>> This is how newapp behaved for me immediately following
>> installation. A diff to the TR.properties file in share/conf
>> shows nothing unusual that might cause this behaviour.
>>
>
> You are right. This is not the behaviour seen with the code
> from HEAD. I'll try to track down the problem, it works in
> the HEAD code so I'll try to find what was fixed and
> backport it.
It appears to be something in the template service ... It doesn't
appear to be even looking for the correct layout template after
a failed login.
We must have fixed this inadvertently in HEAD because what you
are seeing as a problem isn't the case with TDKs I build with
the HEAD code.
I will try to sort this out and I will try to get a 2.1.1
release out with a bunch of fixes including one for the matching
layout problem.
--
jvz.
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Frustrating problem
Posted by Jason van Zyl <jv...@apache.org>.
On 6/20/01 10:27 PM, "Scott Eade" <se...@backstagetech.com.au> wrote:
>
> File attached.
>
> This is how newapp behaved for me immediately following
> installation. A diff to the TR.properties file in share/conf
> shows nothing unusual that might cause this behaviour.
>
You are right. This is not the behaviour seen with the code
from HEAD. I'll try to track down the problem, it works in
the HEAD code so I'll try to find what was fixed and
backport it.
--
jvz.
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Frustrating problem
Posted by Scott Eade <se...@backstagetech.com.au>.
> > Quoting myself:
> >>
> >> Most recently I am experiencing problems attempting to modify
> >> the login process. In newapp an incorrect login switches from
> >> the Login.vm layout to the Default.vm layout (undesirable
> >> behaviour)
>
> I just tried this and that's not the behavior I'm seeing.
> I repeatedly login incorrectly and get the right layout.
>
> Can you send me your TurbineResources.properties file
> and I will take a look.
>
File attached.
This is how newapp behaved for me immediately following
installation. A diff to the TR.properties file in share/conf
shows nothing unusual that might cause this behaviour.
> >> and a correct login takes you to the screen Index.vm
> >> with the layout Default.vm (desirable behaviour). Gary Murphy
> >> indicated that the switch back to the Default.vm layout for
> >> incorrect logins is "deep in the Flux" but that unfortunately the
>
> Deep in flux? When exactly are you seeing this behaviour.
> When I start up the sample app I login in incorrectly
> and the correct layout template is used.
>
> Can you describe exactly when you are seeing this behaviour.
I'd ignore this. I suspect we may have been talking about
different things.
Scott
Re: Frustrating problem
Posted by Jason van Zyl <jv...@apache.org>.
On 6/20/01 11:58 AM, "Scott Eade" <se...@backstagetech.com.au> wrote:
> Quoting myself:
>>
>> Most recently I am experiencing problems attempting to modify
>> the login process. In newapp an incorrect login switches from
>> the Login.vm layout to the Default.vm layout (undesirable
>> behaviour)
I just tried this and that's not the behavior I'm seeing.
I repeatedly login incorrectly and get the right layout.
Can you send me your TurbineResources.properties file
and I will take a look.
>> and a correct login takes you to the screen Index.vm
>> with the layout Default.vm (desirable behaviour). Gary Murphy
>> indicated that the switch back to the Default.vm layout for
>> incorrect logins is "deep in the Flux" but that unfortunately the
Deep in flux? When exactly are you seeing this behaviour.
When I start up the sample app I login in incorrectly
and the correct layout template is used.
Can you describe exactly when you are seeing this behaviour.
>
>
> Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Frustrating problem
Posted by Scott Eade <se...@backstagetech.com.au>.
Quoting myself:
>
> Most recently I am experiencing problems attempting to modify
> the login process. In newapp an incorrect login switches from
> the Login.vm layout to the Default.vm layout (undesirable
> behaviour) and a correct login takes you to the screen Index.vm
> with the layout Default.vm (desirable behaviour). Gary Murphy
> indicated that the switch back to the Default.vm layout for
> incorrect logins is "deep in the Flux" but that unfortunately the
> solution (or at least the reason for the switch) is lost in the mists
> of time. I have actually cloned newapp to myapp for my
> modifications, but somehow, with no modification to
> TR.properties the behaviour is strangely different in that a
> correct login now leaves me on the Login.vm screen with the
> Login.vm template instead of switching me to Index.vm - i.e.
> I have lost the desirable behaviour above. I have confirmed
> that my login has been accepted -
> $data.getUser().getFirstName() in the DefaultTop.vm
> navigation displays the appropriate value.
The change in behaviour was caused by me stuffing up the
initial entry in TURBINE_USER_GROUP_ROLE. Eventually
SecureScreen.isAuthorised() throws me back to Login.vm
because I didn't have the required turbine_root role.
With regards to the undesirable behaviour, I think this is a bug
in org.apache.turbine.modules.actions.LoginUser.java.
I think it needs a change something like:
if (loginTemplate != null && loginTemplate.length() > 0)
{
//data.setScreenTemplate(loginTemplate);
data.setLayoutTemplate(loginTemplate);
}
else
{
//data.setScreen(TurbineResources.getString(
data.setScreenTemplate(TurbineResources.getString(
TurbineConstants.SCREEN_LOGIN));
}
But I am not 100% sure as I am not totally happy with
my understanding of the various methods for setting
screens and templates.
> Introducing my own LoginUser class with:
>
> data.setScreenTemplate(TurbineResources.getString(
> TurbineConstants.TEMPLATE_HOMEPAGE));
>
> at the end of doPerform() (where template.homepage is
> defined as /Index.vm in TR.properties) makes no difference.
This was the same problem as above.
> One last problem. When I shutdown tomcat, I get a bunch
> (5 to be exact) of exceptions like this one:
>
> [Tue Jun 19 23:41:59 GMT+10:00 2001] -- ERROR -- TurbineUser.valueUnbobund(): Failed to save user object
> [Tue Jun 19 23:41:59 GMT+10:00 2001] -- ERROR --
> Exception: org.apache.turbine.util.security.DataBackendException: Failed to save user object
> Stack Trace follows:
> java.lang.NullPointerException
> at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1635)
> at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1578)
... -- SNIP ---
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:196)
>
> Again, anyone have any clues as to what the problem might be?
I am pretty sure this is a side effect of the Catalina bug that Jon
Stevens chased down (thanks Jon).
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Frustrating problem
Posted by Jon Stevens <jo...@latchkey.com>.
on 6/19/01 6:56 AM, "Scott Eade" <se...@backstagetech.com.au> wrote:
> Without doing
> anything else, approximately 5 to 20 seconds later the
> following exception appears in the Catalina console window:
>
> java.lang.NoClassDefFoundError: com/workingdogs/village/KeyDef
> at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1631)
> at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1578)
I have seen this as well. It is a bug somewhere in Catalina...
-jon
--
"Open source is not available to commercial companies."
-Steve Ballmer, CEO Microsoft
<http://www.suntimes.com/output/tech/cst-fin-micro01.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org