I know this is an old thread, but I ran into the same problem with the
ValidatorException causing the crash. After much trial and error, this is the
solution I have come up with. I thought it may be useful for others, at least
once I get the last little niggle out of it, which I don't think is
Ok, found out that hosed is it slang and means broken ;).
However...
@Gavin, could you explain me why using setRollbackOnly() causes isn't good for
the PersistenceContext?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3971221#3971221
Reply to the post :
If a txn rolls back, the EJB3 spec says that the PC should be cleared. So you
will lose the state of the PC.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3971307#3971307
Reply to the post :
Thanks for your answer. But the PC only exists during editing one single entity
(in a conversation), so I think it's ok... it works without problems ;).
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3971324#3971324
Reply to the post :
Gavin, maybe we misunderstood each other. It's important to mention that the
actionMethod above shall perform complex validation and then save if
everything is alright.
| @Stateful
| @Scope(CONVERSATION)
| @Name(whateverEditor)
|
1. For simple validation (just value) we can still use JSF validation.
2. For complex validation I use drools (jBoss Rules).
It nicely integrated with Seam Page Flow (see seam samples).
You can express your validation in rule set. IMHO it looks like quite
elegantly. You can define as complex
[EMAIL PROTECTED] wrote : There is one problem with performing validation
during the action phase: if you are using an extended persistence context, you
would prefer to do validation before applying values onto the model object. But
by the time we get to the action method, the values have
Unfortunately this is not a solution. The EPC is considered hosed after a
transaction rollback.
The only way (per-spec) is to annotate actionMethod() or the bean as
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED), which is ugly.
CVS version of Seam has
I agree with Gavin. I've always been ok with complex validation in the action
method (or control flow). If you need something a little more declarative, it
shouldn't be too hard to use Seam plus EJB interceptors to write your thin
framework.
If you think about it this is what JSF is doing
I still think that it is frustrating that JSF validator error messages and
action phase validation error messages won't appear at the same time. Any ideas?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3970183#3970183
Reply to the post :
There is one problem with performing validation during the action phase: if you
are using an extended persistence context, you would prefer to do validation
before applying values onto the model object. But by the time we get to the
action method, the values have already been applied. It is
And required checking happens outside of conversion/validation at yet another
time. Unfortunately, JSF seems to be designed to support providing a
consistent checked state through each phase of the lifecycle and short circuit
phases if there are problems. This almost explicitly designs away
I see where you are coming from with validating within the application but IMO
the disadvantages are greater
* Your entities get updated with invalid values (less of an issue with manual
flushing as Gavin says)
| * That's what @Invalid did and IIRC it didn't work brilliantly
| * As you
IMO, it is perfectly reasonable to put complex validations in the action
method...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3969930#3969930
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3969930
AFAIK the ModelValidator doesn't solve the 'complex' validation case: when you
want to validate the value of component x against the value of component y. A
simple example of this is that the integers entered into X and Y must add up to
150.
View the original post :
Well, forget it. There's another problem.
That complex validation would work well on an existing person that you edit.
But when you create a new person all its properties are null. And when you fill
in the fields in a form and click save, then the persons properties are still
null during
IMO this is a (big) problem with JSF validation - not that the validation
framework can only handle 'simple' validation, but that you can't display
'complex' validation errors at the same time as simple ones. I can't see a way
around it. I wonder if there has been any disucssion about this on
bfo81 wrote :
| But when you create a new person all its properties are null. And when you
fill in the fields in a form and click save, then the persons properties are
still null during validation (phase 3). They get their concrete values later,
in phase 4 (update model values). And, alas,
18 matches
Mail list logo
