I have a fairly large production installation running on Stripes serving
~billion API calls/month, so it’s very much in active use. Works great! :-)
May you have energy and success!
/Janne
> On 12 Oct 2018, at 15:56, DJDaveMark via Stripes-users
> wrote:
>
> Hi,
>
> Just wondered how
Looking at our own codebase (which isn’t unfortunately public), it seems to be
a fairly straightforward POST handler. All you need to do is to parse the
IPNMessage out of the request, and you should be fine, and luckily Paypal
provides a library to do just that.
Basically we have something
.
Give it a look if you are interested. I have been using it in production
for quite awhile and it works well.
Thanks.
-- Rick
On Sat, Feb 28, 2015 at 7:17 AM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote:
We’ve just been lazy and done
public Resolution foo()
{
switch
We’ve just been lazy and done
public Resolution foo()
{
switch( getContext().getRequest().getMethod() )
{
case “post”:
return doPost();
case “get”
return doGet()
case “delete”:
return doDelete();
I suppose you mean validation errors in particular? We use something like this
in our AbstractApiActionBean from which all our Api beans inherit from:
/**
* Normally Stripes turns validation errors into HTML, but since this is
an API,
* we turn it into JSON. Returns a JSON or
In fixing http://www.stripesframework.org/jira/browse/STS-919 I got a
suggestion from Remi to make a pull request on github. However, I cannot find a
reference to the official Stripes github project on stripesframework.org. In
fact, I can only find links to Sourceforge, and even from the
Yup.
In your ActionBean, try something like this:
@Override
public Resolution handleValidationErrors( ValidationErrors errors ) throws
Exception
{
return new ForwardResolution(“/MainForm?id=3);
}
/Janne
On 2 Jun 2014, at 04:23, Joaquin Valdez joaquinfval...@gmail.com
You’re right, this probably is not a Stripes issue, but the client does not
like what you’re sending. It’s hard to say what’s going on without seeing the
client code… My guess is that the parser at the client end is not very
permissive, and it’ll choke if you just have a wrong byte sequence.
Something like this is probably the easiest way:
https://github.com/blueimp/jQuery-File-Upload
/Janne
On 19 May 2014, at 09:43, Heather and Jon Turgeon
tashiba40_evergr...@hotmail.com wrote:
Hi all, well I finally got my app deployed, now just waiting for the users to
pour in ;-)
I just simply inherited StripesFormTag to provide my own SecureStripesFormTag
which is smart enough to force SSL in form submission if it's not enabled
before. The code looks like this
public class SecureFormTag extends FormTag
{
@Override
protected String buildAction()
{
Can you post your web.xml config, please? My suspicion is that there may be a
problem with the configuration.
/Janne
On Dec 29, 2012, at 21:40 , Noobmeter Admin ad...@noobmeter.com wrote:
Yes, I'm using it. But it doesn't seem to help.
Any other ideas?
Regards,
John
From: Janne
I use something like this from an AbstractApiActionBean
/**
* Normally Stripes turns validation errors into HTML, but since this is
an API,
* we turn it into JSON. Returns a JSON or JSONP resolution with a single
* field error which then contains a number of errors.
Ditto. We can't upgrade out of 1.5.3 :-/
(Can we please get the old layout code back as an option, please?)
/Janne
On 31 Jan 2012, at 15:38, Mike McNally wrote:
Since 1.5.4, using nested layouts has been somewhat problematic. My
site works in 1.5.3 but fails all over the place in any of
and providing the streaming
version with a different URL.
On Tue, Jan 31, 2012 at 8:47 AM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote:
Ditto. We can't upgrade out of 1.5.3 :-/
(Can we please get the old layout code back as an option, please?)
/Janne
On 31 Jan 2012, at 15:38, Mike
Um... Why would you obfuscate a web app? If an attacker has enough access to
your server to read your JAR files, you've already got way worse problems than
having the user decompile your app...
Anyway, Stripes uses Reflection quite heavily and depends on the method and
field names to be the
Make sure that your setters aren't mangled either, or your parameters won't be
transmitted.
/Janne
On 25 Nov 2011, at 14:14, Sylvain Brejeon wrote:
no need to be sorry mate.
the two of you convinced me that it ought to be that the method names have
changed.
of course it can't be
Date formatting is usually something that's done by the view component in a
typical MVC model. I'm not sure that the Stripes ActionBean is the right place
to solve this problem.
What we usually do is that we take the Date object up and until the view layer,
then format it with JSTL on our JSP
Unfortunately not all Javascript frameworks like this. I've just been returning
a StreamingResolution(application/json, {}); that seems to work across
everything. (JSONP requires then also the callback and a different MIME type.)
/Janne
On 30 Sep 2011, at 05:02, Freddy Daoud wrote:
You
- SAVOYM - QA
Yes, you need to clean up the cached compiled JSPs. There have been changes
in the 1.5.x series to the layout tags. Some of them now implement BodyTag
that did not before and vice versa.
-Ben
On Thu, Jun 9, 2011 at 12:53 AM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote
Clean your servlet container compiled JSP pages. (e.g. empty the work
directory from $TOMCAT_HOME, other containers may differ) and ensure your
stripes.jar is not corrupted (jar tvf stripes-1.5.5.jar).
I've seen this occasionally too, though only on dev systems. It's usually a
As for the GIt conversion, I don't get it. We're not the Linux kernel. There
aren't zillions of patches pending to be applied every day. In fact, there
are pretty much zero patches. If folks want to make changes, and make a
difference, then make or find an issue on Jira, and submit a patch.
Again, I'm not attempting to prove that SpringMVC is better than Stripes,
the question of interest is whether Stripes encourages bad practice from an
OO point-of-view?
I suppose it depends on your definition of OO - I use subclassing in my
ActionBeans so that I can share common parameters and
Basically, in addition to the other things I mentioned there indeed is one
Stripes configuration that I set... by creating a custom LocalePicker
subclass that picks the character encoding UTF-8... and dropping it the
configured Stripes extensions folder... the relevant code is as follows:
... but sure if Stripes didn't have
built-in support... I would consider a filter or interceptor but the case is
moot IMO.
Rather my point was about having missed including this in the list of things
I did to enable UTF-8 support in reply to the OP.
Cheers,
--Nikolaos
Janne Jalkanen wrote
Really??? A filter just to set character encoding??? Although I imagine it
would work isn't that a little sledge hammer-ish ;-)
I seem to recall it was the recommended practice.
Why not just put the following at the top of each of your JSPs (or tweak as
necessary):
%@ page
Simple solution: declare the accept-charset value on all your forms to be
UTF-8 (and *only* UTF-8), then put up a simple Filter in front of your chain
which says request.setCharacterEncoding(UTF-8). This should ensure that you
get full unicodes to the ActionBean, and then you only have to deal
1) Logging in. The login action should be https so username and password are
encrypted, but once i pass the login, the first page the user sees does not
need to be secure, hence switching from https to http
And that's exactly when your site stops being secure, and the user session can
be
I know this isn't particularly helpful, but if you do switch from https to http
AND keep the same session identifier, you *do* have a need for encryption, and
hence shouldn't be switching to http.
The reason for this is that session id hijacking is ridiculously easy these
days, so having http
I'm using something like this to set up Stripes (JUnit 4, then use standard
MockRoundtrip()). You should be able to replace the ActionBeanContext here
with whatever you like.
@BeforeClass
public static void mockUp()
{
MockServletContext context = new
BTW, this reminds me... If your Stripes app needs security, using Apache Shiro
together with Stripes is a breeze.
http://www.ecyrd.com/ButtUgly/wiki/Main_blogentry_100910_1
/Janne
On 11 Jan 2011, at 00:12, Joaquin Valdez wrote:
Hello!
In the Stripes book there is an example of encoding a
Thank you! Seems to solve all the weird-o layout issues I was having with 1.5.4
that I never got around to debugging...
/Janne
On Jan 4, 2011, at 20:17 , Ben Gunter wrote:
Stripes 1.5.5 is available for Download from Sourceforge. Maven users will
find it in the central repository.
For
map the filters you need properly for
*.jsp and you should be fine.)
This change alone bumped my Yottaa score up by 10 notches compared to just
blindly mapping action/mybean as a welcome-file. :-)
/Janne
On 29 Dec 2010, at 00:31, Janne Jalkanen wrote:
Hi folks!
I need to map the root
to
improve performance, it would be a very very long discussion, with a lot to
say about the overuse of reflection.
-Original Message-
From: Janne Jalkanen [mailto:janne.jalka...@ecyrd.com]
Sent: Wednesday, December 29, 2010 6:27 AM
To: Stripes Users List
Subject: Re: [Stripes
=/action/mybean /
BTW, the comment in your JSP says redirect instead of forward.
-Ben
On Wed, Dec 29, 2010 at 6:26 AM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote:
Folks,
to follow up on this, it seems that the simplest way to accomplish an
URLBinding to / is to create
OK guys, you got me excited. Is this documented somewhere and do I have to do
anything to get it turned on? :-D
/Janne
On 23 Dec 2010, at 18:14, Ben Gunter wrote:
Thank you so much for the positive feedback. I worked really hard to get that
done, and it's nice to know people are benefiting
Hi folks!
I need to map the root of my site to a particular ActionBean. Now, the simple
way to do this is of course to use a welcome-file-list in web.xml (Tomcat
6.0.x):
welcome-file-list
welcome-fileaction/mybean/welcome-file
/welcome-file-list
but unfortunately this carries a fairly heavy
36 matches
Mail list logo
