I sorta agree with Oscar, except that I think I'd implement it as a
Stripes Interceptor that wraps around ActionBeanResolution. That way
the Interceptor would know the ActionBean being targeting and could
use that information to adjust the request parameters.
-t
On Jan 6, 2009, at 3:59
Does changing the TLD fix the problem? If it does, it sounds to me
like a minor bug that we should just fix in the TLD and be done with.
-t
On Dec 9, 2008, at 11:50 AM, phil darley wrote:
Hi,
I'm attempting to get stripes to run on a 1.4 jee application server,
specifically Weblogic 8.1
You probably also want to call:
return new StreamingResolution(audio/mp3, FileInputStream
Object).setFilename(foo.mp3);
That last part will cause Stripes to send the appropriate headers to
the browser that informs it that the stream of data it's about to
receive should be treated as a
So, actually this works reasonably well already in 1.5, will work
better in 1.5.1 and beyond that the only problem is actually with
related technologies.
When I say works, I mean you should be able to just have:
public Date birthday;
and Stripes will work with the public property
I can't see anything immediately wrong with the web.xml you have
there. A few questions:
- Does the exact same war file deploy and work fine on your
development machine?
- What's different about the production machine? Is it the same JVM
version, same Tomcat version
-t
On Oct 2, 2008,
think it would then use this locale if I understood the
TypeConverter(s) correct?
Maybe da_DA (Danish) is not supported?
Tim Fennell-3 wrote:
I wonder could it be anything to do with your Locale settings? It
seems like Currency.getInstance() is exploding deep within
I wonder could it be anything to do with your Locale settings? It
seems like Currency.getInstance() is exploding deep within the
NumberTypeConverterSupport class. That's a pretty innocuous call and
a bogus locale is the only thing I can think of that might cause
that
-t
On Sep 30,
Just to add a little more to this thread (sorry, I haven't been
reading my list mail for a few days, too much going on). I think
Gregg got my position only half right ;) My view on this kinda stuff
is pretty straightforward:
- True invariants should be expressed in the domain model. Stuff
Hmm, I don't know. It was created the exact same way as the last
bundle we submitted, so I'd hope it's ok. But I'm a complete maven
neophyte :o
-t
On Aug 19, 2008, at 10:30 AM, marijan milicevic wrote:
Tim Fennell wrote:
Automatically no. Have we started the process, yes ;)
You can
Automatically no. Have we started the process, yes ;)
You can follow the ticket here if you're interested:
http://jira.codehaus.org/browse/MAVENUPLOAD-2179
-t
On Aug 18, 2008, at 1:01 PM, David G Friedman wrote:
Ben,
Does the release automatically push out to maven repositories?
Just to let everyone know, Ben submitted the release announcement to
the serverside and it's been published here:
http://www.theserverside.com/news/thread.tss?thread_id=50391
-t
On Aug 18, 2008, at 2:25 PM, Levi Hoogenberg wrote:
Great! It will be hard for 1.6 to trump this release
Stripes does indeed store things in a HashMap (ValidationErrors is
actually a sublcass of HashMap). The s:errors tag also drops all the
errors into a set so that we can't display the exact same text twice
(which can happen when using indexed properties and you get the same
error on
So I have to admit that I'm kinda with Remi on this one :o I
understand that there are folks out there who want this capability.
But for me the light bulb has not gone off - I don't get why you
would want to do this deep-down, very close to the protocol, REST stuff.
Of course, if Will or
This hasn't really changed since 1.4.x as far as I know. We've never
instantiated the action bean on the JSP if it wasn't there. There
are a number of ways to get around this:
1) use a s:useActionBean tag on the JSP
2) have your index.jsp just issue a jsp:forward to the actionBean and
Hey Alan,
I'm not sure this is a bug. I'm not saying it isn't, I'm just not
sure it is either. You are supplying recordName to the message
right? If we escaped all the parameters to a message then you would
never be able to supply an HTML character in a message. If you
wanted to write
I think you have it. The JavaBean spec defines the relationship
between a property name and the accessor/mutator methods for that
property. In this case if you have a property called name then the
accessor methods would be called getName()/setName (unless name was a
boolean of course).
,
Tim Fennell himself ;-)
Cheers,
Freddy
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01
I've been thinking about the different error handling for different
methods for a while, but we haven't implemented anything for 1.5.
Essentially I think I'd like to go to a model where you can decorate
any method on the class with something like:
@HandlesErrors public fallback() { ...
Bear with me a minute here Stripers. I was in a Borders book store
today killing a little time. I wandered over to the tech books
section to see what was new. A new O'Reilly book caught my eye called
Harnessing Hibernate. It sounded like it'd be a real high-end
hibernate book and that
The long and the short is that you should probably take a look at the
1.5 beta instead of 1.4.3. The way we scanned for classes in 1.4.3
was heavily dependent on finding a URLClassLoader to work with. The
code in 1.5 is much more friendly to other class loaders and should
work in a lot
Can anyone with Spring experience help George out? This doesn't look
(to me) like a Stripes specific problem, but then since I don't know a
whole lot about Spring it's hard to know!
-t
On Apr 16, 2008, at 1:49 PM, [EMAIL PROTECTED] wrote:
Hi all,
I am using Stripes 1.4.3, Spring 2.5.3
You know, the more I think about this, the more I think we've all
been barking up the wrong tree. When you have lists in your action
bean (or domain model) the validations are applied individually to
each element of the list as it gets bound. So the expression would
be evaluated against
Alan,
I completely agree. I think adding @Validate(trim=[false|true])
would work well for most folks. Can you JIRA it please? Thanks,
-t
On Apr 1, 2008, at 9:53 AM, Alan Burlison wrote:
Freddy D. wrote:
Alan, your best bet is likely to use a @Before
BindingAndValidation method to
Isn't there an EL builtin function for size/length though? I think
the following should work:
@Validate(expression=fn:length(this) 0))
or alternatively
@Validate(expression=!empty(this))
My syntax/names might be a little off, but you get the idea.
-t
On Mar 29, 2008, at 4:54 AM,
24 matches
Mail list logo
