Nabble - Stripes

Re: Stripes 1.5 and JBOSS 5

2009-07-06T13:17:12Z

I am having the same problem and I want to know if there is a known solution other than using exploded war/ear.

Dag-6 wrote:

Hi!

Tried to deploy my Stripes app to a JBoss 5 app server, but for some reason none
of the action beans are found.

This seems to be a known issue:

http://www.nabble.com/ResolverUtil-not-able-to-read-package-structure-in-war-located-in-an-ear-on-JBoss5--td19725852.html

Anybody have a workaround (other than exploding the ear file)?

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Re: Parameters in Actionbean won't save

2009-07-06T08:23:49Z

You’re redirecting to the jsp which creates a whole new http request with null parameters.

Instead, you’ll want to stash your jsps under WEB-INF so they are protected and can’t be accessed directly; have your action beans return new ForwardResolution(“to-the.jsp”) instead. You’ll probably have to convert your first request from a direct jsp to an action bean which has a @DefaultHandler to forward you to the index jsp. This approach may initially sound like a bit of extra work but it really is much nicer once you get comfortable with it.

See the preactions paragraph at http://www.stripesframework.org/display/stripes/Best+Practices

From: b l [mailto:blake1402@...]
Sent: Monday, July 06, 2009 11:07 AM
To: stripes-users@...
Subject: [Stripes-users] Parameters in Actionbean won't save

I'm having trouble with something that seems very simple. Here is my ActionBean

package ....action;

import net.sourceforge.stripes.

action.RedirectResolution;
import net.sourceforge.stripes.action.Resolution;
import net.sourceforge.stripes.action.UrlBinding;
import net.sourceforge.stripes.action.DefaultHandler;
import net.sourceforge.stripes.action.DontValidate;
import net.sourceforge.stripes.action.HandlesEvent;

import ....pojo.ImgCal;
import ....service.DailyDataImageService;

import org.apache.log4j.Logger;

@UrlBinding("/DailyData.action")
public class DailyDataActionBean extends W2BActionBean {
    private static final Logger logger = Logger.getLogger(DailyDataActionBean.class);

    private DailyDataImageService imgService = new DailyDataImageService();

    private ImgCal imgCal;

    private int curMonth;
    private int prevCurMonth;
    private int curYear;

    public int getCurMonth() {
        return curMonth;
    }

    public void setCurMonth(int curMonth) {
        this.curMonth = curMonth;
    }

    public int getCurYear() {
        return curYear;
    }

    public void setCurYear(int curYear) {
        this.curYear = curYear;
    }

    public ImgCal getImgCal() {
        logger.debug("GET IMG CAL: ");
        if(this.imgCal == null) {
            logger.debug("NULL!");
            this.imgCal = imgService.getImageCalendar(getCurMonth(), getCurYear());
        }
        return imgCal;
    }

    public void setImgCal(ImgCal imgCal) {
        this.imgCal = imgCal;
    }

    public int getPrevCurMonth() {
        return prevCurMonth;
    }

    public void setPrevCurMonth(int prevCurMonth) {
        this.prevCurMonth = prevCurMonth;
    }

    @DontValidate
    @DefaultHandler
    public Resolution view() {
        logger.debug("VIEW BEING CALLED");
        this.curMonth = imgService.getCurMonth();
        this.curYear = imgService.getCurYear();
        this.prevCurMonth = imgService.getCurMonth();

        this.imgCal = imgService.getImageCalendar(getCurMonth(), getCurYear());

        logger.debug("IMG CAL: " + getImgCal().getMonthHeader());
        return new RedirectResolution("/DailyData.jsp");
    }

    @HandlesEvent("update")
    @DontValidate
    public Resolution update() {
        logger.debug("In Update: month " + getCurMonth() + " year " + getCurYear());
        imgCal = imgService.getImageCalendar(getCurMonth(), getCurYear());
        prevCurMonth = curMonth;
        return new RedirectResolution("/DailyData.jsp");
    }
}

When the action is called, view() is called correctly. The imgCal is then built correctly (I print it out to verify) and then the resolution to the jsp works right. However, once getImgCal() is called from the jsp, imgCal is then null (all my bean parameters are then null). I don't understand why everything is null after I've initialized them in view(). If I reinitialize everything inside their getters then everything works correctly, but this is extremely inefficient as it takes a long time to build imgCal. I've also tried using the StripesStuff plugin and the @Session notation, with the same result. Is there something I'm missing? This seems like this should be very basic functionality. I have other actions that work, so to my knowledge, I don't think the problem is with my web.xml or setup in general. Any ideas?

------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Parameters in Actionbean won't save

2009-07-06T08:07:11Z

I'm having trouble with something that seems very simple. Here is my ActionBean

package ....action;

import net.sourceforge.stripes.

From forum: stripes-users

Re: Multiple clicks on submit button

2009-07-03T12:27:25Z

hi,

i have the same problem and i would prefer a server side solution like using
a session token. but as i understood the whole thing, there is no way to do
something like canceling the request cycle for the second, third... request. any suggestions?

erik

Ben Gunter wrote:

> >
> > It's not Stripes-specific, but perhaps onclick="this.disabled=true" on
> > the button would work. I've also done more elaborate things in the past,
> > like overlay a translucent div on top of everything else so they can't
> > click on anything after the form is submitted. I call it a "veil," so my
> > forms always look something like
> >
> > <s:form ... onsubmit="showVeil();return true;">.
> >
> > I've never done anything server-side to avoid this problem so I don't
> > have any suggestions on that.
> >
> > -Ben
> >
> > Mark Smith wrote:
>
>> >> Hello all.
>> >>
>> >> I'm new to stripes and am using it on a project at work.
>> >>
>> >> We have an issue when a user clicks multiple times on a submit button
>> >> before the previous request is complete.
>> >>
>> >> Does anyone know of a stripes method or work around to prevent this?
>> >>
>> >> Thanks in advance.
>> >>
>> >> Mark
>>
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Stripes-users mailing list
> > Stripes-users@...
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
> >
> >
>

-- View this message in context:
http://www.nabble.com/Multiple-clicks-on-submit-button-tp17290841p24327548.html
Sent from the stripes-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Re: Multiple clicks on submit button

2009-07-03T12:16:40Z

hi,

i have the same problem and i would prefer a server side solution like using a session token. but as i understood the whole thing, there is no way to do something like canceling the request cycle for the second, third... request isn't it? any suggestions?

erik

Ben Gunter wrote:

It's not Stripes-specific, but perhaps onclick="this.disabled=true" on
the button would work. I've also done more elaborate things in the past,
like overlay a translucent div on top of everything else so they can't
click on anything after the form is submitted. I call it a "veil," so my
forms always look something like

<s:form ... onsubmit="showVeil();return true;">.

I've never done anything server-side to avoid this problem so I don't
have any suggestions on that.

-Ben

Mark Smith wrote:
> Hello all.
>
> I'm new to stripes and am using it on a project at work.
>
> We have an issue when a user clicks multiple times on a submit button
> before the previous request is complete.
>
> Does anyone know of a stripes method or work around to prevent this?
>
> Thanks in advance.
>
> Mark

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

using Validate check for this case?

2009-07-03T01:23:52Z

hi, this my first post on this forum and i need help to resolve this problem.

i so stuck on this problem..let me explain :

i have a module registration with 2 page

