You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Ate Douma <at...@douma.nu> on 2005/08/18 15:36:47 UTC
HELP: how to ask for it! [Was: Re: ProfilerValveImpl HELP!]
Rakesh,
I'd like to add an important comment to those already made by Randy below
and before.
We (the Jetspeed team) will gladly help anyone out as far as we can but
for that you need to provide us with enough information to go by, like:
- which db are you using (as it seems you have db problems somewhere)
and how do you use it (if non-standard)
- relevant stacktrace / error messages you found in the logs or the console
- relevant configuration changes you made to the default configs
- example/snippet code of your custom classes (like your LoginErrorServlet
you refer to, as well as the parts of web.xml you changed to be able to
use that servlet)
- a logical description of what you are trying to achieve and how it fails
(like a sequence of interactions leading to the error(s)).
Without something concrete like these, we only can guess what your real
problem is and takes far to much of our valuable time.
So please, if you can describe your exact problem and provide us with
the information like I described above, we will gladly try to help out
and get this solved.
Regards,
Ate
Randy Watler wrote:
> Rakesh,
>
> Ok... I think I can finally answer your questions!
>
> While I cannot tell you what is going wrong when you attempt to use a
> different servlet in the login process, I do not think you need one.
> Using the standard profiling rule, J2 will look for a user specific page
> in ../WEB_INF/pages/_user/<user login>/default-page.psml. If that fails,
> it will fallback to ../WEB_INF/pages/default-page.psml. When there is no
> authenticated login, (i.e. before a successful login), it will look in
> ../WEB_INF/pages/_user/guest/default-page.psml before falling back to
> ../WEB_INF/pages/default-page.psml. Perhaps you already have this
> working. If so, I am still interested in knowing why you want to use a
> new login servlet.
>
> When you shut down your application database, I find it difficult to
> believe that J2 fails to load the correct page. I do not think that you
> need to extend ProfierValveImpl to handle errors/exceptions in your
> portlets. In fact, if J2 breaks because your portlets fail to access the
> application DB, that would be a J2 bug... it should not be possible. So,
> I am afraid I have the same response for you here: it is the individual
> portlet's responsibility to catch errors and redirect accordingly in the
> action phase of portlet execution. To be clear: if the ProfilerValveImpl
> is falling back to the root level default page when there is an
> application DB access error, there is a bug in J2. You should not be
> catching this kind of problem in the J2 request pipeline.
>
> HTH,
>
> Randy
>
> Tomba Rakesh wrote:
>
>> Hi Randy
>>
>> >Are you really redirecting to a user specific failed login page? This
>> >seems strange to me. We have lots of support to redirect to a
>> >user/role/group specific page on successful login. Seems like a failed
>> >login might want to redirect to a common page. Am I reading this wrong?
>>
>> When login fail we use LoginErrorServlet for redirecting error page.
>>
>> For login success we redirect to user specific psml file. We define
>> custom layout and decoration so that only one psml file will be
>> displayed. Client requirement have only one psml file for each user.
>> We don't have any group or role psml file.
>>
>> So far we don't have any problem in login, redirect and login error.
>>
>> I was asking for login, is it possible to use a new LoginServlet other
>> than LoginProxyServlet(jetspeed login servlet). When I tried new
>> servlet and defined in jetspeed's app web.xml it does not work.
>>
>> >To be specific: the database you shutdown contains J2 tables for
>> >portlets, security, etc., or just your application data? Seems like only
>> >missing J2 data would effect the page mapping of request urls, no?
>>
>> Database which I shutdown does not contain J2 tables for portlets,
>> security, etc., this is our application data.
>>
>> Regards
>> Rakesh
>>
>> */Randy Watler <wa...@wispertel.net>/* wrote:
>>
>> Rakesh,
>>
>> Further clarification still needed... i must be missing something!
>>
>> Randy
>>
>> Tomba Rakesh wrote:
>>
>> >Hi Randy
>> >
>> >
>> >
>> >>1. did you register and add the new servlet in the web.xml of the
>> >>security app?
>> >>
>> >>
>> >
>> >I am adding new servlet as well as new servlet entry to web.xml
>> (web.xml for jetspeed app, not web.xml for security app).
>> >
>> >
>> >
>> >>2. what functionality would you have added if you were
>> successful in
>> >>using your own servlet?
>> >>
>> >>
>> >
>> >Functionality added: just redirected to user specific psml file.
>> For example for user01
>> >it redirected to
>> >http://localhost:8080/jetspeed/portal/user01.psml
>> >
>> >
>> Are you really redirecting to a user specific failed login page? This
>> seems strange to me. We have lots of support to redirect to a
>> user/role/group specific page on successful login. Seems like a
>> failed
>> login might want to redirect to a common page. Am I reading this
>> wrong?
>>
>> >>Ok... you took down the J2 DB? If so, I missed that. I'd prefer to
>> >>handle that as part of the J2 product if at all possible... this
>> is not
>> >>unique to the ProfilerValveImpl but it may show up there first.
>> Most
>> >>likely, we'll end up returning an HTTP error status code and you
>> can
>> >>customize the returned page in the container for the HTTP page.
>> Will
>> >>that work for you?
>> >>
>> >>
>> >
>> >I took "External Database" down not the J2 DB (Hypersonic).
>> External database is the place where actual user data are stored.
>> >
>> To be specific: the database you shutdown contains J2 tables for
>> portlets, security, etc., or just your application data? Seems
>> like only
>> missing J2 data would effect the page mapping of request urls, no?
>>
>> Randy
>>
>> >
>> >Regards
>> >Rakesh
>> >
>> >Randy Watler wrote:
>> >Rakesh,
>> >
>> >
>> >
>> >Tomba Rakesh wrote:
>> >
>> >
>> >
>> >>Hi Randy
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>Is there some feature that
>> >>>is missing here that you'd like to see? If so, it might be general
>> >>>enough to be added to the product.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>For login, jetspeed use LoginProxyServlet. When I try new
>> servlet(same functionality as LoginProxyServlet) for login it does
>> not work. Is there any way to provide a new servlet (without
>> touching LoginProxyServlet) for login.
>> >>
>> >>
>> >>
>> >I am not sure what is going wrong here... two points for
>> clarification:
>> >
>> >1. did you register and add the new servlet in the web.xml of the
>> >security app?
>> >2. what functionality would you have added if you were successful in
>> >using your own servlet?
>> >
>> >
>> >
>> >>
>> >>
>> >>
>> >>>>For Database connection fail, Jetspeed use ProfilerValveImpl
>> for redirecting.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>This seems incorrect. The portlets themselves must take
>> responsibility
>> >>>for handling errors. In turn, they can redirect and/or modify
>> session
>> >>>state so that subsequent requests to the portal are routed
>> based on a
>> >>>dfferent set of profiling rules.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>Every user we have specific psml file, for user user01 we have
>> >>http://localhost:8080/jetspeed/portal/user01.psml [Contains our
>> portlets]
>> >>
>> >>After database is down. Any try to open
>> "http://localhost:8080/jetspeed/portal/user01.psml" goes to
>> jetspeed default page.
>> >>
>> >>Our portlets takes the responsibility for handling errors, but
>> the portlets are not being call. Instead of calling the portlets
>> specified in the psml file. Jetspeed calls ProfilerValveImpl. So
>> by modifying ProfilerValveImpl I could redirect to any page.
>> >>
>> >>Suggest me how to tackle this issue. Is there any better
>> approach....
>> >>
>> >>
>> >>
>> >>
>> >Ok... you took down the J2 DB? If so, I missed that. I'd prefer to
>> >handle that as part of the J2 product if at all possible... this
>> is not
>> >unique to the ProfilerValveImpl but it may show up there first. Most
>> >likely, we'll end up returning an HTTP error status code and you can
>> >customize the returned page in the container for the HTTP page. Will
>> >that work for you?
>> >
>> >Randy
>> >
>> >
>> >
>> >>Regards
>> >>Rakesh
>> >>
>> >>Randy Watler wrote:
>> >>Rakesh:
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>For login error, redirect using LoginErrorServlet.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>Seems correct, but I cannot contribute much here because it has
>> been a
>> >>while since I did much with the login processing. It seems to me
>> that
>> >>the existing implementation handles this smoothy, including login
>> >>failure counts and other security features. Is there some
>> feature that
>> >>is missing here that you'd like to see? If so, it might be general
>> >>enough to be added to the product.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>For Database connection fail, Jetspeed use ProfilerValveImpl
>> for redirecting.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>This seems incorrect. The portlets themselves must take
>> responsibility
>> >>for handling errors. In turn, they can redirect and/or modify
>> session
>> >>state so that subsequent requests to the portal are routed based
>> on a
>> >>different set of profiling rules. The security application uses
>> this
>> >>technique to force the end user to change passwords using the
>> >>"MyAccount.psml" page. Here, you may want to simply force the
>> display of
>> >>a DBIsDown.psml page using a profiling rule override. Note that the
>> >>profiler is very flexible and can be used in many different ways to
>> >>interpret request urls... all without code modification of any
>> sort. So,
>> >>yes, the profiler is performing the "redirection" in a sense,
>> but it
>> >>does not require programmatic extension.
>> >>
>> >>HTH,
>> >>
>> >>Randy
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>The way I tested:
>> >>>1. Shut down external database (Not Hypersonic Database )
>> >>>2. In normal, when user login, it goes to user specific psml
>> file. And whatever portlets mentioned in the psml file gets
>> displayed. The information displayed by the portlets are from
>> external database.
>> >>>3. As in step 1 database is down. As database is not available,
>> by default jetspeed call ProfilerValveImpl (portlet code are not
>> executing) and redirects to jetspeed default page. So instead of
>> displaying jetspeed default page, I would like to display some
>> error message as "Database is down".
>> >>>
>> >>>Please correct me if I am wrong:
>> >>>I use ProfilerValveImpl for handling psml file Exception (No
>> database available).
>> >>>
>> >>>Regards
>> >>>Rakesh
>> >>>
>> >>>Randy Watler wrote:
>> >>>Rakesh,
>> >>>
>> >>>I am afraid I do not understand your needs fully, so it is hard to
>> >>>suggest the best implementation.
>> >>>
>> >>>Exactly under what conditions do you want to redirect to an
>> error page
>> >>>instead of the default page? If it is after a failed login,
>> there might
>> >>>be a better way to accomplish what you are after.
>> >>>
>> >>>Randy
>> >>>
>> >>>Tomba Rakesh wrote:
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>Hi Randy
>> >>>>
>> >>>>Thanks for your quick response. Sorry I really forgot, that's
>> why it was cross post.
>> >>>>Actually my requirement is redirect to our error page if
>> something goes wrong. By default it redirect to jetspeed's
>> default-page.psml
>> >>>>
>> >>>>Types of Login:
>> >>>>Type 1. Once user sucessfully login to our application,
>> username and password is redirected to jetspeed's LoginProxyServlet.
>> >>>>Type 2. Login from jetspeed's default page.
>> >>>>
>> >>>>For login Type 2, we would like forward to jetspeed default
>> page. For Type 1, we would like forward to our error page.
>> >>>>
>> >>>>So if have a class MyProfilerValveImpl this will always
>> redirected to our page. Where to put this entry before or after
>> ProfilerValveImpl.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>>class="org.apache.jetspeed.profiler.impl.ProfilerValveImpl"
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>init-method="initialize"
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>Regards
>> >>>>Rakesh
>> >>>>
>> >>>>Randy Watler wrote:
>> >>>>Rakesh,
>> >>>>
>> >>>>I have asked before... please do NOT cross post to this list
>> and the dev
>> >>>>list.
>> >>>>
>> >>>>The ProfilerValveImpl is part of the J2 request pipeline. It is
>> >>>>configured using spring in the assembly/pipelines.xml file.
>> >>>>
>> >>>>However, it is non-trivial to replace its functionality. If
>> you simply
>> >>>>want to extend it, you might want to consider adding
>> additional stages
>> >>>>in the pipeline before or after the existing impl instead.
>> >>>>
>> >>>>Randy
>> >>>>
>> >>>>Tomba Rakesh wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>>Hi All
>> >>>>>
>> >>>>>1. Which class or servlet calls
>> org.apache.jetspeed.profiler.impl.ProfilerValveImpl
>> >>>>>2. Is it possible to provide a new ProfilerValveImpl, if so
>> where where to configuration?
>> >>>>>
>> >>>>>Thanks in advance
>> >>>>>
>> >>>>>Regards
>> >>>>>Rakesh
>> >>>>>
>> >>>>>
>> >>>>>__________________________________________________
>> >>>>>Do You Yahoo!?
>> >>>>>Tired of spam? Yahoo! Mail has the best spam protection around
>> >>>>>http://mail.yahoo.com
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>>
>> >>>>---------------------------------------------------------------------
>> >>>>To unsubscribe, e-mail:
>> jetspeed-user-unsubscribe@portals.apache.org
>> >>>>For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>> >>>>
>> >>>>
>> >>>>__________________________________________________
>> >>>>Do You Yahoo!?
>> >>>>Tired of spam? Yahoo! Mail has the best spam protection around
>> >>>>http://mail.yahoo.com
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>>
>> >>>---------------------------------------------------------------------
>> >>>To unsubscribe, e-mail:
>> jetspeed-user-unsubscribe@portals.apache.org
>> >>>For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>> >>>
>> >>>
>> >>>__________________________________________________
>> >>>Do You Yahoo!?
>> >>>Tired of spam? Yahoo! Mail has the best spam protection around
>> >>>http://mail.yahoo.com
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>>
>> >>---------------------------------------------------------------------
>> >>To unsubscribe, e-mail:
>> jetspeed-user-unsubscribe@portals.apache.org
>> >>For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>> >>
>> >>
>> >>__________________________________________________
>> >>Do You Yahoo!?
>> >>Tired of spam? Yahoo! Mail has the best spam protection around
>> >>http://mail.yahoo.com
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> >For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>> >
>> >
>> >
>> >---------------------------------
>> > Start your day with Yahoo! - make it your home page
>> >
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: HELP: how to ask for it! [Was: Re: ProfilerValveImpl HELP!]
Posted by Scott T Weaver <sc...@binary-designs.net>.
>
> I propose that the Jetspeed engine always completes initialization, even
> on error conditions. The engine will have 'state' attribute to
> determine if the engine is running or in
>
> engine.getState()
>
> returning states such as RUNNING, INITIALIZING, DOWN, ERROR
>
> Then a valve can check the engine state, and redirect to servlet pages
> based on the state, or pass thru on the RUNNING state.
+1! This is a great idea.
>
> This leads to an interesting challenge: what if the database comes up?
> Should we just restart the app server?
> Thats certainly the easiest solution.
> A retry thread would be another solution
I think just re-creating a brand new Engine instance and starting it in the
JetspeedServlet would work just as well as long as the app server can
recover cleanly (if we are using the app servers datasource). Otherwise, a
container restart would be required.
>
> Well, I didn't mean to hijack your thread and sorry if I got off topic.
> I hope we are trying to solve the same problem.
>
> Im going to create a JIRA issue to further explore the engine state
> feature
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: HELP: how to ask for it! [Was: Re: ProfilerValveImpl HELP!]
Posted by David Sean Taylor <da...@bluesunrise.com>.
Tomba Rakesh wrote:
> public class ProfilerValveImpl extends AbstractValve
> implements PageProfilerValve {
> ....
> ....
> public void invoke( RequestContext request, ValveContext context )
> throws PipelineException {
> try {
> ....
> ....
> } catch( SecurityException se ) {
> if( ( request.getRequest( ).getUserPrincipal( ) == null ) &&
> ( request.getPath( ) != null ) &&
> !request.getPath( ).equals( "/" ) ) {
> try {
> /******************************************************
> My Comment: When Application DB down. This block redirect
> to jetspeed default page.
> *******************************************************/
> request.getResponse().sendRedirect(request.getRequest().getContextPath());
> } catch( IOException ioe ) {
> }
> return;
> }
> ...
> ...
> }
> }
>
Are you trying to redirect to a servlet page if Jetspeed fails to
initialize? (such as when the database is down)
If yes, I think you are on the right track to fixing an 'user
experience' problem: displaying stack traces to the end user. For
example, If I change my database connection to a bad setting, and then
try to hit the portal, I get this in my browser:
javax.servlet.ServletException: Failed to initalize jetspeed.
org.apache.jetspeed.exception.JetspeedException: Unable to create Engine
org.apache.jetspeed.engine.JetspeedServlet.doGet(JetspeedServlet.java:206)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
Ugly.
I propose that the Jetspeed engine always completes initialization, even
on error conditions. The engine will have 'state' attribute to
determine if the engine is running or in
engine.getState()
returning states such as RUNNING, INITIALIZING, DOWN, ERROR
Then a valve can check the engine state, and redirect to servlet pages
based on the state, or pass thru on the RUNNING state.
This leads to an interesting challenge: what if the database comes up?
Should we just restart the app server?
Thats certainly the easiest solution.
A retry thread would be another solution
Well, I didn't mean to hijack your thread and sorry if I got off topic.
I hope we are trying to solve the same problem.
Im going to create a JIRA issue to further explore the engine state feature
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: HELP: how to ask for it! [Was: Re: ProfilerValveImpl HELP!]
Posted by Tomba Rakesh <to...@yahoo.com>.
Hi Ate/Randy
<- which db are you using (as it seems you have db problems somewhere)
<and how do you use it (if non-standard)
---------------------------------------------------------------------
We use PostgreSQL 8.0.
<- relevant stacktrace / error messages you found in the logs or the console
---------------------------------------------------------------------
No error message on cosole. But it throws SecurityException at ProfilerValveImpl which will redirect to jetspeed's default page.
public class ProfilerValveImpl extends AbstractValve
implements PageProfilerValve {
....
....
public void invoke( RequestContext request, ValveContext context )
throws PipelineException {
try {
....
....
} catch( SecurityException se ) {
if( ( request.getRequest( ).getUserPrincipal( ) == null ) &&
( request.getPath( ) != null ) &&
!request.getPath( ).equals( "/" ) ) {
try {
/******************************************************
My Comment: When Application DB down. This block redirect
to jetspeed default page.
*******************************************************/
request.getResponse().sendRedirect(request.getRequest().getContextPath());
} catch( IOException ioe ) {
}
return;
}
...
...
}
}
<- relevant configuration changes you made to the default configs
server.xml
---------------------------------------------------------------------
I include emptySessionPath="true" as follows
<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<Connector port="8080" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" emptySessionPath="true" />
<- example/snippet code of your custom classes (like your LoginErrorServlet
<you refer to, as well as the parts of web.xml you changed to be able to
<use that servlet)
---------------------------------------------------------------------
Code for DashboardLoginProxyServlet, DashboardLoginErrorServlet,
DashboardLoginRedirectorServlet
public class DashboardLoginRedirectorServlet extends HttpServlet {
public void doGet( HttpServletRequest request, HttpServletResponse response )
throws IOException, ServletException {
final String PORTAL = "/portal/";
final String PSML = ".psml";
HttpSession session = request.getSession( true );
String userName = request.getRemoteUser( );
String destination = request.getContextPath( ) + PORTAL + userName +
PSML;
response.sendRedirect( response.encodeURL( destination ) );
}
public void doPost( HttpServletRequest request, HttpServletResponse response )
throws IOException, ServletException {
doGet( request, response );
}
} // End
public class DashboardLoginErrorServlet extends HttpServlet {
public void doGet( HttpServletRequest request, HttpServletResponse response )
throws IOException, ServletException {
final String LOGIN_PAGE = "/dashboard/jsp/Login.jsp?loginError=Y";
HttpSession session = request.getSession( );
String destination = LOGIN_PAGE;
response.sendRedirect( response.encodeURL( destination ) );
}
public final void doPost( HttpServletRequest request,
HttpServletResponse response )
throws IOException, ServletException {
doGet( request, response );
}
} // DashboardLoginErrorServlet end
public class DashboardLoginProxyServlet extends HttpServlet {
public void doGet( HttpServletRequest request, HttpServletResponse response )
throws IOException, ServletException {
final String DESTINATION = "org.apache.jetspeed.login.destination";
final String USER_NAME = "org.apache.jetspeed.login.username";
final String PASSWORD = "org.apache.jetspeed.login.password";
final String REFRESH_INTERVAL_LIST = "refreshIntervalList";
final String REFRESH_RATE = "refreshRate";
final String REVIEWER_NAME = "reviewerName";
final String LOGIN_REDIRECTOR = "/login/redirector";
final String SELECT_REFRESH = "selectRefresh";
final String SELECT_REFRESH_IN_SECOND = "selectRefreshInSecond";
HttpSession session = request.getSession( true );
String parameter = request.getParameter( DESTINATION );
if( parameter != null ) {
session.setAttribute( DESTINATION, parameter );
} else {
session.removeAttribute( DESTINATION );
}
parameter = request.getParameter( USER_NAME );
if( parameter != null ) {
session.setAttribute( USER_NAME, parameter );
} else {
session.removeAttribute( USER_NAME );
}
parameter = request.getParameter( PASSWORD );
if( parameter != null ) {
session.setAttribute( PASSWORD, parameter );
} else {
session.removeAttribute( PASSWORD );
}
/* For Page Refresh start */
String[] refreshIntervalList = request.getParameterValues( REFRESH_INTERVAL_LIST );
String refreshRate = request.getParameter( REFRESH_RATE );
String reviewerName = request.getParameter( REVIEWER_NAME );
String refreshRateInSecond = request.getParameter( SELECT_REFRESH_IN_SECOND );
session.setAttribute( REFRESH_INTERVAL_LIST, refreshIntervalList );
session.setAttribute( SELECT_REFRESH, refreshRate );
session.setAttribute( REVIEWER_NAME, reviewerName );
session.setAttribute( SELECT_REFRESH_IN_SECOND, refreshRateInSecond );
/* For Page Refresh end */
response.sendRedirect( response.encodeURL( request.getContextPath( ) +
LOGIN_REDIRECTOR ) );
}
public final void doPost( HttpServletRequest request,
HttpServletResponse response )
throws IOException, ServletException {
doGet( request, response );
}
} // DashboardLoginProxyServlet end
Jetspeed web.xml
----------------
<servlet>
<servlet-name>LoginProxyServlet</servlet-name>
<!--<servlet-class>org.apache.jetspeed.login.LoginProxyServlet</servlet-class>-->
<servlet-class>dashboard.login.DashboardLoginProxyServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>LoginErrorServlet</servlet-name>
<!--<servlet-class>org.apache.jetspeed.login.LoginErrorServlet</servlet-class>-->
<servlet-class>dashboard.login.DashboardLoginErrorServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>LoginRedirectorServlet</servlet-name>
<!--<servlet-class>org.apache.jetspeed.login.LoginRedirectorServlet</servlet-class>-->
<servlet-class>dashboard.login.DashboardLoginRedirectorServlet</servlet-class>
</servlet>
user01.psml file located at jetspeed/WEB-INF/pages
-----------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<page id="/user01.psml" hidden="false">
<security-constraints>
<security-constraint>
<users>user01</users>
<permissions>view,edit</permissions>
</security-constraint>
</security-constraints>
<title>[user01] Page</title>
<short-title>[user01] Page</short-title>
<defaults skin="orange" layout-decorator="mylayout" portlet-decorator="myportlet"/>
<fragment id="vericept" type="layout" name="jetspeed-layouts::VelocityTwoColumns">
<fragment id="P-105c32546ee-10001" type="portlet" name="dashboard::topbandwidthusage">
<property name="row" value="0" layout="TwoColumns"/>
<property name="column" value="0" layout="TwoColumns"/>
</fragment>
<fragment id="P-105c394ba24-10001" type="portlet" name="dashboard::topcategories">
<property name="row" value="0" layout="TwoColumns"/>
<property name="column" value="1" layout="TwoColumns"/>
</fragment>
</fragment>
</page>
<- a logical description of what you are trying to achieve and how it fails
<(like a sequence of interactions leading to the error(s)).
---------------------------------------------------------------------
1: Application Database down
2. Login using DashboardLoginProxyServlet
3. Redirect user psml using DashboardLoginRedirectorServlet
for user01: http://localhost:8080/jetspeed/portal/user01.psml
4. ProfilerValveImpl calls and SecurityException thrown
catch( SecurityException se ) {
if( ( request.getRequest( ).getUserPrincipal( ) == null ) &&
( request.getPath( ) != null ) &&
!request.getPath( ).equals( "/" ) ) {
try {
/******************************************************
My Comment: When Application DB down. This block redirect
to jetspeed default page.
*******************************************************/
request.getResponse().sendRedirect(request.getRequest().getContextPath());
} catch( IOException ioe ) {
}
return;
}
...
...
}
5. Page redirect to jetspeed default page (Portlet does not invoke).
Regards
Rakesh
Ate Douma <at...@douma.nu> wrote:
Rakesh,
I'd like to add an important comment to those already made by Randy below
and before.
We (the Jetspeed team) will gladly help anyone out as far as we can but
for that you need to provide us with enough information to go by, like:
- which db are you using (as it seems you have db problems somewhere)
and how do you use it (if non-standard)
- relevant stacktrace / error messages you found in the logs or the console
- relevant configuration changes you made to the default configs
- example/snippet code of your custom classes (like your LoginErrorServlet
you refer to, as well as the parts of web.xml you changed to be able to
use that servlet)
- a logical description of what you are trying to achieve and how it fails
(like a sequence of interactions leading to the error(s)).
Without something concrete like these, we only can guess what your real
problem is and takes far to much of our valuable time.
So please, if you can describe your exact problem and provide us with
the information like I described above, we will gladly try to help out
and get this solved.
Regards,
Ate
Randy Watler wrote:
> Rakesh,
>
> Ok... I think I can finally answer your questions!
>
> While I cannot tell you what is going wrong when you attempt to use a
> different servlet in the login process, I do not think you need one.
> Using the standard profiling rule, J2 will look for a user specific page
> in ../WEB_INF/pages/_user//default-page.psml. If that fails,
> it will fallback to ../WEB_INF/pages/default-page.psml. When there is no
> authenticated login, (i.e. before a successful login), it will look in
> ../WEB_INF/pages/_user/guest/default-page.psml before falling back to
> ../WEB_INF/pages/default-page.psml. Perhaps you already have this
> working. If so, I am still interested in knowing why you want to use a
> new login servlet.
>
> When you shut down your application database, I find it difficult to
> believe that J2 fails to load the correct page. I do not think that you
> need to extend ProfierValveImpl to handle errors/exceptions in your
> portlets. In fact, if J2 breaks because your portlets fail to access the
> application DB, that would be a J2 bug... it should not be possible. So,
> I am afraid I have the same response for you here: it is the individual
> portlet's responsibility to catch errors and redirect accordingly in the
> action phase of portlet execution. To be clear: if the ProfilerValveImpl
> is falling back to the root level default page when there is an
> application DB access error, there is a bug in J2. You should not be
> catching this kind of problem in the J2 request pipeline.
>
> HTH,
>
> Randy
>
> Tomba Rakesh wrote:
>
>> Hi Randy
>>
>> >Are you really redirecting to a user specific failed login page? This
>> >seems strange to me. We have lots of support to redirect to a
>> >user/role/group specific page on successful login. Seems like a failed
>> >login might want to redirect to a common page. Am I reading this wrong?
>>
>> When login fail we use LoginErrorServlet for redirecting error page.
>>
>> For login success we redirect to user specific psml file. We define
>> custom layout and decoration so that only one psml file will be
>> displayed. Client requirement have only one psml file for each user.
>> We don't have any group or role psml file.
>>
>> So far we don't have any problem in login, redirect and login error.
>>
>> I was asking for login, is it possible to use a new LoginServlet other
>> than LoginProxyServlet(jetspeed login servlet). When I tried new
>> servlet and defined in jetspeed's app web.xml it does not work.
>>
>> >To be specific: the database you shutdown contains J2 tables for
>> >portlets, security, etc., or just your application data? Seems like only
>> >missing J2 data would effect the page mapping of request urls, no?
>>
>> Database which I shutdown does not contain J2 tables for portlets,
>> security, etc., this is our application data.
>>
>> Regards
>> Rakesh
>>
>> */Randy Watler /* wrote:
>>
>> Rakesh,
>>
>> Further clarification still needed... i must be missing something!
>>
>> Randy
>>
>> Tomba Rakesh wrote:
>>
>> >Hi Randy
>> >
>> >
>> >
>> >>1. did you register and add the new servlet in the web.xml of the
>> >>security app?
>> >>
>> >>
>> >
>> >I am adding new servlet as well as new servlet entry to web.xml
>> (web.xml for jetspeed app, not web.xml for security app).
>> >
>> >
>> >
>> >>2. what functionality would you have added if you were
>> successful in
>> >>using your own servlet?
>> >>
>> >>
>> >
>> >Functionality added: just redirected to user specific psml file.
>> For example for user01
>> >it redirected to
>> >http://localhost:8080/jetspeed/portal/user01.psml
>> >
>> >
>> Are you really redirecting to a user specific failed login page? This
>> seems strange to me. We have lots of support to redirect to a
>> user/role/group specific page on successful login. Seems like a
>> failed
>> login might want to redirect to a common page. Am I reading this
>> wrong?
>>
>> >>Ok... you took down the J2 DB? If so, I missed that. I'd prefer to
>> >>handle that as part of the J2 product if at all possible... this
>> is not
>> >>unique to the ProfilerValveImpl but it may show up there first.
>> Most
>> >>likely, we'll end up returning an HTTP error status code and you
>> can
>> >>customize the returned page in the container for the HTTP page.
>> Will
>> >>that work for you?
>> >>
>> >>
>> >
>> >I took "External Database" down not the J2 DB (Hypersonic).
>> External database is the place where actual user data are stored.
>> >
>> To be specific: the database you shutdown contains J2 tables for
>> portlets, security, etc., or just your application data? Seems
>> like only
>> missing J2 data would effect the page mapping of request urls, no?
>>
>> Randy
>>
>> >
>> >Regards
>> >Rakesh
>> >
>> >Randy Watler wrote:
>> >Rakesh,
>> >
>> >
>> >
>> >Tomba Rakesh wrote:
>> >
>> >
>> >
>> >>Hi Randy
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>Is there some feature that
>> >>>is missing here that you'd like to see? If so, it might be general
>> >>>enough to be added to the product.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>For login, jetspeed use LoginProxyServlet. When I try new
>> servlet(same functionality as LoginProxyServlet) for login it does
>> not work. Is there any way to provide a new servlet (without
>> touching LoginProxyServlet) for login.
>> >>
>> >>
>> >>
>> >I am not sure what is going wrong here... two points for
>> clarification:
>> >
>> >1. did you register and add the new servlet in the web.xml of the
>> >security app?
>> >2. what functionality would you have added if you were successful in
>> >using your own servlet?
>> >
>> >
>> >
>> >>
>> >>
>> >>
>> >>>>For Database connection fail, Jetspeed use ProfilerValveImpl
>> for redirecting.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>This seems incorrect. The portlets themselves must take
>> responsibility
>> >>>for handling errors. In turn, they can redirect and/or modify
>> session
>> >>>state so that subsequent requests to the portal are routed
>> based on a
>> >>>dfferent set of profiling rules.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>Every user we have specific psml file, for user user01 we have
>> >>http://localhost:8080/jetspeed/portal/user01.psml [Contains our
>> portlets]
>> >>
>> >>After database is down. Any try to open
>> "http://localhost:8080/jetspeed/portal/user01.psml" goes to
>> jetspeed default page.
>> >>
>> >>Our portlets takes the responsibility for handling errors, but
>> the portlets are not being call. Instead of calling the portlets
>> specified in the psml file. Jetspeed calls ProfilerValveImpl. So
>> by modifying ProfilerValveImpl I could redirect to any page.
>> >>
>> >>Suggest me how to tackle this issue. Is there any better
>> approach....
>> >>
>> >>
>> >>
>> >>
>> >Ok... you took down the J2 DB? If so, I missed that. I'd prefer to
>> >handle that as part of the J2 product if at all possible... this
>> is not
>> >unique to the ProfilerValveImpl but it may show up there first. Most
>> >likely, we'll end up returning an HTTP error status code and you can
>> >customize the returned page in the container for the HTTP page. Will
>> >that work for you?
>> >
>> >Randy
>> >
>> >
>> >
>> >>Regards
>> >>Rakesh
>> >>
>> >>Randy Watler wrote:
>> >>Rakesh:
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>For login error, redirect using LoginErrorServlet.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>Seems correct, but I cannot contribute much here because it has
>> been a
>> >>while since I did much with the login processing. It seems to me
>> that
>> >>the existing implementation handles this smoothy, including login
>> >>failure counts and other security features. Is there some
>> feature that
>> >>is missing here that you'd like to see? If so, it might be general
>> >>enough to be added to the product.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>For Database connection fail, Jetspeed use ProfilerValveImpl
>> for redirecting.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>This seems incorrect. The portlets themselves must take
>> responsibility
>> >>for handling errors. In turn, they can redirect and/or modify
>> session
>> >>state so that subsequent requests to the portal are routed based
>> on a
>> >>different set of profiling rules. The security application uses
>> this
>> >>technique to force the end user to change passwords using the
>> >>"MyAccount.psml" page. Here, you may want to simply force the
>> display of
>> >>a DBIsDown.psml page using a profiling rule override. Note that the
>> >>profiler is very flexible and can be used in many different ways to
>> >>interpret request urls... all without code modification of any
>> sort. So,
>> >>yes, the profiler is performing the "redirection" in a sense,
>> but it
>> >>does not require programmatic extension.
>> >>
>> >>HTH,
>> >>
>> >>Randy
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>The way I tested:
>> >>>1. Shut down external database (Not Hypersonic Database )
>> >>>2. In normal, when user login, it goes to user specific psml
>> file. And whatever portlets mentioned in the psml file gets
>> displayed. The information displayed by the portlets are from
>> external database.
>> >>>3. As in step 1 database is down. As database is not available,
>> by default jetspeed call ProfilerValveImpl (portlet code are not
>> executing) and redirects to jetspeed default page. So instead of
>> displaying jetspeed default page, I would like to display some
>> error message as "Database is down".
>> >>>
>> >>>Please correct me if I am wrong:
>> >>>I use ProfilerValveImpl for handling psml file Exception (No
>> database available).
>> >>>
>> >>>Regards
>> >>>Rakesh
>> >>>
>> >>>Randy Watler wrote:
>> >>>Rakesh,
>> >>>
>> >>>I am afraid I do not understand your needs fully, so it is hard to
>> >>>suggest the best implementation.
>> >>>
>> >>>Exactly under what conditions do you want to redirect to an
>> error page
>> >>>instead of the default page? If it is after a failed login,
>> there might
>> >>>be a better way to accomplish what you are after.
>> >>>
>> >>>Randy
>> >>>
>> >>>Tomba Rakesh wrote:
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>Hi Randy
>> >>>>
>> >>>>Thanks for your quick response. Sorry I really forgot, that's
>> why it was cross post.
>> >>>>Actually my requirement is redirect to our error page if
>> something goes wrong. By default it redirect to jetspeed's
>> default-page.psml
>> >>>>
>> >>>>Types of Login:
>> >>>>Type 1. Once user sucessfully login to our application,
>> username and password is redirected to jetspeed's LoginProxyServlet.
>> >>>>Type 2. Login from jetspeed's default page.
>> >>>>
>> >>>>For login Type 2, we would like forward to jetspeed default
>> page. For Type 1, we would like forward to our error page.
>> >>>>
>> >>>>So if have a class MyProfilerValveImpl this will always
>> redirected to our page. Where to put this entry before or after
>> ProfilerValveImpl.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>>class="org.apache.jetspeed.profiler.impl.ProfilerValveImpl"
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>init-method="initialize"
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>Regards
>> >>>>Rakesh
>> >>>>
>> >>>>Randy Watler wrote:
>> >>>>Rakesh,
>> >>>>
>> >>>>I have asked before... please do NOT cross post to this list
>> and the dev
>> >>>>list.
>> >>>>
>> >>>>The ProfilerValveImpl is part of the J2 request pipeline. It is
>> >>>>configured using spring in the assembly/pipelines.xml file.
>> >>>>
>> >>>>However, it is non-trivial to replace its functionality. If
>> you simply
>> >>>>want to extend it, you might want to consider adding
>> additional stages
>> >>>>in the pipeline before or after the existing impl instead.
>> >>>>
>> >>>>Randy
>> >>>>
>> >>>>Tomba Rakesh wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>>Hi All
>> >>>>>
>> >>>>>1. Which class or servlet calls
>> org.apache.jetspeed.profiler.impl.ProfilerValveImpl
>> >>>>>2. Is it possible to provide a new ProfilerValveImpl, if so
>> where where to configuration?
>> >>>>>
>> >>>>>Thanks in advance
>> >>>>>
>> >>>>>Regards
>> >>>>>Rakesh
>> >>>>>
>> >>>>>
>> >>>>>__________________________________________________
>> >>>>>Do You Yahoo!?
>> >>>>>Tired of spam? Yahoo! Mail has the best spam protection around
>> >>>>>http://mail.yahoo.com
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>>
>> >>>>---------------------------------------------------------------------
>> >>>>To unsubscribe, e-mail:
>> jetspeed-user-unsubscribe@portals.apache.org
>> >>>>For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>> >>>>
>> >>>>
>> >>>>__________________________________________________
>> >>>>Do You Yahoo!?
>> >>>>Tired of spam? Yahoo! Mail has the best spam protection around
>> >>>>http://mail.yahoo.com
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>>
>> >>>---------------------------------------------------------------------
>> >>>To unsubscribe, e-mail:
>> jetspeed-user-unsubscribe@portals.apache.org
>> >>>For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>> >>>
>> >>>
>> >>>__________________________________________________
>> >>>Do You Yahoo!?
>> >>>Tired of spam? Yahoo! Mail has the best spam protection around
>> >>>http://mail.yahoo.com
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>>
>> >>---------------------------------------------------------------------
>> >>To unsubscribe, e-mail:
>> jetspeed-user-unsubscribe@portals.apache.org
>> >>For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>> >>
>> >>
>> >>__________________________________________________
>> >>Do You Yahoo!?
>> >>Tired of spam? Yahoo! Mail has the best spam protection around
>> >>http://mail.yahoo.com
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> >For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>> >
>> >
>> >
>> >---------------------------------
>> > Start your day with Yahoo! - make it your home page
>> >
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: HELP: how to ask for it! [Was: Re: ProfilerValveImpl HELP!]
Posted by Tomba Rakesh <to...@yahoo.com>.
Hi Ate/Randy
<- which db are you using (as it seems you have db problems somewhere)
<and how do you use it (if non-standard)
---------------------------------------------------------------------
We use PostgreSQL 8.0.
<- relevant stacktrace / error messages you found in the logs or the console
---------------------------------------------------------------------
No error message on cosole. But it throws SecurityException at ProfilerValveImpl which will redirect to jetspeed's default page.
public class ProfilerValveImpl extends AbstractValve
implements PageProfilerValve {
....
....
public void invoke( RequestContext request, ValveContext context )
throws PipelineException {
try {
....
....
} catch( SecurityException se ) {
if( ( request.getRequest( ).getUserPrincipal( ) == null ) &&
( request.getPath( ) != null ) &&
!request.getPath( ).equals( "/" ) ) {
try {
/******************************************************
My Comment: When Application DB down. This block redirect
to jetspeed default page.
*******************************************************/
request.getResponse().sendRedirect(request.getRequest().getContextPath());
} catch( IOException ioe ) {
}
return;
}
...
...
}
}
<- relevant configuration changes you made to the default configs
server.xml
---------------------------------------------------------------------
I include emptySessionPath="true" as follows
<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<Connector port="8080" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" emptySessionPath="true" />
<- example/snippet code of your custom classes (like your LoginErrorServlet
<you refer to, as well as the parts of web.xml you changed to be able to
<use that servlet)
---------------------------------------------------------------------
Code enclose for DashboardLoginProxyServlet, DashboardLoginErrorServlet, DashboardLoginRedirectorServlet
public class DashboardLoginRedirectorServlet extends HttpServlet {
public void doGet( HttpServletRequest request, HttpServletResponse response )
throws IOException, ServletException {
final String PORTAL = "/portal/";
final String PSML = ".psml";
HttpSession session = request.getSession( true );
String userName = request.getRemoteUser( );
String destination = request.getContextPath( ) + PORTAL + userName +
PSML;
response.sendRedirect( response.encodeURL( destination ) );
}
public void doPost( HttpServletRequest request, HttpServletResponse response )
throws IOException, ServletException {
doGet( request, response );
}
} // End DashboardLoginRedirectorServlet
public class DashboardLoginErrorServlet extends HttpServlet {
public void doGet( HttpServletRequest request, HttpServletResponse response )
throws IOException, ServletException {
final String LOGIN_PAGE = "/dashboard/jsp/Login.jsp?loginError=Y";
HttpSession session = request.getSession( );
String destination = LOGIN_PAGE;
response.sendRedirect( response.encodeURL( destination ) );
}
public final void doPost( HttpServletRequest request,
HttpServletResponse response )
throws IOException, ServletException {
doGet( request, response );
}
} // DashboardLoginErrorServlet end
public class DashboardLoginProxyServlet extends HttpServlet {
public void doGet( HttpServletRequest request, HttpServletResponse response )
throws IOException, ServletException {
final String DESTINATION = "org.apache.jetspeed.login.destination";
final String USER_NAME = "org.apache.jetspeed.login.username";
final String PASSWORD = "org.apache.jetspeed.login.password";
final String REFRESH_INTERVAL_LIST = "refreshIntervalList";
final String REFRESH_RATE = "refreshRate";
final String REVIEWER_NAME = "reviewerName";
final String LOGIN_REDIRECTOR = "/login/redirector";
final String SELECT_REFRESH = "selectRefresh";
final String SELECT_REFRESH_IN_SECOND = "selectRefreshInSecond";
HttpSession session = request.getSession( true );
String parameter = request.getParameter( DESTINATION );
if( parameter != null ) {
session.setAttribute( DESTINATION, parameter );
} else {
session.removeAttribute( DESTINATION );
}
parameter = request.getParameter( USER_NAME );
if( parameter != null ) {
session.setAttribute( USER_NAME, parameter );
} else {
session.removeAttribute( USER_NAME );
}
parameter = request.getParameter( PASSWORD );
if( parameter != null ) {
session.setAttribute( PASSWORD, parameter );
} else {
session.removeAttribute( PASSWORD );
}
/* For Page Refresh start */
String[] refreshIntervalList = request.getParameterValues( REFRESH_INTERVAL_LIST );
String refreshRate = request.getParameter( REFRESH_RATE );
String reviewerName = request.getParameter( REVIEWER_NAME );
String refreshRateInSecond = request.getParameter( SELECT_REFRESH_IN_SECOND );
session.setAttribute( REFRESH_INTERVAL_LIST, refreshIntervalList );
session.setAttribute( SELECT_REFRESH, refreshRate );
session.setAttribute( REVIEWER_NAME, reviewerName );
session.setAttribute( SELECT_REFRESH_IN_SECOND, refreshRateInSecond );
/* For Page Refresh end */
response.sendRedirect( response.encodeURL( request.getContextPath( ) +
LOGIN_REDIRECTOR ) );
}
public final void doPost( HttpServletRequest request,
HttpServletResponse response )
throws IOException, ServletException {
doGet( request, response );
}
} // DashboardLoginProxyServlet end
Jetspeed web.xml
----------------
<servlet>
<servlet-name>LoginProxyServlet</servlet-name>
<!--<servlet-class>org.apache.jetspeed.login.LoginProxyServlet</servlet-class>-->
<servlet-class>dashboard.login.DashboardLoginProxyServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>LoginErrorServlet</servlet-name>
<!--<servlet-class>org.apache.jetspeed.login.LoginErrorServlet</servlet-class>-->
<servlet-class>dashboard.login.DashboardLoginErrorServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>LoginRedirectorServlet</servlet-name>
<!--<servlet-class>org.apache.jetspeed.login.LoginRedirectorServlet</servlet-class>-->
<servlet-class>dashboard.login.DashboardLoginRedirectorServlet</servlet-class>
</servlet>
user01.psml file located at jetspeed/WEB-INF/pages
-----------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<page id="/user01.psml" hidden="false">
<security-constraints>
<security-constraint>
<users>user01</users>
<permissions>view,edit</permissions>
</security-constraint>
</security-constraints>
<title>[user01] Page</title>
<short-title>[user01] Page</short-title>
<defaults skin="orange" layout-decorator="mylayout" portlet-decorator="myportlet"/>
<fragment id="vericept" type="layout" name="jetspeed-layouts::VelocityTwoColumns">
<fragment id="P-105c32546ee-10001" type="portlet" name="dashboard::topbandwidthusage">
<property name="row" value="0" layout="TwoColumns"/>
<property name="column" value="0" layout="TwoColumns"/>
</fragment>
<fragment id="P-105c394ba24-10001" type="portlet" name="dashboard::topcategories">
<property name="row" value="0" layout="TwoColumns"/>
<property name="column" value="1" layout="TwoColumns"/>
</fragment>
</fragment>
</page>
<- a logical description of what you are trying to achieve and how it fails
<(like a sequence of interactions leading to the error(s)).
---------------------------------------------------------------------
1: Application Database down
2. Login using DashboardLoginProxyServlet
3. Redirect user psml using DashboardLoginRedirectorServlet
for user01: http://localhost:8080/jetspeed/portal/user01.psml
4. ProfilerValveImpl calls and SecurityException thrown
catch( SecurityException se ) {
if( ( request.getRequest( ).getUserPrincipal( ) == null ) &&
( request.getPath( ) != null ) &&
!request.getPath( ).equals( "/" ) ) {
try {
/******************************************************
My Comment: When Application DB down. This block redirect
to jetspeed default page.
*******************************************************/
request.getResponse().sendRedirect(request.getRequest().getContextPath());
} catch( IOException ioe ) {
}
return;
}
...
...
}
5. Page redirect to jetspeed default page.
Regards
Rakesh
Ate Douma <at...@douma.nu> wrote:
Rakesh,
I'd like to add an important comment to those already made by Randy below
and before.
We (the Jetspeed team) will gladly help anyone out as far as we can but
for that you need to provide us with enough information to go by, like:
- which db are you using (as it seems you have db problems somewhere)
and how do you use it (if non-standard)
- relevant stacktrace / error messages you found in the logs or the console
- relevant configuration changes you made to the default configs
- example/snippet code of your custom classes (like your LoginErrorServlet
you refer to, as well as the parts of web.xml you changed to be able to
use that servlet)
- a logical description of what you are trying to achieve and how it fails
(like a sequence of interactions leading to the error(s)).
Without something concrete like these, we only can guess what your real
problem is and takes far to much of our valuable time.
So please, if you can describe your exact problem and provide us with
the information like I described above, we will gladly try to help out
and get this solved.
Regards,
Ate
Randy Watler wrote:
> Rakesh,
>
> Ok... I think I can finally answer your questions!
>
> While I cannot tell you what is going wrong when you attempt to use a
> different servlet in the login process, I do not think you need one.
> Using the standard profiling rule, J2 will look for a user specific page
> in ../WEB_INF/pages/_user//default-page.psml. If that fails,
> it will fallback to ../WEB_INF/pages/default-page.psml. When there is no
> authenticated login, (i.e. before a successful login), it will look in
> ../WEB_INF/pages/_user/guest/default-page.psml before falling back to
> ../WEB_INF/pages/default-page.psml. Perhaps you already have this
> working. If so, I am still interested in knowing why you want to use a
> new login servlet.
>
> When you shut down your application database, I find it difficult to
> believe that J2 fails to load the correct page. I do not think that you
> need to extend ProfierValveImpl to handle errors/exceptions in your
> portlets. In fact, if J2 breaks because your portlets fail to access the
> application DB, that would be a J2 bug... it should not be possible. So,
> I am afraid I have the same response for you here: it is the individual
> portlet's responsibility to catch errors and redirect accordingly in the
> action phase of portlet execution. To be clear: if the ProfilerValveImpl
> is falling back to the root level default page when there is an
> application DB access error, there is a bug in J2. You should not be
> catching this kind of problem in the J2 request pipeline.
>
> HTH,
>
> Randy
>
> Tomba Rakesh wrote:
>
>> Hi Randy
>>
>> >Are you really redirecting to a user specific failed login page? This
>> >seems strange to me. We have lots of support to redirect to a
>> >user/role/group specific page on successful login. Seems like a failed
>> >login might want to redirect to a common page. Am I reading this wrong?
>>
>> When login fail we use LoginErrorServlet for redirecting error page.
>>
>> For login success we redirect to user specific psml file. We define
>> custom layout and decoration so that only one psml file will be
>> displayed. Client requirement have only one psml file for each user.
>> We don't have any group or role psml file.
>>
>> So far we don't have any problem in login, redirect and login error.
>>
>> I was asking for login, is it possible to use a new LoginServlet other
>> than LoginProxyServlet(jetspeed login servlet). When I tried new
>> servlet and defined in jetspeed's app web.xml it does not work.
>>
>> >To be specific: the database you shutdown contains J2 tables for
>> >portlets, security, etc., or just your application data? Seems like only
>> >missing J2 data would effect the page mapping of request urls, no?
>>
>> Database which I shutdown does not contain J2 tables for portlets,
>> security, etc., this is our application data.
>>
>> Regards
>> Rakesh
>>
>> */Randy Watler /* wrote:
>>
>> Rakesh,
>>
>> Further clarification still needed... i must be missing something!
>>
>> Randy
>>
>> Tomba Rakesh wrote:
>>
>> >Hi Randy
>> >
>> >
>> >
>> >>1. did you register and add the new servlet in the web.xml of the
>> >>security app?
>> >>
>> >>
>> >
>> >I am adding new servlet as well as new servlet entry to web.xml
>> (web.xml for jetspeed app, not web.xml for security app).
>> >
>> >
>> >
>> >>2. what functionality would you have added if you were
>> successful in
>> >>using your own servlet?
>> >>
>> >>
>> >
>> >Functionality added: just redirected to user specific psml file.
>> For example for user01
>> >it redirected to
>> >http://localhost:8080/jetspeed/portal/user01.psml
>> >
>> >
>> Are you really redirecting to a user specific failed login page? This
>> seems strange to me. We have lots of support to redirect to a
>> user/role/group specific page on successful login. Seems like a
>> failed
>> login might want to redirect to a common page. Am I reading this
>> wrong?
>>
>> >>Ok... you took down the J2 DB? If so, I missed that. I'd prefer to
>> >>handle that as part of the J2 product if at all possible... this
>> is not
>> >>unique to the ProfilerValveImpl but it may show up there first.
>> Most
>> >>likely, we'll end up returning an HTTP error status code and you
>> can
>> >>customize the returned page in the container for the HTTP page.
>> Will
>> >>that work for you?
>> >>
>> >>
>> >
>> >I took "External Database" down not the J2 DB (Hypersonic).
>> External database is the place where actual user data are stored.
>> >
>> To be specific: the database you shutdown contains J2 tables for
>> portlets, security, etc., or just your application data? Seems
>> like only
>> missing J2 data would effect the page mapping of request urls, no?
>>
>> Randy
>>
>> >
>> >Regards
>> >Rakesh
>> >
>> >Randy Watler wrote:
>> >Rakesh,
>> >
>> >
>> >
>> >Tomba Rakesh wrote:
>> >
>> >
>> >
>> >>Hi Randy
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>Is there some feature that
>> >>>is missing here that you'd like to see? If so, it might be general
>> >>>enough to be added to the product.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>For login, jetspeed use LoginProxyServlet. When I try new
>> servlet(same functionality as LoginProxyServlet) for login it does
>> not work. Is there any way to provide a new servlet (without
>> touching LoginProxyServlet) for login.
>> >>
>> >>
>> >>
>> >I am not sure what is going wrong here... two points for
>> clarification:
>> >
>> >1. did you register and add the new servlet in the web.xml of the
>> >security app?
>> >2. what functionality would you have added if you were successful in
>> >using your own servlet?
>> >
>> >
>> >
>> >>
>> >>
>> >>
>> >>>>For Database connection fail, Jetspeed use ProfilerValveImpl
>> for redirecting.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>This seems incorrect. The portlets themselves must take
>> responsibility
>> >>>for handling errors. In turn, they can redirect and/or modify
>> session
>> >>>state so that subsequent requests to the portal are routed
>> based on a
>> >>>dfferent set of profiling rules.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>Every user we have specific psml file, for user user01 we have
>> >>http://localhost:8080/jetspeed/portal/user01.psml [Contains our
>> portlets]
>> >>
>> >>After database is down. Any try to open
>> "http://localhost:8080/jetspeed/portal/user01.psml" goes to
>> jetspeed default page.
>> >>
>> >>Our portlets takes the responsibility for handling errors, but
>> the portlets are not being call. Instead of calling the portlets
>> specified in the psml file. Jetspeed calls ProfilerValveImpl. So
>> by modifying ProfilerValveImpl I could redirect to any page.
>> >>
>> >>Suggest me how to tackle this issue. Is there any better
>> approach....
>> >>
>> >>
>> >>
>> >>
>> >Ok... you took down the J2 DB? If so, I missed that. I'd prefer to
>> >handle that as part of the J2 product if at all possible... this
>> is not
>> >unique to the ProfilerValveImpl but it may show up there first. Most
>> >likely, we'll end up returning an HTTP error status code and you can
>> >customize the returned page in the container for the HTTP page. Will
>> >that work for you?
>> >
>> >Randy
>> >
>> >
>> >
>> >>Regards
>> >>Rakesh
>> >>
>> >>Randy Watler wrote:
>> >>Rakesh:
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>For login error, redirect using LoginErrorServlet.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>Seems correct, but I cannot contribute much here because it has
>> been a
>> >>while since I did much with the login processing. It seems to me
>> that
>> >>the existing implementation handles this smoothy, including login
>> >>failure counts and other security features. Is there some
>> feature that
>> >>is missing here that you'd like to see? If so, it might be general
>> >>enough to be added to the product.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>For Database connection fail, Jetspeed use ProfilerValveImpl
>> for redirecting.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>This seems incorrect. The portlets themselves must take
>> responsibility
>> >>for handling errors. In turn, they can redirect and/or modify
>> session
>> >>state so that subsequent requests to the portal are routed based
>> on a
>> >>different set of profiling rules. The security application uses
>> this
>> >>technique to force the end user to change passwords using the
>> >>"MyAccount.psml" page. Here, you may want to simply force the
>> display of
>> >>a DBIsDown.psml page using a profiling rule override. Note that the
>> >>profiler is very flexible and can be used in many different ways to
>> >>interpret request urls... all without code modification of any
>> sort. So,
>> >>yes, the profiler is performing the "redirection" in a sense,
>> but it
>> >>does not require programmatic extension.
>> >>
>> >>HTH,
>> >>
>> >>Randy
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>The way I tested:
>> >>>1. Shut down external database (Not Hypersonic Database )
>> >>>2. In normal, when user login, it goes to user specific psml
>> file. And whatever portlets mentioned in the psml file gets
>> displayed. The information displayed by the portlets are from
>> external database.
>> >>>3. As in step 1 database is down. As database is not available,
>> by default jetspeed call ProfilerValveImpl (portlet code are not
>> executing) and redirects to jetspeed default page. So instead of
>> displaying jetspeed default page, I would like to display some
>> error message as "Database is down".
>> >>>
>> >>>Please correct me if I am wrong:
>> >>>I use ProfilerValveImpl for handling psml file Exception (No
>> database available).
>> >>>
>> >>>Regards
>> >>>Rakesh
>> >>>
>> >>>Randy Watler wrote:
>> >>>Rakesh,
>> >>>
>> >>>I am afraid I do not understand your needs fully, so it is hard to
>> >>>suggest the best implementation.
>> >>>
>> >>>Exactly under what conditions do you want to redirect to an
>> error page
>> >>>instead of the default page? If it is after a failed login,
>> there might
>> >>>be a better way to accomplish what you are after.
>> >>>
>> >>>Randy
>> >>>
>> >>>Tomba Rakesh wrote:
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>Hi Randy
>> >>>>
>> >>>>Thanks for your quick response. Sorry I really forgot, that's
>> why it was cross post.
>> >>>>Actually my requirement is redirect to our error page if
>> something goes wrong. By default it redirect to jetspeed's
>> default-page.psml
>> >>>>
>> >>>>Types of Login:
>> >>>>Type 1. Once user sucessfully login to our application,
>> username and password is redirected to jetspeed's LoginProxyServlet.
>> >>>>Type 2. Login from jetspeed's default page.
>> >>>>
>> >>>>For login Type 2, we would like forward to jetspeed default
>> page. For Type 1, we would like forward to our error page.
>> >>>>
>> >>>>So if have a class MyProfilerValveImpl this will always
>> redirected to our page. Where to put this entry before or after
>> ProfilerValveImpl.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>>class="org.apache.jetspeed.profiler.impl.ProfilerValveImpl"
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>init-method="initialize"
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>Regards
>> >>>>Rakesh
>> >>>>
>> >>>>Randy Watler wrote:
>> >>>>Rakesh,
>> >>>>
>> >>>>I have asked before... please do NOT cross post to this list
>> and the dev
>> >>>>list.
>> >>>>
>> >>>>The ProfilerValveImpl is part of the J2 request pipeline. It is
>> >>>>configured using spring in the assembly/pipelines.xml file.
>> >>>>
>> >>>>However, it is non-trivial to replace its functionality. If
>> you simply
>> >>>>want to extend it, you might want to consider adding
>> additional stages
>> >>>>in the pipeline before or after the existing impl instead.
>> >>>>
>> >>>>Randy
>> >>>>
>> >>>>Tomba Rakesh wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>>Hi All
>> >>>>>
>> >>>>>1. Which class or servlet calls
>> org.apache.jetspeed.profiler.impl.ProfilerValveImpl
>> >>>>>2. Is it possible to provide a new ProfilerValveImpl, if so
>> where where to configuration?
>> >>>>>
>> >>>>>Thanks in advance
>> >>>>>
>> >>>>>Regards
>> >>>>>Rakesh
---------------------------------
Start your day with Yahoo! - make it your home page