Examples with WOResponse com.webobjects.appserver.WOResponse used on opensource projects

Example 6 with WOResponse

use of com.webobjects.appserver.WOResponse in project wonder-slim by undur.

the class ERXAjaxApplication method shouldNotStorePage.

/**
 * Checks if the page should not be stored in the cache
 */
public static boolean shouldNotStorePage(WOContext context) {
    WORequest request = context.request();
    WOResponse response = context.response();
    // MS: The "AJAX_SUBMIT_BUTTON_NAME" check is a total hack, but if your
    // page structure changes such that the form that
    // is being submitted to is hidden, it ends up not notifying the system
    // not to cache the page.
    boolean shouldNotStorePage = (shouldNotStorePage(response) || shouldNotStorePage(request) || isAjaxSubmit(request)) && !forceStorePage(response);
    return shouldNotStorePage;
}

Example 7 with WOResponse

use of com.webobjects.appserver.WOResponse in project wonder-slim by undur.

the class ERXAjaxApplication method invokeAction.

/**
 * Overridden to allow for redirected responses.
 */
@Override
public WOActionResults invokeAction(WORequest request, WOContext context) {
    WOActionResults results = super.invokeAction(request, context);
    // wrong
    if (ERXAjaxApplication.shouldNotStorePage(context)) {
        if (shouldIgnoreResults(request, context, results)) {
            results = null;
        }
        if (results == null && !ERXAjaxApplication.isAjaxReplacement(request)) {
            WOResponse response = context.response();
            if (_responseDelegate != null) {
                results = _responseDelegate.handleNullActionResults(request, response, context);
                response = context.response();
            }
            // MS: We were removing headers, and I really don't know WHY.  It was causing AUC's
            // inside of AjaxModalDialogs to break ... ERXAjaxSession is already cleaning up
            // headers at the end, so this seems very odd to me.  If you remove headers here,
            // it causes ERXAjaxSession to not treat the response like an Ajax response.
            // ERXAjaxApplication.cleanUpHeaders(response);
            results = response;
        }
    }
    return results;
}

Example 8 with WOResponse

use of com.webobjects.appserver.WOResponse in project wonder-slim by undur.

the class ERXAdminDirectAction method stopAction.

/**
 * Terminates the application when in development.
 *
 * @return "OK" if application has been shut down
 */
public WOActionResults stopAction() {
    WOResponse response = new WOResponse();
    response.setHeader("text/plain", "Content-Type");
    if (ERXApplication.isDevelopmentModeSafe()) {
        WOApplication.application().terminate();
        response.setContent("OK");
    } else {
        response.setStatus(401);
    }
    return response;
}

Example 9 with WOResponse

use of com.webobjects.appserver.WOResponse in project wonder-slim by undur.

the class ERXApplication method handleException.

/**
 * Overridden to log extra information about state when exception is handled.
 */
@Override
public WOResponse handleException(Exception exception, WOContext context) {
    // We first want to test if we ran out of memory. If so we need to quit ASAP.
    handlePotentiallyFatalException(exception);
    // Not a fatal exception, business as usual.
    final NSDictionary extraInfo = ERXUtilities.extraInformationForExceptionInContext(exception, context);
    log.error("Exception caught: " + exception.getMessage() + "\nExtra info: " + NSPropertyListSerialization.stringFromPropertyList(extraInfo) + "\n", exception);
    WOResponse response = super.handleException(exception, context);
    response.setStatus(500);
    return response;
}

Example 10 with WOResponse

use of com.webobjects.appserver.WOResponse in project wonder-slim by undur.

the class ERXApplication method handleActionRequestError.

/**
 * Workaround for WO 5.2 DirectAction lock-ups. As the super-implementation is empty,
 * it is fairly safe to override here to call the normal exception handling earlier than usual.
 */
// NOTE: if you use WO 5.1, comment out this method, otherwise it won't compile.
// CHECKME this was created for WO 5.2, do we still need this for 5.4.3?
@Override
public WOResponse handleActionRequestError(WORequest aRequest, Exception exception, String reason, WORequestHandler aHandler, String actionClassName, String actionName, Class actionClass, WOAction actionInstance) {
    WOContext context = actionInstance != null ? actionInstance.context() : null;
    boolean didCreateContext = false;
    if (context == null) {
        // AK: we provide the "handleException" with not much enough info to output a reasonable error message
        context = createContextForRequest(aRequest);
        didCreateContext = true;
    }
    final WOResponse response = handleException(exception, context);
    // a prime suspect. I am leaving the code below in so that if it does something for prior versions, that will still work.
    if (didCreateContext) {
        context._putAwakeComponentsToSleep();
        saveSessionForContext(context);
    } else // does not check sessions back in which leads to a deadlock in the session store when the session is accessed again.
    if (context.hasSession() && ("InstantiationError".equals(reason) || "InvocationError".equals(reason))) {
        context._putAwakeComponentsToSleep();
        saveSessionForContext(context);
    }
    return response;
}