first page its user will fill a the mandatory textbox (the mandatory could be fill empty), and than user click next button to the second page. (when parsing value from page 1 to page 2 i 'am using @wizard startEvent)

second page, in here user fill the textbox too..after that user click button submit to fullfill registration..

when user click submit system will check all of mandatory text field and show error for the field empty..
its will check mandatory field from page 1 and 2 and will be show on page 2..

if error show from page 1 user could back to page 1 and highlight errors..

From forum: stripes-users

Re: Empty Paramter Map in LayoutContext

2009-07-02T05:59:47Z

Just to let you know the <dispatcher>FORWARD</dispatcher> was all I
needed. I can't actually find any documentation on a
<dispatcher>ERROR</dispatcher> mapping

On Wed, Jul 1, 2009 at 1:43 PM, Ben Gunter<gunterben@...> wrote:

> Do you have StripesFilter executing on error, something like this?
>
> <filter-mapping>
> <filter-name>StripesFilter<filter-name>
> <url-pattern>*.jsp</url-pattern>
> <dispatcher>REQUEST</dispatcher>
> <dispatcher>FORWARD</dispatcher>
> <dispatcher>ERROR</dispatcher>
> </filter-mapping>
>
> -Ben
>
> On Wed, Jul 1, 2009 at 7:09 AM, phil darley <phillip.darley@...>
> wrote:
>>
>> Hi Stripes folk,
>>
>> I'm getting a 500 internal server error (ironically) when attempting
>> to customise my error pages - specifically the 404 page.
>>
>> My error pages use the default template layout-definition for my web
>> app, if I request my 404 jsp directly it works fine but when the
>> servlet container forwards a bad request (a request for a non-existant
>> resource) to my 404 page a StripesJspException is thrown because the
>> LayoutContext contains an empty Map of parameters for the layout
>> componets.
>>
>> When does the Parameter Map get set on the LayoutContext? I can only
>> assume it has something to do with the way the servlet container
>> (weblogic 81) is forwarding on the request.
>>
>> Cheers,
>> Phil
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

[JIRA] Updated: (STS-696) StripesRuntimeException thrown in AnnotatedClassActionResolver when overriding handler but returning a subclass of the original method

2009-07-02T02:30:18Z

[ http://www.stripesframework.org/jira/browse/STS-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul White updated STS-696:
---------------------------

Attachment: AnnotatedClassActionResolverTest.java

This test case demonstrates the issue. It passes when the above change to AnnotatedClassActionResolver.java is made.

> StripesRuntimeException thrown in AnnotatedClassActionResolver when overriding handler but returning a subclass of the original method
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: STS-696
> URL: http://www.stripesframework.org/jira/browse/STS-696
> Project: Stripes
> Issue Type: Bug
> Components: ActionBean Dispatching
> Affects Versions: Release 1.5, Release 1.5.1
> Environment: Java 1.5.0_19
> Reporter: Paul White
> Attachments: AnnotatedClassActionResolverTest.java
>
>
> A net.sourceforge.stripes.exception.StripesRuntimeException is thrown in error at:
> net.sourceforge.stripes.controller.AnnotatedClassActionResolver.processMethods(AnnotatedClassActionResolver.java:226)
> The exception message is "The ActionBean class <classname? declares multiple event handlers for event '<eventname>'"
> This occurs when processing methods for an actionBean that overrides a super class handler with a method returning a subclass of the original method (eg RedirectResolution overriding Resolution). The reason for the error is that AnnotatedClassActionResolver.processMethods is not expecting class.getDeclaredMethods() to include bridge methods. I will attach a test case that displays the problem.
> Workaround is to refactor subclasses to return Resolution rather than ForwardResolution, RedirectResolution etc but it's valid in Java to override methods this way so it should be supported ideally.
> The solution is to change AnnotatedClassActionResolver.java, line 220 as follows:
> if ( Modifier.isPublic(method.getModifiers()) && !method.isBridge() ) {

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

------------------------------------------------------------------------------
_______________________________________________
Stripes-development mailing list
Stripes-development@...
https://lists.sourceforge.net/lists/listinfo/stripes-development

From forum: stripes-dev

[JIRA] Created: (STS-696) StripesRuntimeException thrown in AnnotatedClassActionResolver when overriding handler but returning a subclass of the original method

2009-07-02T02:28:18Z

StripesRuntimeException thrown in AnnotatedClassActionResolver when overriding handler but returning a subclass of the original method
--------------------------------------------------------------------------------------------------------------------------------------

Key: STS-696
URL: http://www.stripesframework.org/jira/browse/STS-696
Project: Stripes
Issue Type: Bug
Components: ActionBean Dispatching
Affects Versions: Release 1.5.1, Release 1.5
Environment: Java 1.5.0_19
Reporter: Paul White

A net.sourceforge.stripes.exception.StripesRuntimeException is thrown in error at:

net.sourceforge.stripes.controller.AnnotatedClassActionResolver.processMethods(AnnotatedClassActionResolver.java:226)

The exception message is "The ActionBean class <classname? declares multiple event handlers for event '<eventname>'"

This occurs when processing methods for an actionBean that overrides a super class handler with a method returning a subclass of the original method (eg RedirectResolution overriding Resolution). The reason for the error is that AnnotatedClassActionResolver.processMethods is not expecting class.getDeclaredMethods() to include bridge methods. I will attach a test case that displays the problem.

Workaround is to refactor subclasses to return Resolution rather than ForwardResolution, RedirectResolution etc but it's valid in Java to override methods this way so it should be supported ideally.

The solution is to change AnnotatedClassActionResolver.java, line 220 as follows:

if ( Modifier.isPublic(method.getModifiers()) && !method.isBridge() ) {

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

------------------------------------------------------------------------------
_______________________________________________
Stripes-development mailing list
Stripes-development@...
https://lists.sourceforge.net/lists/listinfo/stripes-development

From forum: stripes-dev

[JIRA] Updated: (STS-690) "ActionBean execution threw an exception" - root cause is not logged

2009-07-01T13:41:18Z

[ http://www.stripesframework.org/jira/browse/STS-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Newman updated STS-690:
----------------------------

Attachment: BadActionBean.java
TestExceptionLogging.java

I ran into this again today. Minimal test case to reproduce this is attached

> "ActionBean execution threw an exception" - root cause is not logged
> --------------------------------------------------------------------
>
> Key: STS-690
> URL: http://www.stripesframework.org/jira/browse/STS-690
> Project: Stripes
> Issue Type: Bug
> Components: ActionBean Dispatching
> Affects Versions: Release 1.5
> Reporter: John Newman
> Attachments: BadActionBean.java, TestExceptionLogging.java
>
>
> hello,
> Perhaps I have something configured wrong. But occasionally I get this error here, with no help as to what I actually have wrong:
> 10:50:25,230 WARN DefaultExceptionHandler:90 - Unhandled exception caught by the Stripes default exception handler.
> net.sourceforge.stripes.exception.StripesServletException: ActionBean execution threw an exception.
> at net.sourceforge.stripes.controller.DispatcherServlet.doPost(DispatcherServlet.java:190)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at net.sourceforge.stripes.mock.MockFilterChain.doFilter(MockFilterChain.java:66)
> at net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:246)
> at net.sourceforge.stripes.mock.MockFilterChain.doFilter(MockFilterChain.java:63)
> at net.sourceforge.stripes.mock.MockServletContext.acceptRequest(MockServletContext.java:255)
> at net.sourceforge.stripes.mock.MockRoundtrip.execute(MockRoundtrip.java:195)
> at net.sourceforge.stripes.mock.MockRoundtrip.execute(MockRoundtrip.java:207)
> at test.com.upmc.cancercenters.pathways.core.TestPathwayViewer.testViewDiseasePDF(TestPathwayViewer.java:42)
> at test.com.upmc.cancercenters.pathways.core.TestPathwayViewer.testBody(TestPathwayViewer.java:27)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> This doesn't help, the cause of that exception needs to be logged.
> looking at the trunk, I see:
> throw throwable;
> }
> }
> catch (ServletException se) { throw se; }
> catch (IOException ioe) { throw ioe; }
> catch (Throwable t) {
> throw new StripesServletException("Unhandled exception in exception handler.", t);
> }
> so it's throwing it inside a try block and catching it.. something isn't right here.

From forum: stripes-dev

[JIRA] Commented: (STS-655) Example .war does not work on JBoss 5

2009-07-01T11:48:18Z

[ http://www.stripesframework.org/jira/browse/STS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11726#action_11726 ]

Allen Petersen commented on STS-655:
------------------------------------

Are your classes in WEB-INF/classes, or in a jar file in WEB-INF/lib?

> Example .war does not work on JBoss 5
> -------------------------------------
>
> Key: STS-655
> URL: http://www.stripesframework.org/jira/browse/STS-655
> Project: Stripes
> Issue Type: Bug
> Affects Versions: Release 1.5
> Environment: MS Window XP, JDK 1.6, Jboss 5.0.0GA
> Reporter: Richard Tsang
> Priority: Critical
> Fix For: Release 1.6
>
> Attachments: server.zip, server.zip, STS-655-jboss5x.patch
>
>
> -Dropping the stripes-example.war (from stripes-1.5.zip) into JBoss 5.0.0GA (EG: jboss-5.0.0.GA\server\default\deploy)
> -Start up server and open stripes-examples (http://localhost:8080/stripes-examples)
> -Click the quick start link to the simple calculator
> -Enter two numbers and press the Add button
> Got the following stacktrace:
> net.sourceforge.stripes.exception.ActionBeanNotFoundException: Could not locate an ActionBean that is bound to the URL [/examples/quickstart/Calculator.action]. Commons reasons for this include mis-matched URLs and forgetting to implement ActionBean in your class. Registered ActionBeans are: {/controller/DefaultView.action=class net.sourceforge.stripes.controller.DefaultViewActionBean}
> net.sourceforge.stripes.controller.AnnotatedClassActionResolver.getActionBean(AnnotatedClassActionResolver.java:325)
> net.sourceforge.stripes.controller.NameBasedActionResolver.getActionBean(NameBasedActionResolver.java:264)
> net.sourceforge.stripes.controller.AnnotatedClassActionResolver.getActionBean(AnnotatedClassActionResolver.java:279)
> net.sourceforge.stripes.controller.DispatcherHelper$1.intercept(DispatcherHelper.java:106)
> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:158)
> net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113)
> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155)
> net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.java:74)
> net.sourceforge.stripes.controller.DispatcherHelper.resolveActionBean(DispatcherHelper.java:102)
> net.sourceforge.stripes.controller.DispatcherServlet.resolveActionBean(DispatcherServlet.java:245)
> net.sourceforge.stripes.controller.DispatcherServlet.doPost(DispatcherServlet.java:148)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:246)
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

