I've been using Struts 2 for a few weeks now and am finding a few areas that
don't seem to posses the same clarity/utilty as most of the framework. I'm
interested in seeing if I can come up with a patch to address these areas.
The first thing that's been bothering me is the lack of a clean way to
From: Brian Pontarelli <[EMAIL PROTECTED]>
Eric,
SmartURLs (and the zero-config/code-behind) provides a property
that seems like what you need. SmartURLs property is named:
smarturls.action.default.parent.package
which sets the default parent package for all actions that don't
provide
Quoting Brian Pontarelli <[EMAIL PROTECTED]>:
You actually can annotate packages. There is a special java file
called package-info.java that you place in a package and annotate
like this:
@ParentPackage("foo")
package com.example.actions;
Ahh, that's what I was referencing as a possible sol
Quoting Brian Pontarelli <[EMAIL PROTECTED]>:
I guess I'm missing the overall use case. Do you just want to get rid
of all your XML configuration and put everything inside Java code and
annotations? Or are you trying to solve a specific problem that is
currently unsolvable? It seems like it is
I'm happy with a hybrid mix of XML and annotations; however
something feels very wrong about using the package-info.java file
for holding the XWork package level annotations, so I'm trying to
think of alternatives.
I can understand the difficultly in using a new language concept that has
little
[Please excuse if this appears twice, the copy I sent several hours ago seems to
have gotten lost and my webmail client does drop emails at times]
>> I'm happy with a hybrid mix of XML and annotations; however
>> something feels very wrong about using the package-info.java file
>> for holding the
I'm very interested in starting to test the 2.1 code base and the convention
plugin work.
I've done a SVN checkout of the strut2 and xwork code base. I've
built/installed both with maven into my local maven repository. The new
convention plugin doesn't show up in the list of things build with th
I've been investigating some interesting behavior regarding model-driven actions
and found a past thread that covers the situation from late last year:
http://www.nabble.com/ModelDriven-CRUD-validation-failure-still-causes-JPA-update-td12987242.html
First I outline the problem, then a possible fra
Another possible solution I want to try exploring (but unfortunately its
Hibernate specific) is making a custom version of the validator interceptor:
Inject the session into the interceptor
Call session.readOnly(entity,true) on failed validation
If I'm reading things correctly this should
a) kee
[ I suspect this is going to break threading Is there a good way to respond
to a message from a digest without breaking threading? )
Adam Hardy on 26/04/08 10:42, wrote:
> I am pulling in what I wrote earlier because I should correct what I said
> about letting entities slip out of scope. Fol
Alexander Snaps gmail.com> writes:
> I know I am repeating myself, but what is getting in the way of NOT starting
> a transaction at all in the case of a validation error... Shoudn't the
> transaction be started much later anyways, and only if validation passed?
Because that doesn't solve the pro
11 matches
Mail list logo
