Set a breakpoint in ReflectiveServiceLayer#validate and inspect your object 
there to try to understand why it validates when it shouldn't.

BTW, RequestFactory *requires* OSIV, but make sure you use one transaction 
per service method, *not* one that spans the entire request/response.

On Friday, October 18, 2013 7:40:49 PM UTC+2, Nermin wrote:
>
> Dear Group,
>
> What could be the reason for GWT treating the ConstraintViolationException 
> as on ordinary Exception in case an updated entity (with wrong parameter 
> e.g. Email Address) is sent to server using RequestFactory?
>
> This might be a simple misconfiguration of my application but also a 
> GWT-Bug. 
>
>  
>
> My configuration:
>
> I am using GW2.5.1, RequestFactory for accessing Entities via 
> EntityProxyies. JPA and OpenSessionInView (OSIV) pattern is used for 
> handling the entities. Hibernate-validator-4.3.1 is used as the JSR303 
> implementation.
>
> Problem description:
>
> *Case 1:* Create a new User entity on client side that contains 
> constraint violations (e.g. incorrect email address) works fine. The 
> *onConstraintViolation() 
> method gets called*. All fine.
>
> *Case 2:* Read User entity from server, update it with „incorrect email 
> address“ and try to persist it. This throws an exception 
> (javax.validation.ConstraintViolationException) and *onFailure() method 
> gets called!!!????* 
>
> *I would expect onConstraintViolation() method to get called?* Why is 
> this not the case???
>
> WHY IS javax.validation.ConstraintViolationException HANDELED AS A REGULAR 
> SERVER EXCEPTION????
>
> By the way: the server side handler method never gets called. This is 
> probably how it should be in case of a Constraint Violation.
>
> Fri Oct 18 18:38:50 CEST 2013 WireActivityLogger
>
> SEVERE: Server Error 500 <html>
>
> <head>
>
> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>
> <title>Error 500 Validation failed for 
> com.emajstor.server.persistence.PrivatePerson@4e561533 during pre-update 
> for groups [interface javax.validation.groups.Default] - exceptions are 
> attached</title>
>
> </head>
>
> <body><h2>HTTP ERROR 500</h2>
>
> <p>Problem accessing /unAuthRequestFactory. Reason:
>
> <pre>    Validation failed for 
> com.emajstor.server.persistence.PrivatePerson@4e561533 during pre-update 
> for groups [interface javax.validation.groups.Default] - exceptions are 
> attached</pre></p><h3>Caused *
> by:</h3><pre>javax.validation.ConstraintViolationException*: Validation 
> failed for com.emajstor.server.persistence.PrivatePerson@4e561533 during 
> pre-update for groups [interface javax.validation.groups.Default] - 
> exceptions are attached
>
>        at org.datanucleus.validation.BeanValidatorHandler.validate(*
> BeanValidatorHandler.java:71*)
>
>        at org.datanucleus.validation.BeanValidatorHandler.preStore(*
> BeanValidatorHandler.java:86*)
>
>        at org.datanucleus.api.jpa.JPACallbackHandler.preStore(*
> JPACallbackHandler.java:102*)
>
>        at org.datanucleus.state.JDOStateManager.flush(*
> JDOStateManager.java:3827*)
>
>        at org.datanucleus.ObjectManagerImpl.flushInternalWithOrdering(*
> ObjectManagerImpl.java:3888*)
>
>        at org.datanucleus.ObjectManagerImpl.flushInternal(*
> ObjectManagerImpl.java:3811*)
>
>        at org.datanucleus.ObjectManagerImpl.flush(*
> ObjectManagerImpl.java:3751*)
>
>        at org.datanucleus.ObjectManagerImpl.preCommit(*
> ObjectManagerImpl.java:4141*)
>
>        at org.datanucleus.ObjectManagerImpl.transactionPreCommit(*
> ObjectManagerImpl.java:428*)
>
>        at org.datanucleus.TransactionImpl.internalPreCommit(*
> TransactionImpl.java:398*)
>
>        at org.datanucleus.TransactionImpl.commit(*TransactionImpl.java:287
> *)
>
>        at org.datanucleus.ObjectManagerImpl.close(*
> ObjectManagerImpl.java:1090*)
>
>        at org.datanucleus.api.jpa.JPAEntityManager.close(*
> JPAEntityManager.java:193*)
>
>        at com.emajstor.server.AppHandlerFilter.doFilter(*
> AppHandlerFilter.java:91*)
>
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(*
> ServletHandler.java:1157*)
>
>        at com.google.appengine.api.socket.dev.DevSocketFilter.doFilter(*
> DevSocketFilter.java:74*)
>
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(*
> ServletHandler.java:1157*)
>
>        at 
> com.google.appengine.tools.development.ResponseRewriterFilter.doFilter(*
> ResponseRewriterFilter.java:123*)
>
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(*
> ServletHandler.java:1157*)
>
>        at 
> com.google.appengine.tools.development.HeaderVerificationFilter.doFilter(*
> HeaderVerificationFilter.java:34*)
>
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(*
> ServletHandler.java:1157*)
>
>        at com.google.appengine.api.blobstore.dev.ServeBlobFilter.doFilter(
> *ServeBlobFilter.java:63*)
>
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(*
> ServletHandler.java:1157*)
>
>        at 
> com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(*
> TransactionCleanupFilter.java:43*)
>
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(*
> ServletHandler.java:1157*)
>
>        at 
> com.google.appengine.tools.development.StaticFileFilter.doFilter(*
> StaticFileFilter.java:125*)
>
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(*
> ServletHandler.java:1157*)
>
>        at 
> com.google.appengine.tools.development.DevAppServerServersFilter.doDirectRequest(
> *DevAppServerServersFilter.java:369*)
>
>        at 
> com.google.appengine.tools.development.DevAppServerServersFilter.doDirectServerRequest(
> *DevAppServerServersFilter.java:352*)
>
>        at 
> com.google.appengine.tools.development.DevAppServerServersFilter.doFilter(
> *DevAppServerServersFilter.java:115*)
>
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(*
> ServletHandler.java:1157*)
>
>        at org.mortbay.jetty.servlet.ServletHandler.handle(*
> ServletHandler.java:388*)
>
>        at org.mortbay.jetty.security.SecurityHandler.handle(*
> SecurityHandler.java:216*)
>
>        at org.mortbay.jetty.servlet.SessionHandler.handle(*
> SessionHandler.java:182*)
>
>        at org.mortbay.jetty.handler.ContextHandler.handle(*
> ContextHandler.java:765*)
>
>        at org.mortbay.jetty.webapp.WebAppContext.handle(*
> WebAppContext.java:418*)
>
>        at 
> com.google.appengine.tools.development.DevAppEngineWebAppContext.handle(*
> DevAppEngineWebAppContext.java:97*)
>
>        at org.mortbay.jetty.handler.HandlerWrapper.handle(*
> HandlerWrapper.java:152*)
>
>        at 
> com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(
> *JettyContainerService.java:480*)
>
>        at org.mortbay.jetty.handler.HandlerWrapper.handle(*
> HandlerWrapper.java:152*)
>
>        at org.mortbay.jetty.Server.handle(*Server.java:326*)
>
>        at org.mortbay.jetty.HttpConnection.handleRequest(*
> HttpConnection.java:542*)
>
>        at org.mortbay.jetty.HttpConnection$RequestHandler.content(*
> HttpConnection.java:938*)
>
>        at org.mortbay.jetty.HttpParser.parseNext(*HttpParser.java:755*)
>
>        at org.mortbay.jetty.HttpParser.parseAvailable(*HttpParser.java:218
> *)
>
>        at org.mortbay.jetty.HttpConnection.handle(*HttpConnection.java:404
> *)
>
>        at org.mortbay.io.nio.SelectChannelEndPoint.run(*
> SelectChannelEndPoint.java:409*)
>
>        at org.mortbay.thread.QueuedThreadPool$PoolThread.run(*
> QueuedThreadPool.java:582*)
>
> </pre>
>
> <hr /><i><small>Powered by Jetty://</small></i><br/>                          
>                       
>
>
> <br/>                                                
>
> < 
>
>  
>
> </body>
>
> </html>
>
>  
>
> *Case 3:* Now I *change the EntityProxy to ValueProxy* ..... and 
> „magically“ it *works fine*. Instead of getting an server error, when 
> updating an existing User entity with a wrong EmailAddress, as shown above, 
> I am getting the onConstraintViolation() method called!? (This is exactly 
> what I would expect in Case 2 to happen - when EntityProxy used.)
>
> *Case 4:* When I *take the OSIV implementation out* and do testing on a 
> simple Entity using EntityProxy: „magically“ it *works fine*. How ever, 
> my application requires OSIV implementation in order to work.
>
>
> This strange behavior sounds pretty much as a GWT-bug to me. Can anyone 
> else observe a similar behavior ... the constraint violations being handled 
> as regular server exception when updating an existing entity??
>
>
> Thank you for your Help!!
>
>  
> Nermin
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to