From forum: stripes-dev

Re: Empty Paramter Map in LayoutContext

2009-07-01T08:50:50Z

Many thanks Ben this is now working, I previously only had the
StripesFilter dispatched on REQUEST.

Cheers,
Phil

On Wed, Jul 1, 2009 at 1:43 PM, Ben Gunter<gunterben@...> wrote:

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Re: Empty Paramter Map in LayoutContext

2009-07-01T05:43:57Z

Do you have StripesFilter executing on error, something like this?

<filter-mapping>
<filter-name>StripesFilter<filter-name>
<url-pattern>*.jsp</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>ERROR</dispatcher>
</filter-mapping>

-Ben

On Wed, Jul 1, 2009 at 7:09 AM, phil darley <phillip.darley@...> wrote:

Hi Stripes folk,

I'm getting a 500 internal server error (ironically) when attempting
to customise my error pages - specifically the 404 page.

My error pages use the default template layout-definition for my web
app, if I request my 404 jsp directly it works fine but when the
servlet container forwards a bad request (a request for a non-existant
resource) to my 404 page a StripesJspException is thrown because the
LayoutContext contains an empty Map of parameters for the layout
componets.

When does the Parameter Map get set on the LayoutContext? I can only
assume it has something to do with the way the servlet container
(weblogic 81) is forwarding on the request.

Cheers,
Phil

From forum: stripes-users

[JIRA] Commented: (STS-655) Example .war does not work on JBoss 5

2009-07-01T05:37:18Z

[ http://www.stripesframework.org/jira/browse/STS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11725#action_11725 ]

Marcus Kraßmann commented on STS-655:
-------------------------------------

The patch does not work for me. I fetched Stripes 1.5.1 from corresponding svn-tag and used the patch file attached to this ticket. The resulting stripes.jar did neither work on JBoss 5.0.1.GA nor on 5.1.0.GA (server plattform: Windows XP, JDK 1.6.13).

I get no error messages on server startup, but also there are no action beans bound to Stripes.

If I deploy the exploded war, everything works fine.

From forum: stripes-dev

Empty Paramter Map in LayoutContext

2009-07-01T04:09:46Z

Hi Stripes folk,

I'm getting a 500 internal server error (ironically) when attempting
to customise my error pages - specifically the 404 page.

My error pages use the default template layout-definition for my web
app, if I request my 404 jsp directly it works fine but when the
servlet container forwards a bad request (a request for a non-existant
resource) to my 404 page a StripesJspException is thrown because the
LayoutContext contains an empty Map of parameters for the layout
componets.

When does the Parameter Map get set on the LayoutContext? I can only
assume it has something to do with the way the servlet container
(weblogic 81) is forwarding on the request.

Cheers,
Phil

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

[JIRA] Created: (STS-695) Non-transient request field in FlashScope sometimes prevents serialization for session persistence

2009-06-30T17:53:18Z

Non-transient request field in FlashScope sometimes prevents serialization for session persistence
--------------------------------------------------------------------------------------------------

Key: STS-695
URL: http://www.stripesframework.org/jira/browse/STS-695
Project: Stripes
Issue Type: Bug
Components: Context Management
Affects Versions: Release 1.5.1
Environment: Resin 3.1.9, Java 1.6.0_13, Ubuntu 8.10
Reporter: Mark Adams

As we know, Stripes' FlashScope objects are stored in a Map in the HttpSession. The session attribute that stores them is Serializable, and the FlashScope itself implements Serializable, but it has a private field that holds an HttpServletRequest, which in practice is an instance of StripesRequestWrapper, which is not Serializable, so when you're using persistent sessions and your session manager uses serialization, it's possible that you'll end up getting a NotSerializableException when attempting to serialize the FlashScope.

The exact behavior probably varies from servlet engine to servlet engine, but here's what I've seen with Resin: if the request makes it to the end of StripesFilter.doFilter() before trying to save the session, it'll be ok because FlashScope.completeRequest() will have been called, which among other things nulls out the request field on the FlashScope. However, if an action ends with a RedirectResolution, then before the end of doFilter() it will end up in RedirectResolution.execute(), which calls HttpResponse.sendRedirect(), which (on Resin, at least) saves the session before sending the response to the client. At that point, of course, the request field on the FlashScope is still non-null, so the serialization fails.

>From the testing I've done so far, it appears that marking the FlashScope.request field as transient will take care of the problem.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

------------------------------------------------------------------------------
_______________________________________________
Stripes-development mailing list
Stripes-development@...
https://lists.sourceforge.net/lists/listinfo/stripes-development

From forum: stripes-dev

Re: StripesFilter exclude path

2009-06-30T14:56:03Z

Not really : DMF looks for 404s, and tries to resolve to an action if
nothing else could be found. It can introduce side effects that you
simply avoid by "excluding" some paths, if that's what's needed.

In short, if you have a prefix/suffix for your actions (here, .htm),
then you don't need DMF. DMF is useful only for paths that don't have
a prefix (/action/*) or suffix (*.action).

Cheers

Remi

2009/6/30 Levi Hoogenberg <levihoogenberg@...>:

> Isn't this more or less what DynamicMappingFilter does?
>
> Op 30 jun 2009 om 20:35 heeft VANKEISBELCK Remi <remi@...> het volgende
> geschreven:\
>
>> Hi Tony,
>>
>> A very simple way to do this is by subclassing StripesFilter, override
>> the doFilter(...) method, and perform a test on the requested URL to
>> decide wether to call the stripes filter (via super.doFilter()), or
>> just let the request go through and do nothing.
>>
>> Stuff like this :
>>
>> class StripesWithExclusionFilter extends StripesFilter {
>>
>> ...
>>
>> @Override
>> public void doFilter(request,response,filterChain) {
>> if (filterExclusionHelper.isExcluded(request)) {
>> // excluded request
>> filterChain.doFilter(request, response);
>> } else {
>> // request should be handled by Stripes
>> super.doFilter(...);
>> }
>> }
>>
>> ...
>>
>> }
>>
>> Of course, you'll need to declare your filter class instead of
>> Stripes' into web.xml.
>>
>> Cheers
>>
>> Remi
>>
>>
>> 2009/6/30 Tony Nelson <tnelson@...>:
>>>
>>> Hello everyone.
>>>
>>> Thank you for any help in advance.
>>>
>>> I have mapped StripesFilter to all .htm files.
>>>
>>> <filter-mapping>
>>> <filter-name>StripesFilter</filter-name>
>>> <servlet-name>DispatcherServlet</servlet-name>
>>> <dispatcher>REQUEST</dispatcher>
>>> <dispatcher>FORWARD</dispatcher>
>>> </filter-mapping>
>>>
>>> <servlet>
>>> <servlet-name>DispatcherServlet</servlet-name>
>>>
>>>
>>> <servlet-class>net.sourceforge.stripes.controller.DispatcherServlet</servlet-class>
>>> <load-on-startup>1</load-on-startup>
>>> </servlet>
>>>
>>> <servlet-mapping>
>>> <servlet-name>DispatcherServlet</servlet-name>
>>> <url-pattern>*.htm</url-pattern>
>>> </servlet-mapping>
>>>
>>> This was working just great.. until someone clicked a button on a
>>> javascript widget (tiny_mce) that caused a popup to open
>>> (/path/to/tiny_mce/something.htm). Of course Stripes intercepted the
>>> called and complained that it couldn't find an ActionBean for the page.
>>>
>>> I think I have 2 options.
>>>
>>> 1) Change my files from .htm to something else. .html and .jsp are
>>> already taken. My boss wasn't happy with the default .action which is
>>> why I changed it in the first place. Any suggestions?
>>>
>>> 2) Somehow exclude the parent path to the tiny_mce editor. I can
>>> exclude all of /javascript and should be ok since none of the pages that
>>> Stripes should be concerned in will live there. I just can't find a
>>> way to do this. I don't believe the jsp spec allows it, and I can't
>>> find a configuration parameter for Stripes.
>>>
>>> Any help help, ideas or alternate suggestions would be greatly
>>> appreciated.
>>>
>>> Tony Nelson
>>> Starpoint Solutions
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Stripes-users mailing list
>>> Stripes-users@...
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Stripes-users mailing list
>> Stripes-users@...
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Re: StripesFilter exclude path

2009-06-30T14:53:27Z

Yeah sorry, of course dispatcher servlet IS the one to be subclassed...

You don't really need to subclass the filter actually I think.

Cheers

Remi

2009/6/30 Tony Nelson <tnelson@...>:

> Hi Remy, and everyone else.
>
> It looks like the DispatcherServlet is still intercepting the call.. I'm
> sure that my Filter class is being used.. and that it's calling
> filterChain.doFilter() and not super.doFilter() ..
>
> 30 Jun 2009 15:37:24,784 [27391335@qtp0-0] DEBUG
> com.starpoint.instihire.web.stripes.filter.IHStripesFilter:23 -
> /instihire/javascript/tiny_mce/plugins/paste/pasteword.htm
> 30 Jun 2009 15:37:24,785 [27391335@qtp0-0] DEBUG
> com.starpoint.instihire.web.stripes.filter.IHStripesFilter:27 - calling
> filterChain.doFilter()
>
> On second thought that makes a lot of sense as the DispatcherServlet is
> actually what's mapped to *.htm
>
> Do I need to sublclass DispatcherServlet? Or is there a way to configure
> it?
>
> Thank you for your help.
>
> Tony
>
> VANKEISBELCK Remi wrote:
>
> Hi Tony,
>
> A very simple way to do this is by subclassing StripesFilter, override
> the doFilter(...) method, and perform a test on the requested URL to
> decide wether to call the stripes filter (via super.doFilter()), or
> just let the request go through and do nothing.
>
> Stuff like this :
>
> class StripesWithExclusionFilter extends StripesFilter {
>
> ...
>
> @Override
> public void doFilter(request,response,filterChain) {
> if (filterExclusionHelper.isExcluded(request)) {
> // excluded request
> filterChain.doFilter(request, response);
> } else {
> // request should be handled by Stripes
> super.doFilter(...);
> }
> }
>
> ...
>
> }
>
> Of course, you'll need to declare your filter class instead of
> Stripes' into web.xml.
>
> Cheers
>
> Remi
>
>
> 2009/6/30 Tony Nelson <tnelson@...>:
>
>
> Hello everyone.
>
> Thank you for any help in advance.
>
> I have mapped StripesFilter to all .htm files.
>
> <filter-mapping>
> <filter-name>StripesFilter</filter-name>
> <servlet-name>DispatcherServlet</servlet-name>
> <dispatcher>REQUEST</dispatcher>
> <dispatcher>FORWARD</dispatcher>
> </filter-mapping>
>
> <servlet>
> <servlet-name>DispatcherServlet</servlet-name>
>
> <servlet-class>net.sourceforge.stripes.controller.DispatcherServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
>
> <servlet-mapping>
> <servlet-name>DispatcherServlet</servlet-name>
> <url-pattern>*.htm</url-pattern>
> </servlet-mapping>
>
> This was working just great.. until someone clicked a button on a
> javascript widget (tiny_mce) that caused a popup to open
> (/path/to/tiny_mce/something.htm). Of course Stripes intercepted the
> called and complained that it couldn't find an ActionBean for the page.
>
> I think I have 2 options.
>
> 1) Change my files from .htm to something else. .html and .jsp are
> already taken. My boss wasn't happy with the default .action which is
> why I changed it in the first place. Any suggestions?
>
> 2) Somehow exclude the parent path to the tiny_mce editor. I can
> exclude all of /javascript and should be ok since none of the pages that
> Stripes should be concerned in will live there. I just can't find a
> way to do this. I don't believe the jsp spec allows it, and I can't
> find a configuration parameter for Stripes.
>
> Any help help, ideas or alternate suggestions would be greatly appreciated.
>
> Tony Nelson
> Starpoint Solutions
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Re: StripesFilter exclude path

2009-06-30T13:28:12Z

Isn't this more or less what DynamicMappingFilter does?

Op 30 jun 2009 om 20:35 heeft VANKEISBELCK Remi <remi@...> het
volgende geschreven:\

> Hi Tony,
>
> A very simple way to do this is by subclassing StripesFilter, override
> the doFilter(...) method, and perform a test on the requested URL to
> decide wether to call the stripes filter (via super.doFilter()), or
> just let the request go through and do nothing.
>
> Stuff like this :
>
> class StripesWithExclusionFilter extends StripesFilter {
>
> ...
>
> @Override
> public void doFilter(request,response,filterChain) {
> if (filterExclusionHelper.isExcluded(request)) {
> // excluded request
> filterChain.doFilter(request, response);
> } else {
> // request should be handled by Stripes
> super.doFilter(...);
> }
> }
>
> ...
>
> }
>
> Of course, you'll need to declare your filter class instead of
> Stripes' into web.xml.
>
> Cheers
>
> Remi
>
>
> 2009/6/30 Tony Nelson <tnelson@...>:
>> Hello everyone.
>>
>> Thank you for any help in advance.
>>
>> I have mapped StripesFilter to all .htm files.
>>
>> <filter-mapping>
>> <filter-name>StripesFilter</filter-name>
>> <servlet-name>DispatcherServlet</servlet-name>
>> <dispatcher>REQUEST</dispatcher>
>> <dispatcher>FORWARD</dispatcher>
>> </filter-mapping>
>>
>> <servlet>
>> <servlet-name>DispatcherServlet</servlet-name>
>>
>> <servlet-
>> class>net.sourceforge.stripes.controller.DispatcherServlet</servlet-
>> class>
>> <load-on-startup>1</load-on-startup>
>> </servlet>
>>
>> <servlet-mapping>
>> <servlet-name>DispatcherServlet</servlet-name>
>> <url-pattern>*.htm</url-pattern>
>> </servlet-mapping>
>>
>> This was working just great.. until someone clicked a button on a
>> javascript widget (tiny_mce) that caused a popup to open
>> (/path/to/tiny_mce/something.htm). Of course Stripes intercepted the
>> called and complained that it couldn't find an ActionBean for the
>> page.
>>
>> I think I have 2 options.
>>
>> 1) Change my files from .htm to something else. .html and .jsp are
>> already taken. My boss wasn't happy with the default .action which
>> is
>> why I changed it in the first place. Any suggestions?
>>
>> 2) Somehow exclude the parent path to the tiny_mce editor. I can
>> exclude all of /javascript and should be ok since none of the pages
>> that
>> Stripes should be concerned in will live there. I just can't find a
>> way to do this. I don't believe the jsp spec allows it, and I can't
>> find a configuration parameter for Stripes.
>>
>> Any help help, ideas or alternate suggestions would be greatly
>> appreciated.
>>
>> Tony Nelson
>> Starpoint Solutions
>>
>>
>> ---
>> ---
>> ---
>> ---------------------------------------------------------------------
>> _______________________________________________
>> Stripes-users mailing list
>> Stripes-users@...
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>
> ---
> ---
> ---
> ---------------------------------------------------------------------
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@...
> https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Re: StripesFilter exclude path

2009-06-30T12:45:19Z

Hi Remy, and everyone else.

It looks like the DispatcherServlet is still intercepting the call.. I'm sure that my Filter class is being used.. and that it's calling filterChain.doFilter() and not super.doFilter() ..

30 Jun 2009 15:37:24,784 [27391335@qtp0-0] DEBUG com.starpoint.instihire.web.stripes.filter.IHStripesFilter:23 - /instihire/javascript/tiny_mce/plugins/paste/pasteword.htm
30 Jun 2009 15:37:24,785 [27391335@qtp0-0] DEBUG com.starpoint.instihire.web.stripes.filter.IHStripesFilter:27 - calling filterChain.doFilter()

On second thought that makes a lot of sense as the DispatcherServlet is actually what's mapped to *.htm

Do I need to sublclass DispatcherServlet? Or is there a way to configure it?

Thank you for your help.

Tony

VANKEISBELCK Remi wrote:

Hi Tony,

A very simple way to do this is by subclassing StripesFilter, override
the doFilter(...) method, and perform a test on the requested URL to
decide wether to call the stripes filter (via super.doFilter()), or
just let the request go through and do nothing.

Stuff like this :

class StripesWithExclusionFilter extends StripesFilter {

...

@Override
public void doFilter(request,response,filterChain) {
  if (filterExclusionHelper.isExcluded(request)) {
    // excluded request
    filterChain.doFilter(request, response);
  } else {
    // request should be handled by Stripes
    super.doFilter(...);
  }
}

...

}

Of course, you'll need to declare your filter class instead of
Stripes' into web.xml.

Cheers

Remi


2009/6/30 Tony Nelson tnelson@...:

Hello everyone.

Thank you for any help in advance.

I have mapped StripesFilter to all .htm files.

   <filter-mapping>
       <filter-name>StripesFilter</filter-name>
       <servlet-name>DispatcherServlet</servlet-name>
       <dispatcher>REQUEST</dispatcher>
       <dispatcher>FORWARD</dispatcher>
   </filter-mapping>

   <servlet>
       <servlet-name>DispatcherServlet</servlet-name>

<servlet-class>net.sourceforge.stripes.controller.DispatcherServlet</servlet-class>
       <load-on-startup>1</load-on-startup>
   </servlet>

   <servlet-mapping>
       <servlet-name>DispatcherServlet</servlet-name>
       <url-pattern>*.htm</url-pattern>
   </servlet-mapping>

This was working just great.. until someone clicked a button on a
javascript widget (tiny_mce) that caused a popup to open
(/path/to/tiny_mce/something.htm).  Of course Stripes intercepted the
called and complained that it couldn't find an ActionBean for the page.

I think I have 2 options.

1) Change my files from .htm to something else.  .html and .jsp are
already taken.  My boss wasn't happy with the default .action which is
why I changed it in the first place.  Any suggestions?

2) Somehow exclude the parent path to the tiny_mce editor.  I can
exclude all of /javascript and should be ok since none of the pages that
Stripes should be concerned in will live there.   I just can't find a
way to do this.  I don't believe the jsp spec allows it, and I can't
find a configuration parameter for Stripes.

Any help help, ideas or alternate suggestions would be greatly appreciated.

Tony Nelson
Starpoint Solutions


------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users


------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Fun with wizards

2009-06-30T11:36:55Z

All,

I have an issue with the Stripes Wizard and am hoping someone has come across this before and can help. The wizard is a three-step process and I’ll start from step #2:

· User specifies items to order and clicks Next

· A custom validation returns an error message about one of the items keeping the user on step #2

· The user removes the item with the error and clicks Next again

· From step #3 the user reviews all the data and submits again to complete the process

· (symptom of the problem) A validation fails for an item number being required and will not let the user complete the process

At first blush it appears the first time data is submitted from step #2 the Stripes wizard saves it away because it appears the item removed on the step #2 resubmit is somehow hanging around when the user attempts to complete the process in step #3.

If anyone has any suggestions as to how to get around this I would certainly appreciate it. Otherwise I may need to start digging into the Stripes wizard code and see if I can keep the wizard from hanging onto submitted data when there is a validation error raised during the processing of the request.

Thanks,

The information contained in this message and any attachments is intended only for the use of the individual or entity to which it is addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL, and exempt from disclosure under applicable law. If you are not the intended recipient, you are prohibited from copying, distributing, or using the information. Please contact the sender immediately by return e-mail and delete the original message from your system.
------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Re: StripesFilter exclude path

2009-06-30T11:35:12Z

Hi Tony,

A very simple way to do this is by subclassing StripesFilter, override
the doFilter(...) method, and perform a test on the requested URL to
decide wether to call the stripes filter (via super.doFilter()), or
just let the request go through and do nothing.

Stuff like this :

class StripesWithExclusionFilter extends StripesFilter {

...

@Override
public void doFilter(request,response,filterChain) {
if (filterExclusionHelper.isExcluded(request)) {
// excluded request
filterChain.doFilter(request, response);
} else {
// request should be handled by Stripes
super.doFilter(...);
}
}

...

}

Of course, you'll need to declare your filter class instead of
Stripes' into web.xml.

Cheers

Remi

2009/6/30 Tony Nelson <tnelson@...>:

> Hello everyone.
>
> Thank you for any help in advance.
>
> I have mapped StripesFilter to all .htm files.
>
> <filter-mapping>
> <filter-name>StripesFilter</filter-name>
> <servlet-name>DispatcherServlet</servlet-name>
> <dispatcher>REQUEST</dispatcher>
> <dispatcher>FORWARD</dispatcher>
> </filter-mapping>
>
> <servlet>
> <servlet-name>DispatcherServlet</servlet-name>
>
> <servlet-class>net.sourceforge.stripes.controller.DispatcherServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
>
> <servlet-mapping>
> <servlet-name>DispatcherServlet</servlet-name>
> <url-pattern>*.htm</url-pattern>
> </servlet-mapping>
>
> This was working just great.. until someone clicked a button on a
> javascript widget (tiny_mce) that caused a popup to open
> (/path/to/tiny_mce/something.htm). Of course Stripes intercepted the
> called and complained that it couldn't find an ActionBean for the page.
>
> I think I have 2 options.
>
> 1) Change my files from .htm to something else. .html and .jsp are
> already taken. My boss wasn't happy with the default .action which is
> why I changed it in the first place. Any suggestions?
>
> 2) Somehow exclude the parent path to the tiny_mce editor. I can
> exclude all of /javascript and should be ok since none of the pages that
> Stripes should be concerned in will live there. I just can't find a
> way to do this. I don't believe the jsp spec allows it, and I can't
> find a configuration parameter for Stripes.
>
> Any help help, ideas or alternate suggestions would be greatly appreciated.
>
> Tony Nelson
> Starpoint Solutions
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

StripesFilter exclude path

2009-06-30T10:54:07Z

Hello everyone.

Thank you for any help in advance.

I have mapped StripesFilter to all .htm files.

<filter-mapping>
<filter-name>StripesFilter</filter-name>
<servlet-name>DispatcherServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>

<servlet>
<servlet-name>DispatcherServlet</servlet-name>

<servlet-class>net.sourceforge.stripes.controller.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>DispatcherServlet</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>

This was working just great.. until someone clicked a button on a
javascript widget (tiny_mce) that caused a popup to open
(/path/to/tiny_mce/something.htm). Of course Stripes intercepted the
called and complained that it couldn't find an ActionBean for the page.

I think I have 2 options.

1) Change my files from .htm to something else. .html and .jsp are
already taken. My boss wasn't happy with the default .action which is
why I changed it in the first place. Any suggestions?

2) Somehow exclude the parent path to the tiny_mce editor. I can
exclude all of /javascript and should be ok since none of the pages that
Stripes should be concerned in will live there. I just can't find a
way to do this. I don't believe the jsp spec allows it, and I can't
find a configuration parameter for Stripes.

Any help help, ideas or alternate suggestions would be greatly appreciated.

Tony Nelson
Starpoint Solutions

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Re: Stripes wizard, partial form, and required validation

2009-06-30T04:32:16Z

This sounds familiar and I believe I submitted a patch for it at one point and someone else cleaned it up a little. It is probably in the 2.5.2 code which you are using which should work. Did you say it was working in the release you are using but not in the 'official' version?

On Monday 29 June 2009 04:45:44 pm allen petersen wrote:
> Oh, I think that the validation step is doing the right thing in ignoring
> those fields. It's the __fp field that's only getting the main
> <stripes:form> tag's info, rather than including the nested <stripes:form
> partial="true"> tags' values that I think is not doing the right thing.
>
> So to make it clearer, let's say you have a wizard layout that looks like
> this:
>
> <stripes:form action="${actionBean.wizardAction}">
> <ul class="wizardMenu">
> <c:forEach var="wizardPage" items="${actionBean.wizardPages}"
> varStatus="status">
> <li><stripes:submit name="${wizardPage.targetAction}">
> <fmt:message key="${wizardPage.label}"/></stripes:submit></li>
> </c:forEach>
> </ul>
> <stripes:text name="myObject.requiredField"/>
> </stripes:form>
>
> then that works fine, because the form tag goes through, registers the
> "myObject.requiredField" tag in the fieldsPresent ("__fp"), and so on
> submit the validator knows that that field is present on the page and
> should be checked if it's required.
>
> Meanwhile, if instead of including the <stripes:text> field directly, you
> instead go
>
> <jsp:include page="/WEB-INF/jsp/fields/myFields.jsp"/>
>
> which includes
>
> <stripes:form action="${actionBean.wizardAction}" partial="true">
> <stripes:text name="myObject.requiredField"/>
> </stripes:form>
>
> ...then suddenly the nested form tag doesn't write out any __fp fields.
> And the parent form tag doesn't write it out, either. So the fact that the
> "myObject.requiredField" tag is in the form is lost. And so the validator,
> since this is a wizard, just thinks that the field must be referenced in
> some other page of the wizard, and so doesn't mark it as being required.
>
> I just put in a bit of code in FormTag.java that saves the fieldsPresent
> values in a partial form tag and then prints it on the parent. It seems to
> work ok for me, though there might be some other problems there that I
> haven't thought of yet.
>
> -allen
>
>
> On Mon, Jun 29, 2009, 15:59, Mike McNally <emmecinque@...> wrote
>
> >How would the validator know that the incoming parameters are from the
> >same page? All it sees is the set of parameters in the HTTP request,
> >and it uses the validation metadata for the action bean & event as
> >appropriate.
> >
> >(In other words - validation works whether you post from a Stripes page or
>
> not.)
>
> >Maybe I'm missing what you mean by "noted as being required".
> >
> >On Mon, Jun 29, 2009 at 2:50 PM, allen petersen<allen@...> wrote:
> >> Hi.
> >>
> >> So, quick version: �stripes wizard form with a nested page that has a
> >> <stripes:form partial="true"> tag in it. �Required fields are included
>
> in
>
> >> the nested partial form tag. �But...those required fields aren't being
> >> noted as being required, because the __fp (fieldsOnPage) field is only
> >> being written for the top-level form tag. �So the validator thinks that
>
> the
>
> >> fields are from another page, and therefore don't need to be validated
>
> as
>
> >> required.
> >>
> >> I think I can work around this (or file a bug and submit a patch or
> >> whatever), but I just wanted to run this by the list and see if there
>
> was a
>
> >> known easy fix/workaround. �Or if I'm just doing something wrong.
>
> �(Well,
>
> >> other than using a nested partial form in the first place; I'm actually
> >> having to use the 1.5.2 beta branch already in order to get around
>
> another
>
> >> bug there....)
> >>
> >> -allen
>
> ---------------------------------------------------------------------------
> ---
>
> >> _______________________________________________
> >> Stripes-users mailing list
> >> Stripes-users@...
> >> https://lists.sourceforge.net/lists/listinfo/stripes-users
> >
> >--
> >Turtle, turtle, on the ground,
> >Pink and shiny, turn around.
> >
> >--------------------------------------------------------------------------
>
> ----
>
> >_______________________________________________
> >Stripes-users mailing list
> >Stripes-users@...
> >https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

[JIRA] Commented: (STS-655) Example .war does not work on JBoss 5

2009-06-29T15:04:18Z

[ http://www.stripesframework.org/jira/browse/STS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11724#action_11724 ]

Richard Tsang commented on STS-655:
-----------------------------------

Tested patch together with Trunk on JBoss 5.0.1GA. All good. Stripes Examples work as expected.

Thanks guys

From forum: stripes-dev

Re: Stripes wizard, partial form, and required validation

2009-06-29T13:45:44Z

Oh, I think that the validation step is doing the right thing in ignoring
those fields. It's the __fp field that's only getting the main
<stripes:form> tag's info, rather than including the nested <stripes:form
partial="true"> tags' values that I think is not doing the right thing.

So to make it clearer, let's say you have a wizard layout that looks like
this:

<stripes:form action="${actionBean.wizardAction}">
<ul class="wizardMenu">
<c:forEach var="wizardPage" items="${actionBean.wizardPages}"
varStatus="status">
<li><stripes:submit name="${wizardPage.targetAction}">
<fmt:message key="${wizardPage.label}"/></stripes:submit></li>
</c:forEach>
</ul>
<stripes:text name="myObject.requiredField"/>
</stripes:form>

then that works fine, because the form tag goes through, registers the
"myObject.requiredField" tag in the fieldsPresent ("__fp"), and so on
submit the validator knows that that field is present on the page and
should be checked if it's required.

Meanwhile, if instead of including the <stripes:text> field directly, you
instead go

<jsp:include page="/WEB-INF/jsp/fields/myFields.jsp"/>

which includes

<stripes:form action="${actionBean.wizardAction}" partial="true">
<stripes:text name="myObject.requiredField"/>
</stripes:form>

...then suddenly the nested form tag doesn't write out any __fp fields.
And the parent form tag doesn't write it out, either. So the fact that the
"myObject.requiredField" tag is in the form is lost. And so the validator,
since this is a wizard, just thinks that the field must be referenced in
some other page of the wizard, and so doesn't mark it as being required.

I just put in a bit of code in FormTag.java that saves the fieldsPresent
values in a partial form tag and then prints it on the parent. It seems to
work ok for me, though there might be some other problems there that I
haven't thought of yet.

-allen

On Mon, Jun 29, 2009, 15:59, Mike McNally <emmecinque@...> wrote
>How would the validator know that the incoming parameters are from the
>same page? All it sees is the set of parameters in the HTTP request,
>and it uses the validation metadata for the action bean & event as
>appropriate.
>
>(In other words - validation works whether you post from a Stripes page or
not.)
>
>Maybe I'm missing what you mean by "noted as being required".
>
>
>On Mon, Jun 29, 2009 at 2:50 PM, allen petersen<allen@...> wrote:
>> Hi.
>>
>> So, quick version: �stripes wizard form with a nested page that has a
>> <stripes:form partial="true"> tag in it. �Required fields are included
in
>> the nested partial form tag. �But...those required fields aren't being
>> noted as being required, because the __fp (fieldsOnPage) field is only
>> being written for the top-level form tag. �So the validator thinks that
the
>> fields are from another page, and therefore don't need to be validated
as
>> required.
>>
>> I think I can work around this (or file a bug and submit a patch or
>> whatever), but I just wanted to run this by the list and see if there
was a
>> known easy fix/workaround. �Or if I'm just doing something wrong.
�(Well,
>> other than using a nested partial form in the first place; I'm actually
>> having to use the 1.5.2 beta branch already in order to get around
another
>> bug there....)
>>
>> -allen
>>
>>
>>
---------------------------------------------------------------------------
---

>> _______________________________________________
>> Stripes-users mailing list
>> Stripes-users@...
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>
>
>
>--
>Turtle, turtle, on the ground,
>Pink and shiny, turn around.
>
>--------------------------------------------------------------------------

----
>_______________________________________________
>Stripes-users mailing list
>Stripes-users@...
>https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>

From forum: stripes-users

Re: Stripes wizard, partial form, and required validation

2009-06-29T12:59:47Z

How would the validator know that the incoming parameters are from the
same page? All it sees is the set of parameters in the HTTP request,
and it uses the validation metadata for the action bean & event as
appropriate.

(In other words - validation works whether you post from a Stripes page or not.)

Maybe I'm missing what you mean by "noted as being required".

On Mon, Jun 29, 2009 at 2:50 PM, allen petersen<allen@...> wrote:

> Hi.
>
> So, quick version: stripes wizard form with a nested page that has a
> <stripes:form partial="true"> tag in it. Required fields are included in
> the nested partial form tag. But...those required fields aren't being
> noted as being required, because the __fp (fieldsOnPage) field is only
> being written for the top-level form tag. So the validator thinks that the
> fields are from another page, and therefore don't need to be validated as
> required.
>
> I think I can work around this (or file a bug and submit a patch or
> whatever), but I just wanted to run this by the list and see if there was a
> known easy fix/workaround. Or if I'm just doing something wrong. (Well,
> other than using a nested partial form in the first place; I'm actually
> having to use the 1.5.2 beta branch already in order to get around another
> bug there....)
>
> -allen
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

--
Turtle, turtle, on the ground,
Pink and shiny, turn around.

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Stripes wizard, partial form, and required validation

2009-06-29T12:50:26Z

Hi.

So, quick version: stripes wizard form with a nested page that has a
<stripes:form partial="true"> tag in it. Required fields are included in
the nested partial form tag. But...those required fields aren't being
noted as being required, because the __fp (fieldsOnPage) field is only
being written for the top-level form tag. So the validator thinks that the
fields are from another page, and therefore don't need to be validated as
required.

I think I can work around this (or file a bug and submit a patch or
whatever), but I just wanted to run this by the list and see if there was a
known easy fix/workaround. Or if I'm just doing something wrong. (Well,
other than using a nested partial form in the first place; I'm actually
having to use the 1.5.2 beta branch already in order to get around another
bug there....)

-allen

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

[JIRA] Updated: (STS-655) Example .war does not work on JBoss 5

2009-06-29T08:51:18Z

[ http://www.stripesframework.org/jira/browse/STS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Allen Petersen updated STS-655:
-------------------------------

Attachment: STS-655-jboss5x.patch

This (STS-655-jboss5x.patch) is what I'm using right now to run Stripes with JBoss 5.x. The main change is updating the ResolverUtil to handle vfszip files by reading it from the URL stream.

I also had to change the example build code to put the classes into a jar file in WEB-INF/lib instead of directly in WEB-INF/classes. This is because this fix only works with vfszip: jar files; it doesn't handle vfs files directly on the filesystem. I didn't see a way to support that without using the JBoss VFS API directly; even Hibernate(!!)'s similar code loading EJB3 persistence.xml classes (which is fairly nice, by the way, if perhaps a bit over-engineered) doesn't work with the WEB-INF/classes directory on JBoss 5.x. Still, that should be a restriction that people can live with.

From forum: stripes-dev

Confluence Wiki Page added to Wrong section

2009-06-28T14:27:41Z

Hello,

I wrongly added a "French Translation" to the "User Addition" section. AFAICS, I can't delete pages I add to the wiki. Can someone delete it for me?

http://www.stripesframework.org/display/stripes/Stripes+contre+Struts2+to+Delete

Again, sorry... but in my defense it's 23:30 on Sunday night!

Night, night,

DJDaveMark

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

[JIRA] Updated: (STS-694) patch to remove warnings in eclipse 3.5

2009-06-28T13:58:18Z

[ http://www.stripesframework.org/jira/browse/STS-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jon Stevens updated STS-694:
----------------------------

Attachment: patch.txt

my patch

> patch to remove warnings in eclipse 3.5
> ---------------------------------------
>
> Key: STS-694
> URL: http://www.stripesframework.org/jira/browse/STS-694
> Project: Stripes
> Issue Type: Improvement
> Environment: using eclipse 3.5 and svn trunk
> Reporter: Jon Stevens
> Priority: Trivial
> Attachments: patch.txt
>
>
> I tend to like a build without any warnings. I just checked out the source code to stripes to check it out and found a bunch of areas where eclipse was throwing warnings. This patch just adds a bunch of <?> to the end of various places where eclipse 3.5 was complaining. I also use Eclipse Java->Save Actions to improve the look and feel of the source code without having to do any work. This created a slightly larger patch file. Here are my settings:
> Add 'this' qualifier to unqualified field accesses
> Add 'this' qualifier to unqualified method accesses
> Convert for loops to enhanced for loops
> Add paranoiac parentheses
> Remove unused imports
> Add missing '@Override' annotations
> Add missing '@Deprecated' annotations
> Remove unnecessary casts
> Remove unnecessary '$NON-NLS$' tags
> Remove trailing white spaces on all lines

From forum: stripes-dev

Eclipse and LOG4J configuration nightmare. HELP!

2009-06-27T16:30:27Z

I'm following the "quick start" instructions for Stripes and everytime I try to run a page, I get the following error. My commons-logging.properties and log4j.properties are an my root src directory in Eclipse. My WEB-INF/lib contains commons-logging.jar, cos.jar, and stripes.jar. I'm running stripes 1.5.1, Tomcat 6.0.18, and Eclipse Galileo. Why can't it find that class? It's in stripes.jar.

When I delete the 2 log files from my src directory, the page runs fine.

java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
Caused by: org.apache.commons.logging.LogConfigurationException: User-specified log class 'net.sourceforge.stripes.util.Log4JLogger' cannot be found or is not useable.

My commons-logging.properties has the following value.
org.apache.commons.logging.Log=net.sourceforge.stripes.util.Log4JLogger

And my log4j.properties has the following.
### direct log messages to stdout ###
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

### set log levels - for more verbose logging change 'info' to 'debug' ###
log4j.rootLogger=INFO, stdout
log4j.logger.net.sourceforge.stripes=DEBUG

From forum: stripes-users

Re: Spring managed action beans - any change?

2009-06-26T10:48:05Z

Hi Dave,

Interesting. I'd love to see an example added in the "User Additions" part of the site!

Will try to do that soon. It does require that your Stripes ActionBeans be Spring-managed (by any of the means discussed in this thread already). Once that's set up, then the security approach is the same as the annotation examples in the Spring Security reference doc.

Agreed. Unfortunately in my case we have experienced as well as beginner developers on our projects. We also start projects with one team and end up coming back a few months later with another team. This leads us to employ rather strict "layer" (and coding) conventions so that everyone can 1. find their way around easily
2. not have to think when to start a transaction
(it's a service method named save*, update*, find* etc.)

Pretty much as I describe in my Stripes Spring JPA guide :
http://www.stripesframework.org/display/stripes/Stripes+Spring+JPA

I'd love to get some feedback!

That's a helpful guide :)

Although it doesn't include Spring transaction details, I do have one bit of feedback on the transaction approach you mention in your email:

I'm not keen on using method naming patterns for defining transaction boundaries, because it constrains you to naming your methods within those patterns. That might not be an issue on DAO's, but it might be inconvenient on use-case oriented controllers/services.

What I do instead, is have an abstract parent for controllers, services, dao's etc. Then I use Spring transaction annotations like so:

1) Define a default transaction behavior for the descendants, using a class-level annotation:

@Transactional(propagation = Propagation.REQUIRED)

public abstract class BaseService {

}

2) Add other transaction behavior on descendant classes, or individual methods when they need to vary from the inherited default:

public class FooService extends BaseService implements IFooService {

@Transactional(readOnly = true, propagation = Propagation.SUPPORTS)

public List<Foo> listAll() {

// <snip>

}

I suppose the main disadvantage of my approach is the extra effort of annotating the methods whose transactional behavior need to vary from the default.

Chris.

From forum: stripes-users

Multiple Resource Bundles

2009-06-26T04:07:53Z

Hello everyone,

Coming back to the improvement Oscar suggested for my guide to having Multiple Resource Bundles
http://www.stripesframework.org/display/stripes/Multiple+Resource+Bundles

> > I added a guide to the "User Additions" Stripes documentation...
> >
>
> Why use a custom Configuration, when your
> LocalizationBundleFactory can also implement
> ConfigurableComponent? This also allows you
> to initialize the resource bundles.

I found some time to improve upon it and removed the need for a custom Configuration. All the initialization is now done in LocalizationBundleFactory.

Cheers,

DJDaveMark

------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users

Vedr.: Re: Vedr.: Re: List binding?

2009-06-26T03:35:37Z

Hi,

Thanks for the input guys. I ended up solving it with @Before and @After annotations that clears the list before binding and compacts (remove null entries) it after binding. Seems to work fine.

-dennis

Ben Gunter <gunterben@...> skrev den 25-06-2009 14:44:18: > It's generally a bad idea to do the following, even though it's really easy:
> 1. Load a list into your ActionBean and forward to a view with > inputs for properties of the list elements.
> 2. Modify the elements and submit to same ActionBean
> 3. Before binding, load the list the same way as in #1
> 4. Allow Stripes to bind the properties into the list elements
> The reason it's a bad idea is that the list often can change between > the time the view is presented and the time the form is submitted. > Then you'd be binding property values to the same indexes, but there > might be a different object at that index in the list due to the changes. > > You can do something very similar except that you do NOT load the > list again (step 3 above) on form submission. Instead, you include a > hidden input that specifies which object to load into the list at > the given index. E.g. <s:hidden name="things[0]" />. If you're using > Stripersist (or some other good TypeConverter/Formatter combination) > then Stripes will populate the input automatically. When you submit > your form, each element will get stuffed into the list by the type > converter and property binder and you'll know exactly what object > you're modifying with inputs like things[0].name and things[0].description. > > And that's where Mike's comment is relevant. If you don't submit any > inputs for things[1] (but you do have a things[2]) then that > position in the list will be null and you'd need to compact it to > remove the nulls. > > -Ben
> On Thu, Jun 25, 2009 at 3:25 AM, <dth@...> wrote:
> > Hi, > > But as far as I can tell, there is no way to see which entries (if > any) were deleted from the list? > > Since the setter method actually takes a list I would think it was > cleared before putting the new values (from the request) in it? > > -dennis > > Mike McNally <emmecinque@...> skrev den 24-06-2009 15:31:32: > > > > In this exact situation, I ended up "packing" my list in my data-layer > > code. Our (home-grown) JPA layer provides for a "beforeSave" hook in > > the DAO, so in there I make sure the list is contiguous.
> ------------------------------------------------------------------------------ > _______________________________________________ > Stripes-users mailing list > Stripes-users@... > https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

From forum: stripes-users