Re: RequestFactory Could not parse payload: payload[0] = N

[William Brophy]

For anyone else still having this issue, I thought it may be helpful to 
share that I encountered a similar exception when attempting to construct a 
json number with an NaN value

On Saturday, July 28, 2012 at 3:46:00 PM UTC-4, Sydney wrote:
>
> After deploying my app on appengine, I get the following exception: 
>
> com.google.web.bindery.requestfactory.server.RequestFactoryServlet doPost: 
> Unexpected error
> java.lang.RuntimeException: Could not parse payload: payload[0] = N
> at 
> com.google.web.bindery.autobean.vm.impl.JsonSplittable.create(JsonSplittable.java:70)
> at 
> com.google.web.bindery.autobean.shared.impl.StringQuoter.create(StringQuoter.java:46)
> at 
> com.google.web.bindery.autobean.shared.ValueCodex$Type$7.encode(ValueCodex.java:122)
> at 
> com.google.web.bindery.autobean.shared.ValueCodex.encode(ValueCodex.java:315)
> at 
> com.google.web.bindery.autobean.shared.impl.AutoBeanCodexImpl$ValueCoder.extractSplittable(AutoBeanCodexImpl.java:500)
> at 
> com.google.web.bindery.autobean.shared.impl.AbstractAutoBean.setProperty(AbstractAutoBean.java:277)
> at 
> com.google.web.bindery.autobean.vm.impl.ProxyAutoBean.setProperty(ProxyAutoBean.java:253)
> at 
> com.google.web.bindery.autobean.vm.impl.BeanPropertyContext.set(BeanPropertyContext.java:44)
> at 
> com.google.web.bindery.requestfactory.server.Resolver$PropertyResolver.visitValueProperty(Resolver.java:154)
> at 
> com.google.web.bindery.autobean.vm.impl.ProxyAutoBean.traverseProperties(ProxyAutoBean.java:289)
> at 
> com.google.web.bindery.autobean.shared.impl.AbstractAutoBean.traverse(AbstractAutoBean.java:166)
> at 
> com.google.web.bindery.autobean.shared.impl.AbstractAutoBean.accept(AbstractAutoBean.java:101)
> at 
> com.google.web.bindery.requestfactory.server.Resolver.resolveClientValue(Resolver.java:395)
> at 
> com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.processInvocationMessages(SimpleRequestProcessor.java:483)
> at 
> com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:225)
> at 
> com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:127)
> at 
> com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:133)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
>
> Any idea of what the exception means? Thanks
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT Plugin v3.0 and tbroyer maven integration with requestfactory

[Sheldon Damons]

Thanks you Thomas, your help is always much appreciated.

To get Eclipse to work, I added the shared module source as linked source 
in the server module project and enabled annotation processing. The only 
problem is that when I try 'open declaration' it take me to the server's 
linked source and not the shared folders source. Other than that, debugging 
in Eclipse works well.

Thanks again.

On Wednesday, 2 August 2017 20:18:53 UTC+2, Thomas Broyer wrote:
>
>
>
> On Wednesday, August 2, 2017 at 7:24:53 PM UTC+2, Sheldon Damons wrote:
>>
>> Hi Guys,
>>
>> I have been investigating migrating our current GWT Project to use 
>> gwt-eclipse-plugin-v3 <https://github.com/gwt-plugins/gwt-eclipse-plugin> 
>> together 
>> with gwt-maven-plugin <https://tbroyer.github.io/gwt-maven-plugin/>. Our 
>> project uses Requestfactory extensively, so I created a project using 
>> modular-requestfactory <https://github.com/tbroyer/gwt-maven-archetypes/>
>>  archetype.
>>
>> Using maven commands I could successfully run the sample app, but I could 
>> not get the app to run within eclipse using the following GWT Eclipse 
>> Plugin V3 - GWT Development Mode with Tomcat - Manually Configure 
>> <https://www.youtube.com/watch?v=-_YcBeI_Feo=6=PLBbgqtDgdc_TqzA-qXrjgTFMC_6DKAQyT>
>>  as 
>> a guide.
>>
>> This is the error I get :
>>
>> Aug 02, 2017 5:11:15 PM com.google.web.bindery.requestfactory.server.
>> RequestFactoryServlet doPost
>> SEVERE: Unexpected error
>> java.lang.RuntimeException: The RequestFactory ValidationTool must be run 
>> for the net.access.gwtmain.AppFactory RequestFactory type
>> at 
>> com.google.web.bindery.requestfactory.vm.impl.Deobfuscator$Builder.load(Deobfuscator.java:58)
>> at 
>> com.google.web.bindery.requestfactory.server.ResolverServiceLayer.updateDeobfuscator(ResolverServiceLayer.java:44)
>>
>>
>> I have manually added the requestfactory-apt to the compiler annotation 
>> resultig in:
>>
>> SEVERE: Unexpected error
>> com.google.web.bindery.requestfactory.server.UnexpectedException: No 
>> domain method descriptor is mapped to operation 
>> yc28czZ8zQtD$z0QQ8ciWx0s3p4=
>>  at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.
>> die(ServiceLayerDecorator.java:216)
>>  at com.google.web.bindery.requestfactory.server.ResolverServiceLayer.
>> resolveDomainMethod(ResolverServiceLayer.java:121)
>>  at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.
>> resolveDomainMethod(ServiceLayerDecorator.java:152)
>>
>>  Can some direct me on how to get this to work.
>>
>> Thanks in advance.
>>
>
> In the modular-requestfactory archetype, proxies and request contexts in 
> 'shared' reference domain objects and services in 'server' by name (using 
> @ProxyForName and @ServiceName), so you cannot use the annotation processor 
> when compiling the shared interfaces, you have to do the processing in 
> 'server', either using the ValidationTool (as done in the Maven build), or 
> possibly calling the annotation processor on the RequestFactory interface 
> *compiled class* (I don't know of any build tool, besides low-level ones 
> like Ant, or IDE that allows this).
>
> I don't know how to set things up in Eclipse with WTP, but you can launch 
> and debug the server code by using Run as… / Debug as… → Maven… to run the 
> equivalent of the "mvn tomcat7:run" that you'd run from the command-line.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT Plugin v3.0 and tbroyer maven integration with requestfactory

[Thomas Broyer]

On Wednesday, August 2, 2017 at 7:24:53 PM UTC+2, Sheldon Damons wrote:
>
> Hi Guys,
>
> I have been investigating migrating our current GWT Project to use 
> gwt-eclipse-plugin-v3 <https://github.com/gwt-plugins/gwt-eclipse-plugin> 
> together 
> with gwt-maven-plugin <https://tbroyer.github.io/gwt-maven-plugin/>. Our 
> project uses Requestfactory extensively, so I created a project using 
> modular-requestfactory <https://github.com/tbroyer/gwt-maven-archetypes/>
>  archetype.
>
> Using maven commands I could successfully run the sample app, but I could 
> not get the app to run within eclipse using the following GWT Eclipse 
> Plugin V3 - GWT Development Mode with Tomcat - Manually Configure 
> <https://www.youtube.com/watch?v=-_YcBeI_Feo=6=PLBbgqtDgdc_TqzA-qXrjgTFMC_6DKAQyT>
>  as 
> a guide.
>
> This is the error I get :
>
> Aug 02, 2017 5:11:15 PM com.google.web.bindery.requestfactory.server.
> RequestFactoryServlet doPost
> SEVERE: Unexpected error
> java.lang.RuntimeException: The RequestFactory ValidationTool must be run 
> for the net.access.gwtmain.AppFactory RequestFactory type
> at 
> com.google.web.bindery.requestfactory.vm.impl.Deobfuscator$Builder.load(Deobfuscator.java:58)
> at 
> com.google.web.bindery.requestfactory.server.ResolverServiceLayer.updateDeobfuscator(ResolverServiceLayer.java:44)
>
>
> I have manually added the requestfactory-apt to the compiler annotation 
> resultig in:
>
> SEVERE: Unexpected error
> com.google.web.bindery.requestfactory.server.UnexpectedException: No 
> domain method descriptor is mapped to operation 
> yc28czZ8zQtD$z0QQ8ciWx0s3p4=
>  at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.die
> (ServiceLayerDecorator.java:216)
>  at com.google.web.bindery.requestfactory.server.ResolverServiceLayer.
> resolveDomainMethod(ResolverServiceLayer.java:121)
>  at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.
> resolveDomainMethod(ServiceLayerDecorator.java:152)
>
>  Can some direct me on how to get this to work.
>
> Thanks in advance.
>

In the modular-requestfactory archetype, proxies and request contexts in 
'shared' reference domain objects and services in 'server' by name (using 
@ProxyForName and @ServiceName), so you cannot use the annotation processor 
when compiling the shared interfaces, you have to do the processing in 
'server', either using the ValidationTool (as done in the Maven build), or 
possibly calling the annotation processor on the RequestFactory interface 
*compiled class* (I don't know of any build tool, besides low-level ones 
like Ant, or IDE that allows this).

I don't know how to set things up in Eclipse with WTP, but you can launch 
and debug the server code by using Run as… / Debug as… → Maven… to run the 
equivalent of the "mvn tomcat7:run" that you'd run from the command-line.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

GWT Plugin v3.0 and tbroyer maven integration with requestfactory

[Sheldon Damons]

Hi Guys,

I have been investigating migrating our current GWT Project to use 
gwt-eclipse-plugin-v3 <https://github.com/gwt-plugins/gwt-eclipse-plugin> 
together 
with gwt-maven-plugin <https://tbroyer.github.io/gwt-maven-plugin/>. Our 
project uses Requestfactory extensively, so I created a project using 
modular-requestfactory <https://github.com/tbroyer/gwt-maven-archetypes/>
 archetype.

Using maven commands I could successfully run the sample app, but I could 
not get the app to run within eclipse using the following GWT Eclipse 
Plugin V3 - GWT Development Mode with Tomcat - Manually Configure 
<https://www.youtube.com/watch?v=-_YcBeI_Feo=6=PLBbgqtDgdc_TqzA-qXrjgTFMC_6DKAQyT>
 as 
a guide.

This is the error I get :

Aug 02, 2017 5:11:15 PM com.google.web.bindery.requestfactory.server.
RequestFactoryServlet doPost
SEVERE: Unexpected error
java.lang.RuntimeException: The RequestFactory ValidationTool must be run 
for the net.access.gwtmain.AppFactory RequestFactory type
at 
com.google.web.bindery.requestfactory.vm.impl.Deobfuscator$Builder.load(Deobfuscator.java:58)
at 
com.google.web.bindery.requestfactory.server.ResolverServiceLayer.updateDeobfuscator(ResolverServiceLayer.java:44)


I have manually added the requestfactory-apt to the compiler annotation 
resultig in:

SEVERE: Unexpected error
com.google.web.bindery.requestfactory.server.UnexpectedException: No domain 
method descriptor is mapped to operation yc28czZ8zQtD$z0QQ8ciWx0s3p4=
 at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.die(
ServiceLayerDecorator.java:216)
 at com.google.web.bindery.requestfactory.server.ResolverServiceLayer.
resolveDomainMethod(ResolverServiceLayer.java:121)
 at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.
resolveDomainMethod(ServiceLayerDecorator.java:152)

 Can some direct me on how to get this to work.

Thanks in advance.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to use Object?

[salk31]

Thanks Ignacio,

Indeed. Our app will probably stay on the GWT 2.8 "branch" for a long time 
to come. Hopefully in that time something better will come along. We are 
mainly betting heavily on Java, JPA, lots of client side code... So 
hopefully won't be too painful a switch.

Cheers

Sam

On Friday, January 6, 2017 at 7:21:35 PM UTC, Ignacio Baca Moreno-Torres 
wrote:
>
> Salk31, please note that we are saying that if you are going to start 
> learning RF right now, you better try other approach. But as you said, RF, 
> editor framework, probably validations, ui binder, etc is a pretty good 
> solution. You should note that this solution is not going to evolve anymore 
> (I think), but this again might be a good thing because hasn't evolved in 
> the last 4 years and it is still a good solution. Actually I stop using RF 
> when I stopped using editor framework. Both together is a good option.
>
> El vie., 6 ene. 2017 15:54, Jens  
> escribió:
>
>> And who knows, maybe one day we'll finally have grpc-web ;-)
>>>
>>
>> Oh please! +1 
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "GWT Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-web-toolkit+unsubscr...@googlegroups.com .
>> To post to this group, send email to google-we...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/google-web-toolkit.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to use Object?

[Ignacio Baca Moreno-Torres]

Salk31, please note that we are saying that if you are going to start
learning RF right now, you better try other approach. But as you said, RF,
editor framework, probably validations, ui binder, etc is a pretty good
solution. You should note that this solution is not going to evolve anymore
(I think), but this again might be a good thing because hasn't evolved in
the last 4 years and it is still a good solution. Actually I stop using RF
when I stopped using editor framework. Both together is a good option.

El vie., 6 ene. 2017 15:54, Jens  escribió:

> And who knows, maybe one day we'll finally have grpc-web ;-)
>
>
> Oh please! +1
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to use Object?

[Jens]

>
> And who knows, maybe one day we'll finally have grpc-web ;-)
>

Oh please! +1 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to use Object?

[Thomas Broyer]

On Friday, January 6, 2017 at 1:11:35 PM UTC+1, Ignacio Baca Moreno-Torres 
wrote:
>
> Hehe this is not a bad thing! Just means that now exists simpler 
> solutions. I personally think that RF keeps track of object (the entity id) 
> which add really a lot of complexity, at this point I think that the lib 
> should include some kind of storage with remote synchronization because if 
> not, the complexity just makes thing difficult with the "only" benefit of 
> reducing transfer size.
>

FWIW, that was the original design, in the first milestones of GWT 2.1. It 
was overhauled in the RC (too complex I believe, particularly when 
requesting partial objects, meaning that your "local cache" could have some 
properties that are out-of-date, breaking the "diff" requests).
 

> I also don't like the obscure encoding,
>

Much less obscure than RPC ;-)
And "documented" by 
AutoBeans: 
https://github.com/gwtproject/gwt/tree/2.8.0/user/src/com/google/web/bindery/requestfactory/shared/messages
They allow entities to be referenced multiple times without duplication, 
including reference cycles.

not easy to debug, not compatible with changes in the model (sometimes). 
> IMO RF was promising, but it's complexity do not justify its benefits.
>

I tend to agree. The main reason RF hasn't have more bugs fixed is that 
it's awfully complex (particularly on the server side) and hard to debug. I 
had floated the idea for years now to simplify things by generating code 
and relying less on reflection, but I'm not sure it'd be "compatible" with 
the ServiceLayer machinery.
 

> But the best thing to do is always an small project, and test each 
> strategy, RF, RPC and Rest+Jackson, Rest+JsInterop. The last one has de 
> benefit nowadays than is done almost everything in the browser natively 
> without different code for different browsers.
>

Most importantly, Web APIs put the complexity out of the code and into the 
protocol/API-design (to make it RESTful): they're super-easy to code on the 
both server (using Spring Web, JAX-RS, Restlet or RESTX) and client side 
(using JsInterop; which even allows your to share your objects –or 
interfaces– with the server)
If you're not too concerned with RESTful-ness and are happy with an 
RPC-style API, then JSON-RPC is quite easy to implement (and while RF can 
do JSON-RPC, it's not worth the complexity IMO)
And who knows, maybe one day we'll finally have grpc-web ;-)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to use Object?

[salk31]

I can definitely see that it is complex (like compiler, garage collection, 
rdbms...) so it needs to outweigh that cost. My problem is that I really 
like UiBinder + Editor + RequestFactory and we have a large app built 
around this. I've been doing web for 25 years and it finally felt mature.

Do other frameworks offer anything to match the Editor framework setting 
fetch paths? (along with strong typing, compile time checks, batching 
requests, tracking deltas...)?



On Friday, January 6, 2017 at 1:09:49 PM UTC, Ed wrote:
>
> I migrated everything from RPC to RF.  Thinking it was a better 
> alternative to 3rd party libs and could be sustainable when 3.0 arrives was 
> I wrong in this thinking?
>
> Regards
>
> On Fri, Jan 6, 2017 at 7:10 AM, Ignacio Baca Moreno-Torres <
> ign...@bacamt.com > wrote:
>
>> Hehe this is not a bad thing! Just means that now exists simpler 
>> solutions. I personally think that RF keeps track of object (the entity id) 
>> which add really a lot of complexity, at this point I think that the lib 
>> should include some kind of storage with remote synchronization because if 
>> not, the complexity just makes thing difficult with the "only" benefit of 
>> reducing transfer size. I also don't like the obscure encoding, not easy to 
>> debug, not compatible with changes in the model (sometimes). IMO RF was 
>> promising, but it's complexity do not justify its benefits. But the best 
>> thing to do is always an small project, and test each strategy, RF, RPC and 
>> Rest+Jackson, Rest+JsInterop. The last one has de benefit nowadays than is 
>> done almost everything in the browser natively without different code for 
>> different browsers.
>>
>> El jue., 5 ene. 2017 15:01, salk31 <sal...@gmail.com > 
>> escribió:
>>
>>> :(
>>>
>>>
>>> On Monday, December 26, 2016 at 2:11:35 PM UTC, Thomas Broyer wrote:
>>>>
>>>> +1 Do not start learning/using RequestFactory (or even GWT RPC I'd 
>>>> say). Learn JsInterop and use json-based http APIs.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "GWT Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to google-web-toolkit+unsubscr...@googlegroups.com 
>>> .
>>> To post to this group, send email to google-we...@googlegroups.com 
>>> .
>>> Visit this group at https://groups.google.com/group/google-web-toolkit.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "GWT Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-web-toolkit+unsubscr...@googlegroups.com .
>> To post to this group, send email to google-we...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/google-web-toolkit.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to use Object?

[Ed]

I migrated everything from RPC to RF.  Thinking it was a better alternative
to 3rd party libs and could be sustainable when 3.0 arrives was I wrong in
this thinking?

Regards

On Fri, Jan 6, 2017 at 7:10 AM, Ignacio Baca Moreno-Torres <
igna...@bacamt.com> wrote:

> Hehe this is not a bad thing! Just means that now exists simpler
> solutions. I personally think that RF keeps track of object (the entity id)
> which add really a lot of complexity, at this point I think that the lib
> should include some kind of storage with remote synchronization because if
> not, the complexity just makes thing difficult with the "only" benefit of
> reducing transfer size. I also don't like the obscure encoding, not easy to
> debug, not compatible with changes in the model (sometimes). IMO RF was
> promising, but it's complexity do not justify its benefits. But the best
> thing to do is always an small project, and test each strategy, RF, RPC and
> Rest+Jackson, Rest+JsInterop. The last one has de benefit nowadays than is
> done almost everything in the browser natively without different code for
> different browsers.
>
> El jue., 5 ene. 2017 15:01, salk31 <sal...@gmail.com> escribió:
>
>> :(
>>
>>
>> On Monday, December 26, 2016 at 2:11:35 PM UTC, Thomas Broyer wrote:
>>
>> +1 Do not start learning/using RequestFactory (or even GWT RPC I'd say).
>> Learn JsInterop and use json-based http APIs.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit+unsubscr...@googlegroups.com.
>> To post to this group, send email to google-web-toolkit@googlegroups.com.
>> Visit this group at https://groups.google.com/group/google-web-toolkit.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to use Object?

[Ignacio Baca Moreno-Torres]

Hehe this is not a bad thing! Just means that now exists simpler solutions.
I personally think that RF keeps track of object (the entity id) which add
really a lot of complexity, at this point I think that the lib should
include some kind of storage with remote synchronization because if not,
the complexity just makes thing difficult with the "only" benefit of
reducing transfer size. I also don't like the obscure encoding, not easy to
debug, not compatible with changes in the model (sometimes). IMO RF was
promising, but it's complexity do not justify its benefits. But the best
thing to do is always an small project, and test each strategy, RF, RPC and
Rest+Jackson, Rest+JsInterop. The last one has de benefit nowadays than is
done almost everything in the browser natively without different code for
different browsers.

El jue., 5 ene. 2017 15:01, salk31 <sal...@gmail.com> escribió:

> :(
>
>
> On Monday, December 26, 2016 at 2:11:35 PM UTC, Thomas Broyer wrote:
>
> +1 Do not start learning/using RequestFactory (or even GWT RPC I'd say).
> Learn JsInterop and use json-based http APIs.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to use Object?

[salk31]

:(

On Monday, December 26, 2016 at 2:11:35 PM UTC, Thomas Broyer wrote:
>
> +1 Do not start learning/using RequestFactory (or even GWT RPC I'd say). 
> Learn JsInterop and use json-based http APIs.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to use Object?

[Thomas Broyer]

+1 Do not start learning/using RequestFactory (or even GWT RPC I'd say). Learn 
JsInterop and use json-based http APIs.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to use Object?

[Ignacio Baca Moreno-Torres]

Hi, a side note. IMO you should not start using request factory. It is a
pretty awesome lib which solves a lot of problem which probably you don't
have with the cost of a complexity which will make you ask a lot of doubt's
like this one for a long time. IMO if you want a API focused in your model,
with type inheritance, generics, etc. you should use GWT RPC. If you want a
more message payloads focused API, you should use some REST lib like
RestyGWT (mature, full java type support) or AutoREST (new, though to be
used with JsInterop, do not support inheritance or other fancy things).

El lun., 26 dic. 2016 4:01, Manuel  escribió:

> Hi everyone,
>
> I got a question regarding datatypes. I got a object on the server side
> that has a value of type Object. Like this:
>
> class MyObject{
> public *Object *getValue();
> public void setValue(*Object *value);
> }
>
>
> How is it possible to have proxies for this object on the client side
> (with different datatypes (Date, String, Double, Long, etc.))?
> Object-Datatype is not allowed in proxies. Using a template-type is also
> not allowed. Is it somehow possible to have proxies for this object?
>
> I guess I would like to have something like this:
>
> @ProxyFor(value = MyObject.class)
> MyDateObjectProxy{
> public *Date *getValue();
> public void setValue(*Date *value);
> }
>
> or
>
> @ProxyFor(value = MyObject.class)
> MyStringObjectProxy{
> public *String *getValue();
> public void setValue(*String *value);
> }
>
> Your help is much appreciated.
>
> Kind regards,
> Manuel
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Requestfactory: How to use Object?

[Manuel]

Hi everyone,

I got a question regarding datatypes. I got a object on the server side 
that has a value of type Object. Like this:

class MyObject{
public *Object *getValue();
public void setValue(*Object *value);
}


How is it possible to have proxies for this object on the client side (with 
different datatypes (Date, String, Double, Long, etc.))? Object-Datatype is 
not allowed in proxies. Using a template-type is also not allowed. Is it 
somehow possible to have proxies for this object?

I guess I would like to have something like this:

@ProxyFor(value = MyObject.class)
MyDateObjectProxy{
public *Date *getValue();
public void setValue(*Date *value);
}

or

@ProxyFor(value = MyObject.class)
MyStringObjectProxy{
public *String *getValue();
public void setValue(*String *value);
}

Your help is much appreciated.

Kind regards,
Manuel

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to build ValueProxy

[Manuel]

Ok I got it working now. For those facing the same problems, here are the 
pitfalls I came across:

1. I create a proxy with one request and send the proxy with another 
request. One have to create proxies with the same request that is use to 
call the server. 
2. The proxies had setter-Methods but no getter-Methods. Proxies need to 
declare getter!!

Kind regards,
Manuel

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Requestfactory: How to build ValueProxy

[Manuel]

Hi again,

maybe a simple example helps to understand better:
I actually want a request like this:

Request findAll(*VehicleProxy *vehicle);

However I want to send car, motorbike, bike etc with the request. Those are 
all implementing the "Vehicle" interface but also have more attributes and 
methods.

For now Im able to create and send the mentioned proxies. But the  
attributes along with this object are null on the server. In my request I 
can see that no attributes are send along the request.

Kind regards,
Manuel

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Requestfactory: How to build ValueProxy

[Manuel]

Hi everyone,

On the *server-side* I have an interface lets call it "CommonInterface". 
There are some subinterfaces and various implementations.

Now the client should be able to create objects that fit the 
"CommonInterface" and send it to the server. However there is a 
wrapperClass around that holds *CommonInterface as a member*.
The Request should look like this:

@Service(value = MyService.class, locator = MyServiceLocator.class)
public interface MyServiceRequest extends RequestContext{

Request findAll(*ObjectThatHasCommonInterfaceAsMemberProxy *
myObject);

}

Lets asume I want the client to send SubSub-CommonInterfaceImpl 
implementation. Which proxies do I need then on the client?

*Server Client*
CommonInterface   ? Create a proxy that maps to 
the interface ?  (No Implementation on the server, just Interface)
Sub-CommonInterface? Create a proxy that maps to 
the interface ?  (No Implementation on the server, just Interface)
SubSub-CommonInterface  ? Create a proxy that maps to the 
interface ?
SubSub-CommonInterfaceImplSubSub-CommonInterfaceImplProxy


However I already tried to implement it in various ways but couldnt get it 
working. Currently I have 2 proxies (CommonInterfaceProxy and 
SubSub-CommonInterfaceImplProxy that extends CommonInterfaceProxy). Im able 
to create instance of both of the proxies, but whenever I call 
objectThatHasCommonInterfaceAsMemberProxy.setCommonInterface(obj) I get an 
illegal argument exception.

Your help is much appreciated.

Thanks in advance.
Kind regards,
Manuel

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Requestfactory: How to build ValueProxy

[Manuel]

Hi everyone,

On the server-side I have an interface lets call it "CommonInterface". 
There are some subinterfaces and various implementations. 

Now the client should be able to create objects that fit the 
"CommonInterface" and send it to the server. The Request should look like 
this:

@Service(value = MyService.class, locator = MyServiceLocator.class)
public interface MyServiceRequest extends RequestContext{

Request findAll(*CommonInterfaceProxy* myObject);

}

Lets asume I want the client to send SubSub-CommonInterfaceImpl 
implementation. Which proxies do I need then on the client?

*Server  *  * Client*
CommonInterface   ? Create a proxy that maps to 
the interface ?  (No Implementation on the server, just Interface)
Sub-CommonInterface? Create a proxy that maps to 
the interface ?  (No Implementation on the server, just Interface)
SubSub-CommonInterface  ? Create a proxy that maps to the 
interface ?
SubSub-CommonInterfaceImplSubSub-CommonInterfaceImplProxy


However I already tried to implement it in vairous ways but couldnt get it 
working. Your help is much appreciated.

Thanks in advance.
Kind regards,
Manuel

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Unchanged transient field received as null on server using RequestFactory - how to force to send?

[TimOnGmail]

Ok - our code has a default finder used generically for all calls, though 
some locators override it.  I hadn't been very aware of it - it was this 
that was causing the issue.

Once I overrode the finder to fill in transient values, my problems went 
away.

Thanks for pointing me in the right direction!

- Tim

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Unchanged transient field received as null on server using RequestFactory - how to force to send?

[TimOnGmail]

Ah, ok - I didn't realize that I was able to provide my own modification of 
the locator method.  In my debugging of our code, I saw the RF framework do 
a direct to an EntityManager.find() method.  For some reason I didn't see 
that this was something we could modify.  I also wasn't aware of @PostLoad. 
 I'll look into both of those then, thanks!

- Tim

On Thursday, October 27, 2016 at 2:36:54 PM UTC-7, Jens wrote:
>
>
>  But when RF looks up the current value to compare, it will always be null 
>> because the regular lookup doesn't set the transient value.
>>
>
> RF expects a correctly filled entity after loading it from the DB using 
> the entity locator methods (because RF only sends changed data). It's your 
> job to provide a correctly filled entity. You must update your entity 
> locator method to fill the @Transient field or you have to use JPA 
> @PostLoad to "automatically" fill the @Transient field once the entity has 
> been loaded from DB.
>
> Otherwise use a ValueProxy as it does not has a DB identity and thus all 
> values will be send by the client.
>
> -- J.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Unchanged transient field received as null on server using RequestFactory - how to force to send?

[Jens]

>  But when RF looks up the current value to compare, it will always be null 
> because the regular lookup doesn't set the transient value.
>

RF expects a correctly filled entity after loading it from the DB using the 
entity locator methods (because RF only sends changed data). It's your job 
to provide a correctly filled entity. You must update your entity locator 
method to fill the @Transient field or you have to use JPA @PostLoad to 
"automatically" fill the @Transient field once the entity has been loaded 
from DB.

Otherwise use a ValueProxy as it does not has a DB identity and thus all 
values will be send by the client.

-- J.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Unchanged transient field received as null on server using RequestFactory - how to force to send?

[TimOnGmail]

... or maybe an improvement, whereby fields marked @Transient would always 
be sent, and not use the usual lookup/compare workflow?

I'm surprised it works the way it does - when the original value is 
fetched, we set the @Transient values when returned to the client.  But 
when RF looks up the current value to compare, it will always be null 
because the regular lookup doesn't set the transient value.  So it would be 
comparing null to the value the client currently has - why wouldn't that 
cause it to send the value?  Or, I guess, the value is compared on the 
server, and since the client perceives that the value hasn't changed, it's 
comparing (null == null), I guess that's it, eh?

Anyway, some way to force it to send a value would be nice.

- Tim

On Wednesday, October 26, 2016 at 10:59:43 PM UTC-7, Thomas Broyer wrote:
>
> Assuming an EntityProxy here, if the field is left unchanged, then it's 
> not sent to the server. On the server side, the entity is loaded by the 
> Locator and then the diff is applied. So if the Locator gets a null field, 
> it'll be left null. 
> You may have to use a ValueProxy here…

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Unchanged transient field received as null on server using RequestFactory - how to force to send?

[TimOnGmail]

Sorry, yes, it was an EntityProxy.

My ideas to solve it were:

1) Use a ValueProxy instead of an EntityProxy
2) Use a ValueProxy for the @Transient String value (dunno how a transient 
value, expressed as a ValueProxy within an EntityProxy, would be handled, 
or if it's allowed)
3) Pass the changing/unchanging value as a separate String argument in the 
RF call
4) Intuit it is unchanged BECAUSE it is null, since the client always sets 
it to something, but never to null

I think #3 is the easiest in this case.

Is there any possibility that, in future releases (we're one release behind 
current), an individual field in a proxy can be set to 'changed'?  That is, 
override the default returned by isChanged()?  I think that could be very 
useful, and I don't see it as causing any hiccups in the way things already 
work.

- Tim

On Wednesday, October 26, 2016 at 10:59:43 PM UTC-7, Thomas Broyer wrote:
>
> Assuming an EntityProxy here, if the field is left unchanged, then it's 
> not sent to the server. On the server side, the entity is loaded by the 
> Locator and then the diff is applied. So if the Locator gets a null field, 
> it'll be left null. 
> You may have to use a ValueProxy here…

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Unchanged transient field received as null on server using RequestFactory - how to force to send?

[Thomas Broyer]

Assuming an EntityProxy here, if the field is left unchanged, then it's not 
sent to the server. On the server side, the entity is loaded by the Locator and 
then the diff is applied. So if the Locator gets a null field, it'll be left 
null.
You may have to use a ValueProxy here…

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Unchanged transient field received as null on server using RequestFactory - how to force to send?

[TimOnGmail]

Hi all...

So I have a situation where we have an entity persisted with JPA on the 
server:

public class MyEntity ... {
> private String field1;
> private String field2;
> @Transient
> private String myTransientField;
> }


... and we have a proxy:

public class MyEntityProxy ... {
> public String getField1();
> public void setField1(String field1);
> public String getField2();
> public void setField2(String field2);
> public String getMyTransientField();
> public void setMyTransientField(String myTransientField);
> }


When I first make a call to the server to persist the entity, it works fine.

However, if I load it to edit it, and don't change myTransientField, 
myTransientField arrives on the server as a null value.

I had *thought* I had this working in the past, but for some reason I see 
it breaking now.

Is this the way it's supposed to work? (since the field hasn't changed, or 
because it's transient, or both)

If so, how can I get around this restriction, and force that field to be 
dirty, even if it is unchanged?

- Tim

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Specify earlier dated version of requestfactory-server-2.8.0-SNAPSHOT with Maven

[Seth]

Hi Thomas,

Thanks so much. I thought that the timestamped snapshot would be available 
if it was listed, this is probably why it wasn't working for me when I 
tried with the specific earlier version. I ran into the maven-shade-plugin 
too, looks like it's a nice option. Thanks for the details on the approach. 
I'm guessing your fix will be in the snapshot soon, so will definitely test 
it out to confirm that it fixed the issue.

Thanks again.

On Thursday, May 5, 2016 at 7:18:04 AM UTC-4, Thomas Broyer wrote:
>
>
>
> On Thursday, May 5, 2016 at 11:34:34 AM UTC+2, Thomas Broyer wrote:
>>
>>
>>
>> On Wednesday, May 4, 2016 at 8:46:03 PM UTC+2, Seth wrote:
>>>
>>> Hi all,
>>>
>>>
>>> After some jar hell, I figured out that the 
>>> requestfactory-server-2.8.0-SNAPSHOT 
>>> after March 20, 2016 (or so) seems to be including some Gson classes 
>>> (and it doesn't seem to use a dependency). These Gson classes are 
>>> causing some classpath problems with another dependency that depends on 
>>> Gson 2.2.4 release resulting in some not-so-nice NoClassDefFound 
>>> exceptions.
>>>
>>
>> Thanks for the report, I'll get it fixed.
>> FWIW, it was introduced on April 6th: 
>> https://github.com/gwtproject/gwt/commit/21e557ee56e257bc4af1b1b637f5ba5d775a56dd
>>
>
> Proposed fix: https://gwt-review.googlesource.com/14790 (needs testing)
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Specify earlier dated version of requestfactory-server-2.8.0-SNAPSHOT with Maven

[Thomas Broyer]

On Thursday, May 5, 2016 at 11:34:34 AM UTC+2, Thomas Broyer wrote:
>
>
>
> On Wednesday, May 4, 2016 at 8:46:03 PM UTC+2, Seth wrote:
>>
>> Hi all,
>>
>>
>> After some jar hell, I figured out that the 
>> requestfactory-server-2.8.0-SNAPSHOT 
>> after March 20, 2016 (or so) seems to be including some Gson classes 
>> (and it doesn't seem to use a dependency). These Gson classes are 
>> causing some classpath problems with another dependency that depends on 
>> Gson 2.2.4 release resulting in some not-so-nice NoClassDefFound 
>> exceptions.
>>
>
> Thanks for the report, I'll get it fixed.
> FWIW, it was introduced on April 6th: 
> https://github.com/gwtproject/gwt/commit/21e557ee56e257bc4af1b1b637f5ba5d775a56dd
>

Proposed fix: https://gwt-review.googlesource.com/14790 (needs testing)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Specify earlier dated version of requestfactory-server-2.8.0-SNAPSHOT with Maven

[Thomas Broyer]

On Wednesday, May 4, 2016 at 8:46:03 PM UTC+2, Seth wrote:
>
> Hi all,
>
>
> After some jar hell, I figured out that the 
> requestfactory-server-2.8.0-SNAPSHOT 
> after March 20, 2016 (or so) seems to be including some Gson classes (and 
> it doesn't seem to use a dependency). These Gson classes are causing some 
> classpath problems with another dependency that depends on Gson 2.2.4 
> release resulting in some not-so-nice NoClassDefFound exceptions.
>

Thanks for the report, I'll get it fixed.
FWIW, it was introduced on April 
6th: 
https://github.com/gwtproject/gwt/commit/21e557ee56e257bc4af1b1b637f5ba5d775a56dd
 

> The only remedy I found was to replace the 
> requestfactory-server-2.8.0-SNAPSHOT 
> maven includes with a version from March 20, 2016 (or earlier). 
>
>
> Does anyone know how to specify a more detailed version for the 
> requestfactory-server-2.8.0-SNAPSHOT  so that Maven will just build with 
> the snapshot version from March 20, 2016?
>

You should be able to specify a timestamped version, e.g. 
2.8.0-20160502.055217-237 for May, 5th build; but beware that older 
snapshots are regularly deleted.
(see 
https://oss.sonatype.org/content/repositories/google-snapshots/com/google/web/bindery/requestfactory-server/2.8.0-SNAPSHOT/
 
for available versions; unfortunately, while the history might look big, 
only signatures are kept –for some reason, probably a bug in the cleanup 
task on Sonatype's side– for older snapshots, and you won't find builds as 
old as the one you'd like)
 

> I understand that SNAPSHOT means latest and there's a beta1, but the 2.8 
> beta1 is almost 6 months old now. And it seems as though it will be much 
> harder to get an actual Gson dependency for requestfactory-server (or to 
> resolve the class duplication) in the short term.
>

Your best short-term bets are to either:

   - build a version yourself that you deploy into your own repo, with a 
   non-snapshot version (e.g. 2.8.0-seth-20160405-g5d64514)
   - pre-process the snapshot JAR to remove the offending classes: use a 
   Maven module that depends on the snapshot jar (with scope=provided) and 
   repacks it without the offending classes (might be possible and easy with 
   the maven-shade-plugin); then have your app depends on that module instead 
   of the snapshot.

 

>
> Many thanks in advance,
>
>
> -Seth
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Specify earlier dated version of requestfactory-server-2.8.0-SNAPSHOT with Maven

[Seth]

 

Hi all,


After some jar hell, I figured out that the 
requestfactory-server-2.8.0-SNAPSHOT 
after March 20, 2016 (or so) seems to be including some Gson classes (and 
it doesn't seem to use a dependency). These Gson classes are causing some 
classpath problems with another dependency that depends on Gson 2.2.4 
release resulting in some not-so-nice NoClassDefFound exceptions.


The only remedy I found was to replace the requestfactory-server-2.8.0-SNAPSHOT 
maven includes with a version from March 20, 2016 (or earlier). 


Does anyone know how to specify a more detailed version for the 
requestfactory-server-2.8.0-SNAPSHOT  so that Maven will just build with 
the snapshot version from March 20, 2016?


I understand that SNAPSHOT means latest and there's a beta1, but the 2.8 
beta1 is almost 6 months old now. And it seems as though it will be much 
harder to get an actual Gson dependency for requestfactory-server (or to 
resolve the class duplication) in the short term.


Many thanks in advance,


-Seth

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Specify version of requestfactory-server-2.8.0-SNAPSHOT to early with Maven

[Seth]

Hi all,

After some jar hell, I figured out that the 
requestfactory-server-2.8.0-SNAPSHOT after March 20, 2016 (or so) seems to 
be including some Gson classes (and it doesn't seem to use a dependency). 
These Gson classes are causing some classpath problems with another 
dependency that depends on Gson 2.2.4 release resulting in some not-so-nice 
NoClassDefFound exceptions.

The only remedy I found was to replace the 
requestfactory-server-2.8.0-SNAPSHOT maven includes with a version from 
March 20, 2016 (or earlier). 

Does anyone know how to specify a more detailed version for the 
requestfactory-server-2.8.0-SNAPSHOT  so that Maven will just build with 
the snapshot version from March 20, 2016?

I understand that SNAPSHOT means latest and there's a beta1, but the 2.8 
beta1 is almost 6 months old now. And it seems as though it will be much 
harder to get an actual Gson dependency for requestfactory-server (or to 
resolve the class duplication) in the short term.

Many thanks in advance,

-Seth

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: com.google.web.bindery.requestfactory.shared.impl.Constants missing in both requestfactory-client and requestfactory-server

['Dirk Holzenburg' via GWT Users]

Thank you Thomas for the explanation

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: com.google.web.bindery.requestfactory.shared.impl.Constants missing in both requestfactory-client and requestfactory-server

[Thomas Broyer]

On Thursday, February 18, 2016 at 8:59:10 PM UTC+1, Dirk Holzenburg wrote:
>
> Hi everyone,
>
> why is com.google.web.bindery.requestfactory.shared.impl.Constants missing 
> in both requestfactory-client.jar and requestfactory-server.jar? Is there 
> any particular reason?
>

Those JARs are extracted from gwt-user.jar using bytecode analysis starting 
from a few key classes. Because constants are inlined by JavaC, I think the 
bytecode analysis never ever walks into the Constants class, so it doesn't 
include it in the JAR.
If you're curious you can see the tool's code 
here 
https://gwt.googlesource.com/gwt/+/2.8.0-beta1/user/src/com/google/web/bindery/requestfactory/server/RequestFactoryJarExtractor.java
 

> And why is com.google.gwt.thirdparty.json.* missing in the source jars? 
> Legal reasons?
>

No, com.google.gwt.thirdparty.json is extracted from the Android SDK so is 
under Apache 2.0. You can find there 
here https://github.com/gwtproject/tools/tree/master/lib/json/android-sdk-19.1
Again, it's mainly a packaging artefact: the sources aren't included in the 
RequestFactoryJarExtractor classpath so they're not seen by the tool and 
cannot be included in the JARs. That being said, even if they were, they 
have not been "rebased" (from org.json to com.google.gwt.thirdparty.json) 
so they wouldn't be found either.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

com.google.web.bindery.requestfactory.shared.impl.Constants missing in both requestfactory-client and requestfactory-server

['Dirk Holzenburg' via GWT Users]

Hi everyone,

why is com.google.web.bindery.requestfactory.shared.impl.Constants missing 
in both requestfactory-client.jar and requestfactory-server.jar? Is there 
any particular reason?

And why is com.google.gwt.thirdparty.json.* missing in the source jars? 
Legal reasons?

Thank you very much in advance!

Dirk

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

RequestFactory Caching with Transaction Failures

[Paul Mazzuca]

What is the best way to deal with objects that still get cached when a 
transaction fails and is rolled back?  

I am running into this with GAE / JDO / GWT RequestFactory.   The 
transaction rightfully fails and rolls back, but then the memcache still 
retains the older values.  The datastore has the correct values, but then 
memcache does not. 

This can also lead to others issues when, for example, if a new object were 
persisted during the transaction. Again the object is cached, however 
because the transaction failed, it is actually not in the datastore 
resulting in a NucleusOptimisticException: "The underlying entity had 
already been deleted." exception.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

RequestFactory Services asJava EE managed Beans

[Pedro Lamarão]

Guys,
after experimenting with subclassing RequestFactoryServlet for a while, I 
devised a new trick to have RequestFactory Services be managed Beans.
It is a simple trick where a ServiceLocator obtains Services from the 
BeanManager.
I'd like to share it with the community.

-- x --
public final class BeanManagerServiceLocator implements ServiceLocator
{
@Override public Object getInstance (Class clazz)
{
return getReference(clazz);
}

public static  T getReference (Class clazz)
{
try
{
InitialContext context = new InitialContext();
BeanManager beanManager = (BeanManager) 
context.lookup("java:comp/BeanManager");
Set<Bean> beans = beanManager.getBeans(clazz);
Bean bean = beanManager.resolve(beans);
CreationalContext creationalContext = 
beanManager.createCreationalContext(bean);
Object object = beanManager.getReference(bean, 
bean.getBeanClass(), creationalContext);
return clazz.cast(object);
}
catch (NamingException e)
{
throw new RuntimeException(e);
}
}
}
-- x --

Thanks!
P.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory, frozen autobeans, and MVP

[Jens]

Have you called requestFactoryEditorDriver.edit(lockedProxyFromServer, 
requestContextUsedForSaving) ?

If you use SimpleBeanEditorDriver you have to do

T editableProxy = requestContextUsedForSaving.edit(lockedProxyFromServer);
simpleBeanEditorDriver.edit(editableProxy);

If the user does not end up saving any changes then you simply do not call 
flush(). I think thats the normal workflow (never really used 
RequestFactory). As you use MVP I would add a factory method to the view to 
create the editor driver since you need to GWT.create() it and you normally 
want to avoid GWT.create() in presenters. 

-- J.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

RequestFactory, frozen autobeans, and MVP

[Steve C]

I'm trying to convert an app from using plain JSON to using 
RequestFactory.  The app has a view and presenter.  So, I use the 
RequestFactory to get Contact instances, and pass them on the view to 
edit.  But, the editing runs into an issue with the AutoBean being frozen.  
Without MVP, I would just open a request, invoke edit and pass the bean, 
and be done.  But, it doesn't seem right to now do that in the view.  And, 
I have an issue with holding a request open just to enable editing the 
bean, when it's conceivable that the user will bail out and not end up 
saving their changes.

So, what would the best flow be for this situation?


-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] [GWT2.8] RequestFactory lambda support

[Manuel Carrasco Moñino]

Hi Kay,

It makes sense to me if it does not break old code, could you take the time
to make those modifications and send a patch?

Thanks
- Manolo

On Tue, Sep 15, 2015 at 3:06 PM, Kay-Uwe Janssen <kujans...@gmail.com>
wrote:

> Hello there,
>
> i wonder if there are plans to allow developers to use lambdas/method
> references for requestfactory.
>
> my idea was that there could be some overloaded versions of
> fire(Receiver) and to(Receiver) that accept 1-3 lamdbas (4 if the
> deprecated onViolation should be supported here too).
>
> e.g
> fire(Receiver) // the original
> fire(SuccessReceiver) // only the success callback
> fire(SuccessReceiver, FailureReceiver) // the success + failure callback
> fire(SuccessReceiver, ConstraintViolationReceiver) // the success +
> ConstraintViolation callback
> fire(SuccessReceiver, FailureReceiver, ConstraintViolationReceiver) //
> the success + failure + ConstraintViolation callback
>
> same for to() of course.
>
> the implementation could be something like: all lambda supporting methods
> call the one with the Receiver parameter with an assembled Receiver that
> forwards its calls to the corresponding lambda.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/b33b86ac-e2e9-4e9d-a6d5-a4efdfa9117e%40googlegroups.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/b33b86ac-e2e9-4e9d-a6d5-a4efdfa9117e%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAshjwuiDq3zcpB7qF15_%2BfUHR6X3P-tFugS9Y8u_9tLUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: [GWT2.8] RequestFactory lambda support

[Jens]

I am pretty sure APIs will be enhanced for better lambda use over time but 
that will probably happen after a 2.8 release. 

Given your concrete example it might be cleaner to let fire() return an 
object that you can use to register callbacks on, similar to a Promise / 
CompletableFuture. That avoids having lots of overloads of the fire() 
method with all kinds of parameter combinations.

IMHO readability also improves with such an object because it communicates 
pretty clearly which request state maps to which lambda, e.g. 
updatingPerson.*onSuccess*(), 
updatingPerson.*onConstraintViolation*(). 
Also you can pass around that instance which can be beneficial and, if 
supported, possibly attach N callbacks to one request state.


-- J.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/4d40216a-204e-4e77-83a1-d8a00e539eea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] [GWT2.8] RequestFactory lambda support

[Kay-Uwe Janssen]

Hello there,

i wonder if there are plans to allow developers to use lambdas/method 
references for requestfactory.

my idea was that there could be some overloaded versions of 
fire(Receiver) and to(Receiver) that accept 1-3 lamdbas (4 if the 
deprecated onViolation should be supported here too).

e.g
fire(Receiver) // the original
fire(SuccessReceiver) // only the success callback
fire(SuccessReceiver, FailureReceiver) // the success + failure callback
fire(SuccessReceiver, ConstraintViolationReceiver) // the success + 
ConstraintViolation callback
fire(SuccessReceiver, FailureReceiver, ConstraintViolationReceiver) // 
the success + failure + ConstraintViolation callback

same for to() of course.

the implementation could be something like: all lambda supporting methods 
call the one with the Receiver parameter with an assembled Receiver that 
forwards its calls to the corresponding lambda.


-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/b33b86ac-e2e9-4e9d-a6d5-a4efdfa9117e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RequestFactory - update entity

[Manuel]

Hi everyone,

Im using the requestFactory and want to update an entity. The problem is, 
its frozen.

I get an entityProxy passed, were I like to update 1 value. The problem is, 
when I try to edit it with a new Request, it fails, cause the proxy is 
frozen.

I found this: 
http://stackoverflow.com/questions/7479779/gwt-autobean-frozen-when-saving-graph

It says, I got to get a new entityProxy from the server.

This would take 1 request to receive a fresh entityProxy and another for 
the update... I was wondering, if there is a better way to do this? Or 
whats the proper way to update a entity with just 1 request?
Is there a way to actually create a new entityProxy on the client that 
updates an existing entity without loading it from the server?

Thats what I tried:
   PersonRequest request = AppManager.getRequestFactory().
personRequest();
   PersonProxy proxy = request.create(PersonProxy.class);

   
   proxy.setSalary(0);
   proxy.setId(object.getId()); // Copy values of passed object
   proxy.setVersion(object.getVersion());   
   
   request.persist(proxy).fire(new ReceiverPersonProxy() 


Copy all values ends in hibernate Exception for detached entity passed to 
persist.

Thanks in advance.

Regards

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory - update entity

[Thomas Broyer]

The first question that comes to mind is: where does 'object' come from? 
(and why is it frozen)

On Monday, August 24, 2015 at 9:10:30 PM UTC+2, Manuel wrote:

 Hi everyone,

 Im using the requestFactory and want to update an entity. The problem is, 
 its frozen.

 I get an entityProxy passed, were I like to update 1 value. The problem 
 is, when I try to edit it with a new Request, it fails, cause the proxy is 
 frozen.

 I found this: 
 http://stackoverflow.com/questions/7479779/gwt-autobean-frozen-when-saving-graph

 It says, I got to get a new entityProxy from the server.

 This would take 1 request to receive a fresh entityProxy and another for 
 the update... I was wondering, if there is a better way to do this? Or 
 whats the proper way to update a entity with just 1 request?
 Is there a way to actually create a new entityProxy on the client that 
 updates an existing entity without loading it from the server?

 Thats what I tried:
PersonRequest request = AppManager.getRequestFactory().
 personRequest();
PersonProxy proxy = request.create(PersonProxy.class);


proxy.setSalary(0);
proxy.setId(object.getId()); // Copy values of passed 
 object
proxy.setVersion(object.getVersion());   

request.persist(proxy).fire(new ReceiverPersonProxy() 


 Copy all values ends in hibernate Exception for detached entity passed to 
 persist.

 Thanks in advance.

 Regards


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory - update entity

[Manuel]

The following solved my problem:

request = AppManager.getRequestFactory().personRequest(); 
*object = request.edit(object);* //object is the Proxy passed to me
// *request.edit(object);* // instead of this...

Actually edit(object) returns a new mutable version of the entityProxy, 
that can be worked with. Changing values and persisting did not cause 
exceptions anymore.

Am Montag, 24. August 2015 21:10:30 UTC+2 schrieb Manuel:

 Hi everyone,

 Im using the requestFactory and want to update an entity. The problem is, 
 its frozen.

 I get an entityProxy passed, were I like to update 1 value. The problem 
 is, when I try to edit it with a new Request, it fails, cause the proxy is 
 frozen.

 I found this: 
 http://stackoverflow.com/questions/7479779/gwt-autobean-frozen-when-saving-graph

 It says, I got to get a new entityProxy from the server.

 This would take 1 request to receive a fresh entityProxy and another for 
 the update... I was wondering, if there is a better way to do this? Or 
 whats the proper way to update a entity with just 1 request?
 Is there a way to actually create a new entityProxy on the client that 
 updates an existing entity without loading it from the server?

 Thats what I tried:
PersonRequest request = AppManager.getRequestFactory().
 personRequest();
PersonProxy proxy = request.create(PersonProxy.class);


proxy.setSalary(0);
proxy.setId(object.getId()); // Copy values of passed 
 object
proxy.setVersion(object.getVersion());   

request.persist(proxy).fire(new ReceiverPersonProxy() 


 Copy all values ends in hibernate Exception for detached entity passed to 
 persist.

 Thanks in advance.

 Regards


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

RequestFactory: String not a transportable type?

[Stephan Windmüller]

Hello,

according to the documentation 
http://www.gwtproject.org/doc/latest/DevGuideRequestFactory.html#transportable
 
of RequestFactory, the String class is not defined as a transportable type. 
However, the example code above uses String both as paramaters and return 
values. Is this an error in the documentation or did I understand something 
wrong?

Additionally, the anchor when clicking on Transportable types in the TOC 
does not work.

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory: String not a transportable type?

[Jens]

Its a documentation issue. The Other value types row should also contain 
String. 

-- J.

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory: String not a transportable type?

[Stephan Windmüller]

Thank you for the confirmation!

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Can an interface serve as proxy for more than one class in RequestFactory?

[Thomas Broyer]

On Sunday, June 21, 2015 at 9:29:01 PM UTC+2, Aldo wrote:

 HI,

 I know this is an old thread, but I'm having a similar problem.

 I have a class A that is an entity on my server side and a class B that 
 extends A (with PrimaryKeyJoinColumn). So, in other words I have:

 @Entity
 @Inheritance(strategy=InheritanceType.JOINED)
 public class A {
 ...
 }

 @Entity
 @PrimaryKeyJoinColumn(name=a_id, referencedColumnName=id)
 public class B extends A {
 ...
 }

 I already have A extending EntityProxy:

 @ProxyFor(A.class)
 public interface AProxy extends EntityProxy {
 ...
 }

 And now I need to map B as an Entity Proxy as well, but I'm getting an 
 exception. What I did is:

 @ProxyFor(B.class)
 public interface BProxy extends AProxy, EntityProxy {
 ...
 }

 but I get the following exception:


 *BProxy is not an EntityProxy typeat 
 com.google.web.bindery.requestfactory.shared.impl.IdFactory.asEntityProxy(IdFactory.java:66)*

 Is it possible to do what I'm trying here? If so, how?


Assuming you get that error on the client side, it actually means that your 
RequestFactory doesn't know about BProxy.
BProxy has to be referenced from a RequestContext or another 
EntityProxy/ValueProxy transitively referenced from your RequestFactory 
interface.
You might have to annotate one of your RequestContext or proxy with 
@ExtraTypes(BProxy.class).
See 
http://www.gwtproject.org/doc/latest/DevGuideRequestFactory.html#transportable 
(search for ExtraTypes there) 

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Can an interface serve as proxy for more than one class in RequestFactory?

[Aldo Neto]

HI,

I know this is an old thread, but I'm having a similar problem.

I have a class A that is an entity on my server side and a class B that
extends A (with PrimaryKeyJoinColumn). So, in other words I have:

@Entity
@Inheritance(strategy=InheritanceType.JOINED)
public class A {
...
}

@Entity
@PrimaryKeyJoinColumn(name=a_id, referencedColumnName=id)
public class B extends A {
...
}

I already have A extending EntityProxy:

@ProxyFor(A.class)
public interface AProxy extends EntityProxy {
...
}

And now I need to map B as an Entity Proxy as well, but I'm getting an
exception. What I did is:

@ProxyFor(B.class)
public interface BProxy extends AProxy, EntityProxy {
...
}

but I get the following exception:


*BProxy is not an EntityProxy typeat
com.google.web.bindery.requestfactory.shared.impl.IdFactory.asEntityProxy(IdFactory.java:66)*

Is it possible to do what I'm trying here? If so, how?

Thanks,
Aldo


On Mon, Jun 27, 2011 at 12:48 PM, Ryan McFall mcfall.r...@gmail.com wrote:

 Thanks for the reply.  I think you're right that there's no great
 solution to my problem.

 I've got it solved at the moment by creating a client side interface,
 and wrapper classes for the two proxies that both implement that
 client-side interface (basically mimicking the functionality of the
 common server interface).  I don't like it, but it seems to be
 working.

 Ryan

 On Jun 27, 10:00 am, Thomas Broyer t.bro...@gmail.com wrote:
  On Monday, June 27, 2011 12:40:05 PM UTC+2, Ryan McFall wrote:
 
   I have two domain objects that implement the same interface on the
   server, and a third class that contains a (heterogeneous) List of
   those objects.  I need to be able to expose this list on the client
   side.  The domain objects do not share a common super-class (they
   instead delegate the common functionality to another object).
 
   Given that all proxy interfaces are required to extend BaseProxy, I
   cannot figure out how to write multiple proxies that will have a
   parent interface in common.  I tried making a base interface that both
   proxies extend, but that base interface must extend EntityProxy, and
   the GWT compiler complains if you have an interface that extends
   EntityProxy but does not have a ProxyFor annotation.
 
  The interface need not extend EntityProxy, you can have:
  interface BaseInterface { ... }
  interface FooProxy extends BaseInterface, EntityProxy { }
  interface BarProxy extends BaseInterface, EntityProxy { }
 
  ...but then you obviously cannot have a proxy declare a list that contain
  both FooProxy and BarProxy, as a CollectionBaseInterface would be
 rejected
  because BaseInterface doesn't extend EntityProxy or ValueProxy.
 
  BUT!
 
 - The hierarchy of proxy interfaces need not mimic the one of domain
 objects on the server-side. You could have interface BarProxy extends
 FooProxy for example.
 - or, because you can have more than one proxy interface for the same
 domain object, you could annotate the base interface with a @ProxyFor
 for
 one of the domain class.
 
  I am wondering (although I suspect the answer is no) whether I can
 
   have a single interface declare that it is a proxy for multiple
   entities.  If not, other ideas for making this work are welcome.
 
  You're right: an interface can only map to a single domain class.
 Moreover,
  you cannot use an interface in a @ProxyFor, as the
  RequestFactoryInterfaceValidator used by the RequestFactoryServlet will
  ultimately flag it as an error (so you unfortunately cannot use the
  interface implemented by both your domain objects).
 
  RequestFactory does not (yet
 http://code.google.com/p/google-web-toolkit/issues/detail?id=5367)
  support polymorphism, so your collection can only ever contain a single
  interface.
 
  Not sure there's a solution to your problem besides refactoring your
 domain
  classes (but maybe if you share a bit more information, maybe there's a
  solution)

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.



-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Can an interface serve as proxy for more than one class in RequestFactory?

[Aldo Neto]

Thank you for your reply. It solved the issue.

Now I'm struggling with the editor part. I don't know how to implement the
editor so it can work with both classes A and B (where B extends A). I'd
like to use a TabPanel and display A in one tab and B in the other one, but
I'm having trouble with shared fields. In other words, once B has the same
fields as A (plus some others), how can I have two boxes with same name in
both tabs? Is there a way to use editor in this scenario?

Once again, thanks for your quick response.

Aldo


On Sun, Jun 21, 2015 at 6:31 PM, Thomas Broyer t.bro...@gmail.com wrote:



 On Sunday, June 21, 2015 at 9:29:01 PM UTC+2, Aldo wrote:

 HI,

 I know this is an old thread, but I'm having a similar problem.

 I have a class A that is an entity on my server side and a class B that
 extends A (with PrimaryKeyJoinColumn). So, in other words I have:

 @Entity
 @Inheritance(strategy=InheritanceType.JOINED)
 public class A {
 ...
 }

 @Entity
 @PrimaryKeyJoinColumn(name=a_id, referencedColumnName=id)
 public class B extends A {
 ...
 }

 I already have A extending EntityProxy:

 @ProxyFor(A.class)
 public interface AProxy extends EntityProxy {
 ...
 }

 And now I need to map B as an Entity Proxy as well, but I'm getting an
 exception. What I did is:

 @ProxyFor(B.class)
 public interface BProxy extends AProxy, EntityProxy {
 ...
 }

 but I get the following exception:


 *BProxy is not an EntityProxy typeat
 com.google.web.bindery.requestfactory.shared.impl.IdFactory.asEntityProxy(IdFactory.java:66)*

 Is it possible to do what I'm trying here? If so, how?


 Assuming you get that error on the client side, it actually means that
 your RequestFactory doesn't know about BProxy.
 BProxy has to be referenced from a RequestContext or another
 EntityProxy/ValueProxy transitively referenced from your RequestFactory
 interface.
 You might have to annotate one of your RequestContext or proxy with
 @ExtraTypes(BProxy.class).
 See
 http://www.gwtproject.org/doc/latest/DevGuideRequestFactory.html#transportable
 (search for ExtraTypes there)

 --
 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 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.7.0 RequestFactory + Spring + JPA + Hibernate optimistic locking implementation

[Anton Mityagin]

Yeah, i see. You implement manual version control in your project.

But, I decided to use RF in my project to forget about transmission domain 
objects between server and client.

In general, it is unclear why the guys at Google have made the RF this way.


On Wednesday, June 10, 2015 at 2:51:48 AM UTC+3, Jens wrote:

 We don't use RequestFactory but GWT-RPC with Eclipselink + optimistic 
 locking and heavy auto saving. Because we don't want to live with the extra 
 query when doing the em.find / detach / update version / merge dance we 
 simply do the version check manually in the app. Also we don't send 
 versions to the client, we keep track of them on the server only.

 On server side we have a class called EntityVersionStore and each user 
 session has exactly one instance of it. This store is transactional just 
 like the EntityManager so you can do EVS.beginTransaction() / rollback() / 
 flush() / commit(). Then we have a EVS.remember(Entity) method that can 
 only be called within an active transaction and simply stores the current 
 entity version inside an internal map. 
 To do the optimistic lock checking we have EVS.checkVersion(Entity) which 
 compares the current entity version against the version that has been 
 flushed() or committed() to the store previously. Finally we have @PostLoad 
 and @PostUpdate hooks in a base entity that simply call EVS.remember(this) 
 whenever an entity is loaded from DB or saved to DB.

 So when a request reaches the server the overall workflow is

 1. entityManager.beginTransaction()
 2. evs.beginTransaction()
 3. dispatch command to a handler (we use command pattern)
 4. Inside the handler we load entities which causes the @PostLoad hook of 
 those entities to be executed (evs.remember(this))
 5. Manually compare versions via evs.checkVersion(entityToEdit). As 
 checkVersion() only works on flushed/committed data the version remembered 
 in 4. is not used. Instead the version of any previous request is used as 
 that data is committed.
 6. If version checks passes continue modifying the entities and save them 
 to DB
 7. entityManager. commit()
 8. @PostUpdate hook executes for all updated entities and EVS will be 
 updated just like in 4.
 9. evs.commit() to make all the remembered versions of that current 
 request committed so that the next request can use that information when 
 calling checkVersion.


 Works pretty transparent for us, as the only thing we need to do is to 
 call evs.checkVersion() before updating an entity. And with some abstract 
 handlers for common tasks like saving one entity we don't even have to call 
 evs.checkVersion() as the abstract handler does this for us.


 -- J.


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.7.0 RequestFactory + Spring + JPA + Hibernate optimistic locking implementation

[Thomas Broyer]

On Wednesday, June 10, 2015 at 12:21:03 PM UTC+2, Anton Mityagin wrote:

 In general, it is unclear why the guys at Google have made the RF this way.


If you look at the changes between the various milestones and RCs of GWT 
2.1, and then 2.1.1 and 2.2, you'll see that RF is totally different today 
than it was initially conceived (TL;DR: started as just CRUD  keeping the 
client and server entities in sync, evolved into RPC).
Unfortunately, some early design decisions have slept in, making things a 
bit blurry about what RF is best at.
I also believe the partnership with Spring Roo at the time wasn't for the 
better (and it didn't last long, I'm not even sure it lived 'til the 2.1 
final release).
But there are many things RF does quite well: RPC (with ValueProxy), 
“patching” entities in client→server communications (but without optimistic 
locking), batching (soon to be obsoleted by HTTP/2 though), support for 
non-XHR transports (e.g. WebSocket, though I haven't seen any such 
implementation), support for non-GWT environments, and the lose coupling 
between client and server making it a valid choice for e.g. mobile 
(Android) or offline-capable apps, where the client is hard to keep in sync 
with the server.

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.7.0 RequestFactory + Spring + JPA + Hibernate optimistic locking implementation

[Anton Mityagin]

Undoubtedly, RF - greate thing. I use it and plan to continue to use.

The more that I get to make workaround for those things that do not exist 
in RF.

Just very strange that such a good thing as RF does not support such basic 
things like optimistic locking, refire request after excpetion.

And everyone who face a shortage of such things must reinvent their own 
wheel

On Wednesday, June 10, 2015 at 3:53:02 PM UTC+3, Thomas Broyer wrote:



 On Wednesday, June 10, 2015 at 12:21:03 PM UTC+2, Anton Mityagin wrote:

 In general, it is unclear why the guys at Google have made the RF this 
 way.


 If you look at the changes between the various milestones and RCs of GWT 
 2.1, and then 2.1.1 and 2.2, you'll see that RF is totally different today 
 than it was initially conceived (TL;DR: started as just CRUD  keeping the 
 client and server entities in sync, evolved into RPC).
 Unfortunately, some early design decisions have slept in, making things a 
 bit blurry about what RF is best at.
 I also believe the partnership with Spring Roo at the time wasn't for 
 the better (and it didn't last long, I'm not even sure it lived 'til the 
 2.1 final release).
 But there are many things RF does quite well: RPC (with ValueProxy), 
 “patching” entities in client→server communications (but without optimistic 
 locking), batching (soon to be obsoleted by HTTP/2 though), support for 
 non-XHR transports (e.g. WebSocket, though I haven't seen any such 
 implementation), support for non-GWT environments, and the lose coupling 
 between client and server making it a valid choice for e.g. mobile 
 (Android) or offline-capable apps, where the client is hard to keep in sync 
 with the server.



-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.7.0 RequestFactory + Spring + JPA + Hibernate optimistic locking implementation

[Ignacio Baca Moreno-Torres]

We made a similar approach using the client/server version variables. But 
we call it version/expectedVersion.
class MyEntity {
 @Version int version;
 public int getExpectedVersion() { return null; }
 public void setExpectedVersion(int v) { this.version = v; }
 public int getVersion() { return version; } 
  // public void setVersion() {} // not required/recomended
}
As explained in stackoverflow 
http://www.google.com/url?q=http%3A%2F%2Fstackoverflow.com%2Fquestions%2F7696764%2Fdoes-gwt-requestfactory-support-implementation-of-optimistic-concurrency-control%2F7697307%237697307sa=Dsntz=1usg=AFQjCNEjQwYbtnsepzEPUD0X1zeqCT3jAg
 RF 
only sent changes, this forces to have an always-null expectedVersion and 
manually copy the getVersion to setExpectedVersion to enable optimistic 
locking. BUT! it's critical that the entity be detached when you set the 
version (or you detach and merge) because if you set the version on an 
attached entity the version is not checked (at least in hibernate).

OTOH, RF only sent changes to the server so optimistic locking is not 
required most of the time. Just for curiosity, why you need optimistic 
locking?

Usually only some operation requires fully transactional/optimistic locking 
and in our experience, this operations are better handled using some kind 
of command pattern. I.e. sent how-to-update instead of what-to-set. We used 
the optimistic locking approach initially because we try to use 
RF/Entities/Proxies for everything, but now we use commands for this 
situations and versions are not required anymore. Moreover, RF has a 
problem when you try to repeat an operation (which is a good idea in 
optimistic locking), because if the server side fails in the operations 
phase (after validation phase) the client entity gets invalidated, and you 
can't sent the entity again.




 

On Monday, June 8, 2015 at 11:11:41 PM UTC+2, Anton Mityagin wrote:


 As all you know RequestFactory does not support optimistic locking.

 see details 
 https://code.google.com/p/google-web-toolkit/issues/detail?id=6046

 I tried to implement it для RequestFactory + Spring + JPA + Hibernate

 I took as a basis the idea proposed by Thomas (
 http://stackoverflow.com/questions/7696764/does-gwt-requestfactory-support-implementation-of-optimistic-concurrency-control/7697307#7697307
 ).

 As he wrote his idea - pure theory.

 @ProxyFor(MyEntity.class)
 interface MyEntityProxy extends EntityProxy {
String getServerVersion();
String getClientVersion();
void setClientVersion(String clientVersion);
…
 }

 @Entity
 class MyEntity {
private String clientVersion;
@Version private String serverVersion;

public String getServerVersion() { return serverVersion; }
public String getClientVersion() { return null; }
public void setClientVersion(String clientVersion) {
   this.clientVersion = clientVersion;
}

public void patchVersion() {
   serverVersion = clientVersion;
}

public void shouldPatchVersion() {
   return Objects.equal(serverVersion, clientVersion);
}
 }

 On the server-side we need to use somthing like this to edit MyEntityProxy
  
 public P extends BaseProxy P edit(P proxy, RequestContext request)
 {
   P mutableProxy = request.edit(proxy);
   
   if (mutableProxy instanceof MyEntityProxy)
   {
 MyEntityProxy myProxy = (MyEntityProxy)mutableProxy;
 myProxy.setClientVersion(myProxy.getServerVersion());
   }
 }

 On the server-side we need to handle case when clientVersion not equals to 
 serverVersion.

 I think that if we use EntityManager, we do not have to manually throw an 
 exception when the versions are not equal.
 It has to do EntityManager when it tries to save domain object in the 
 database. Otherwise a situation may arise when 
 an object has been checked, but has not been saved to the database, and 
 someone else has save the same object.

 I think a good place to make check and patch server version right before 
 validating the domain object.
 ServiceLayerDecorator
 public T SetConstraintViolationT validate(T domainObject)

 Unfortunately, not enough simply call MyEntity.patchVersion()
 JPA provider uses internal structures to keep current version of maanged 
 object.
 And value of serverVersion does not actually play any role.

 We need to use specific JPA provider's API to change a version of managed 
 object.

 In my case it's Hibernate:

 @Override
 public T SetConstraintViolationT validate(T domainObject)
 {
   
   if (domainObject != null  domainObject instanceof HasVersion?)
   {
 MyEntity version = (MyEntity)domainObject;
 
 if (!version.*shouldPatchVersion*())
 {
   ApplicationContext context = 
 ApplicationContextHolderLocator.getHolder().getApplicationContext();
   EntityManager entityManager = context.getBean(EntityManager.class);
   
   if (entityManager.getDelegate() instanceof SessionImplementor)
   {
 SessionImplementor sess

Re: GWT 2.7.0 RequestFactory + Spring + JPA + Hibernate optimistic locking implementation

[Anton Mityagin]

Thanks for your comment

On Tuesday, June 9, 2015 at 10:12:10 PM UTC+3, Ignacio Baca Moreno-Torres 
wrote:

 We made a similar approach using the client/server version variables. But 
 we call it version/expectedVersion.

 As explained in stackoverflow 
 http://www.google.com/url?q=http%3A%2F%2Fstackoverflow.com%2Fquestions%2F7696764%2Fdoes-gwt-requestfactory-support-implementation-of-optimistic-concurrency-control%2F7697307%237697307sa=Dsntz=1usg=AFQjCNEjQwYbtnsepzEPUD0X1zeqCT3jAg
  RF 
 only sent changes, this forces to have an always-null expectedVersion and 
 manually copy the getVersion to setExpectedVersion to enable optimistic 
 locking. BUT! it's critical that the entity be detached when you set the 
 version (or you detach and merge) because if you set the version on an 
 attached entity the version is not checked (at least in hibernate).

 Yes, I know about detached entity and setting version to it, in the end of 
my post I pointed this thing, and I pointed how to set version to attached 
entity (managed by hibernate).
 

 OTOH, RF only sent changes to the server so optimistic locking is not 
 required most of the time. Just for curiosity, why you need optimistic 
 locking?


Because there is a possibility conflict while saving data and users dont 
want to lose their data or overrite someone else's data.


 Usually only some operation requires fully transactional/optimistic 
 locking and in our experience, this operations are better handled using 
 some kind of command pattern. I.e. sent how-to-update instead of 
 what-to-set. We used the optimistic locking approach initially because we 
 try to use RF/Entities/Proxies for everything, but now we use commands for 
 this situations and versions are not required anymore. Moreover, RF has a 
 problem when you try to repeat an operation (which is a good idea in 
 optimistic locking), because if the server side fails in the operations 
 phase (after validation phase) the client entity gets invalidated, and you 
 can't sent the entity again.

 Yes, I know about this problem.
I have workaround it.
Now I test it and I you wish I'll post it here

In short, I send to server clone of proxy and always create a new request 
context which will be fired.
1. get immutable proxy A1 from DB
2. driver.display(A1)
3. user clicks save button
4. make a clone of A1 - A2
5. driver.edit(A2, requestContext)
6. driver.flush()
7. validate(A2) on client
8. requestContext.getRequest().save(A2).fire()
9. in case of exception or server validation failure driver.display(A1)
10. user may fix a problem and try save proxy again




  

 On Monday, June 8, 2015 at 11:11:41 PM UTC+2, Anton Mityagin wrote:


 As all you know RequestFactory does not support optimistic locking.

 see details 
 https://code.google.com/p/google-web-toolkit/issues/detail?id=6046

 I tried to implement it для RequestFactory + Spring + JPA + Hibernate

 I took as a basis the idea proposed by Thomas (
 http://stackoverflow.com/questions/7696764/does-gwt-requestfactory-support-implementation-of-optimistic-concurrency-control/7697307#7697307
 ).

 As he wrote his idea - pure theory.

 @ProxyFor(MyEntity.class)
 interface MyEntityProxy extends EntityProxy {
String getServerVersion();
String getClientVersion();
void setClientVersion(String clientVersion);
…
 }

 @Entity
 class MyEntity {
private String clientVersion;
@Version private String serverVersion;

public String getServerVersion() { return serverVersion; }
public String getClientVersion() { return null; }
public void setClientVersion(String clientVersion) {
   this.clientVersion = clientVersion;
}

public void patchVersion() {
   serverVersion = clientVersion;
}

public void shouldPatchVersion() {
   return Objects.equal(serverVersion, clientVersion);
}
 }

 On the server-side we need to use somthing like this to edit 
 MyEntityProxy 
 public P extends BaseProxy P edit(P proxy, RequestContext request)
 {
   P mutableProxy = request.edit(proxy);
   
   if (mutableProxy instanceof MyEntityProxy)
   {
 MyEntityProxy myProxy = (MyEntityProxy)mutableProxy;
 myProxy.setClientVersion(myProxy.getServerVersion());
   }
 }

 On the server-side we need to handle case when clientVersion not equals 
 to serverVersion.

 I think that if we use EntityManager, we do not have to manually throw an 
 exception when the versions are not equal.
 It has to do EntityManager when it tries to save domain object in the 
 database. Otherwise a situation may arise when 
 an object has been checked, but has not been saved to the database, and 
 someone else has save the same object.

 I think a good place to make check and patch server version right before 
 validating the domain object.
 ServiceLayerDecorator
 public T SetConstraintViolationT validate(T domainObject)

 Unfortunately, not enough simply call MyEntity.patchVersion()
 JPA provider uses internal structures to keep current version of maanged

Re: GWT 2.7.0 RequestFactory + Spring + JPA + Hibernate optimistic locking implementation

[Jens]

We don't use RequestFactory but GWT-RPC with Eclipselink + optimistic 
locking and heavy auto saving. Because we don't want to live with the extra 
query when doing the em.find / detach / update version / merge dance we 
simply do the version check manually in the app. Also we don't send 
versions to the client, we keep track of them on the server only.

On server side we have a class called EntityVersionStore and each user 
session has exactly one instance of it. This store is transactional just 
like the EntityManager so you can do EVS.beginTransaction() / rollback() / 
flush() / commit(). Then we have a EVS.remember(Entity) method that can 
only be called within an active transaction and simply stores the current 
entity version inside an internal map. 
To do the optimistic lock checking we have EVS.checkVersion(Entity) which 
compares the current entity version against the version that has been 
flushed() or committed() to the store previously. Finally we have @PostLoad 
and @PostUpdate hooks in a base entity that simply call EVS.remember(this) 
whenever an entity is loaded from DB or saved to DB.

So when a request reaches the server the overall workflow is

1. entityManager.beginTransaction()
2. evs.beginTransaction()
3. dispatch command to a handler (we use command pattern)
4. Inside the handler we load entities which causes the @PostLoad hook of 
those entities to be executed (evs.remember(this))
5. Manually compare versions via evs.checkVersion(entityToEdit). As 
checkVersion() only works on flushed/committed data the version remembered 
in 4. is not used. Instead the version of any previous request is used as 
that data is committed.
6. If version checks passes continue modifying the entities and save them 
to DB
7. entityManager. commit()
8. @PostUpdate hook executes for all updated entities and EVS will be 
updated just like in 4.
9. evs.commit() to make all the remembered versions of that current request 
committed so that the next request can use that information when calling 
checkVersion.


Works pretty transparent for us, as the only thing we need to do is to call 
evs.checkVersion() before updating an entity. And with some abstract 
handlers for common tasks like saving one entity we don't even have to call 
evs.checkVersion() as the abstract handler does this for us.


-- J.

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.7.0 RequestFactory + Spring + JPA + Hibernate optimistic locking implementation

[Ignacio Baca Moreno-Torres]

IMO using attached entities in RF is dangerous because in hibernate any 
committed transaction will persist any previous change in the current 
context. So, if you are using per-request entityManager, whenever you call 
transaction.commit you will persist any modification sent from the client 
(which has been set to an attached entity). And, because all our entities 
were detached after the validation phase, we did use the default optimistic 
lock (no forceLocked). 

On Tuesday, June 9, 2015 at 9:34:19 PM UTC+2, Anton Mityagin wrote:


 Thanks for your comment

 On Tuesday, June 9, 2015 at 10:12:10 PM UTC+3, Ignacio Baca Moreno-Torres 
 wrote:

 We made a similar approach using the client/server version variables. But 
 we call it version/expectedVersion.

 As explained in stackoverflow 
 http://www.google.com/url?q=http%3A%2F%2Fstackoverflow.com%2Fquestions%2F7696764%2Fdoes-gwt-requestfactory-support-implementation-of-optimistic-concurrency-control%2F7697307%237697307sa=Dsntz=1usg=AFQjCNEjQwYbtnsepzEPUD0X1zeqCT3jAg
  RF 
 only sent changes, this forces to have an always-null expectedVersion and 
 manually copy the getVersion to setExpectedVersion to enable optimistic 
 locking. BUT! it's critical that the entity be detached when you set the 
 version (or you detach and merge) because if you set the version on an 
 attached entity the version is not checked (at least in hibernate).

 Yes, I know about detached entity and setting version to it, in the end 
 of my post I pointed this thing, and I pointed how to set version to 
 attached entity (managed by hibernate).
  

 OTOH, RF only sent changes to the server so optimistic locking is not 
 required most of the time. Just for curiosity, why you need optimistic 
 locking?


 Because there is a possibility conflict while saving data and users dont 
 want to lose their data or overrite someone else's data.


 Usually only some operation requires fully transactional/optimistic 
 locking and in our experience, this operations are better handled using 
 some kind of command pattern. I.e. sent how-to-update instead of 
 what-to-set. We used the optimistic locking approach initially because we 
 try to use RF/Entities/Proxies for everything, but now we use commands for 
 this situations and versions are not required anymore. Moreover, RF has a 
 problem when you try to repeat an operation (which is a good idea in 
 optimistic locking), because if the server side fails in the operations 
 phase (after validation phase) the client entity gets invalidated, and you 
 can't sent the entity again.

 Yes, I know about this problem.
 I have workaround it.
 Now I test it and I you wish I'll post it here

 In short, I send to server clone of proxy and always create a new request 
 context which will be fired.
 1. get immutable proxy A1 from DB
 2. driver.display(A1)
 3. user clicks save button
 4. make a clone of A1 - A2
 5. driver.edit(A2, requestContext)
 6. driver.flush()
 7. validate(A2) on client
 8. requestContext.getRequest().save(A2).fire()
 9. in case of exception or server validation failure driver.display(A1)
 10. user may fix a problem and try save proxy again




  

 On Monday, June 8, 2015 at 11:11:41 PM UTC+2, Anton Mityagin wrote:


 As all you know RequestFactory does not support optimistic locking.

 see details 
 https://code.google.com/p/google-web-toolkit/issues/detail?id=6046

 I tried to implement it для RequestFactory + Spring + JPA + Hibernate

 I took as a basis the idea proposed by Thomas (
 http://stackoverflow.com/questions/7696764/does-gwt-requestfactory-support-implementation-of-optimistic-concurrency-control/7697307#7697307
 ).

 As he wrote his idea - pure theory.

 @ProxyFor(MyEntity.class)
 interface MyEntityProxy extends EntityProxy {
String getServerVersion();
String getClientVersion();
void setClientVersion(String clientVersion);
…
 }

 @Entity
 class MyEntity {
private String clientVersion;
@Version private String serverVersion;

public String getServerVersion() { return serverVersion; }
public String getClientVersion() { return null; }
public void setClientVersion(String clientVersion) {
   this.clientVersion = clientVersion;
}

public void patchVersion() {
   serverVersion = clientVersion;
}

public void shouldPatchVersion() {
   return Objects.equal(serverVersion, clientVersion);
}
 }

 On the server-side we need to use somthing like this to edit 
 MyEntityProxy 
 public P extends BaseProxy P edit(P proxy, RequestContext request)
 {
   P mutableProxy = request.edit(proxy);
   
   if (mutableProxy instanceof MyEntityProxy)
   {
 MyEntityProxy myProxy = (MyEntityProxy)mutableProxy;
 myProxy.setClientVersion(myProxy.getServerVersion());
   }
 }

 On the server-side we need to handle case when clientVersion not equals 
 to serverVersion.

 I think that if we use EntityManager, we do not have to manually throw 
 an exception when the versions are not equal

GWT 2.7.0 RequestFactory + Spring + JPA + Hibernate optimistic locking implementation

[Anton Mityagin]

As all you know RequestFactory does not support optimistic locking.

see 
details https://code.google.com/p/google-web-toolkit/issues/detail?id=6046

I tried to implement it для RequestFactory + Spring + JPA + Hibernate

I took as a basis the idea proposed by 
Thomas 
(http://stackoverflow.com/questions/7696764/does-gwt-requestfactory-support-implementation-of-optimistic-concurrency-control/7697307#7697307).

As he wrote his idea - pure theory.

@ProxyFor(MyEntity.class)
interface MyEntityProxy extends EntityProxy {
   String getServerVersion();
   String getClientVersion();
   void setClientVersion(String clientVersion);
   …
}

@Entity
class MyEntity {
   private String clientVersion;
   @Version private String serverVersion;

   public String getServerVersion() { return serverVersion; }
   public String getClientVersion() { return null; }
   public void setClientVersion(String clientVersion) {
  this.clientVersion = clientVersion;
   }
   
   public void patchVersion() {
  serverVersion = clientVersion;
   }

   public void shouldPatchVersion() {
  return Objects.equal(serverVersion, clientVersion);
   }
}

On the server-side we need to use somthing like this to edit MyEntityProxy 
public P extends BaseProxy P edit(P proxy, RequestContext request)
{
  P mutableProxy = request.edit(proxy);
  
  if (mutableProxy instanceof MyEntityProxy)
  {
MyEntityProxy myProxy = (MyEntityProxy)mutableProxy;
myProxy.setClientVersion(myProxy.getServerVersion());
  }
}

On the server-side we need to handle case when clientVersion not equals to 
serverVersion.

I think that if we use EntityManager, we do not have to manually throw an 
exception when the versions are not equal.
It has to do EntityManager when it tries to save domain object in the 
database. Otherwise a situation may arise when 
an object has been checked, but has not been saved to the database, and 
someone else has save the same object.

I think a good place to make check and patch server version right before 
validating the domain object.
ServiceLayerDecorator
public T SetConstraintViolationT validate(T domainObject)

Unfortunately, not enough simply call MyEntity.patchVersion()
JPA provider uses internal structures to keep current version of maanged 
object.
And value of serverVersion does not actually play any role.

We need to use specific JPA provider's API to change a version of managed 
object.

In my case it's Hibernate:

@Override
public T SetConstraintViolationT validate(T domainObject)
{
  
  if (domainObject != null  domainObject instanceof HasVersion?)
  {
MyEntity version = (MyEntity)domainObject;

if (!version.*shouldPatchVersion*())
{
  ApplicationContext context = 
ApplicationContextHolderLocator.getHolder().getApplicationContext();
  EntityManager entityManager = context.getBean(EntityManager.class);
  
  if (entityManager.getDelegate() instanceof SessionImplementor)
  {
SessionImplementor sess = 
(SessionImplementor)entityManager.getDelegate();
EntityEntry entry = 
sess.getPersistenceContext().getEntry(domainObject);
if (entry != null)
{
  version.*patchVersion*();
  LockMode lockMode = entry.getLockMode();
  *entry.forceLocked(domainObject, version.getServerVersion());*
  entry.setLockMode(lockMode);
}
  }
}
  }
  
  return super.validate(domainObject);
}

after this manipulation Hibernate will throws StaleObjectStateException as 
expected if client has edited old version of domain object.


There is another way to patch version in domain object:

in the method T find(Class? extends T clazz, I id); of entities locator 
detach from persistent context the found domain object
in the method validate(T domainObject) call method *patchVersion*() and try 
to attach domain object to the persistent context by calling
entityManger.merge.
No hibernate dependency, but one more database hit while merging object and 
exceptions may be thrown.


Please express an opinion on this implementation.

What are the disadvantages?

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory proxies stuck in RequestContext edit context

[Anton Mityagin]

I think I've found a workaround.

A key of it is to ignore validation after entity was deleted in *another *
context.
To do that you need implement some interface in proxies which can be 
deleted.
something like:
public interface IgnoreValidator
{
boolean isIgnore();

void setIgnore(boolean ignore);
}

and after delete operation set to all *unfrozen *beans setIgnore(true)
something like this:

void delete(final ListENTITY list)
{
ListENTITY toDelete = new ArrayList();
for(ENTITY entity : list)
{
if (entity.wasSaved()) 
{
*// send to server only saved entities*
*// no need to delete unsaved*
*toDelete.add(entity);*
}
}

RequestContext request = getNewRequestContext();

request.delete(*toDelete*).fire(new ReceiverVoid()
{
@Override
public void onSuccess(Void response)
{
// set ignore validation to all unfrozen beans
for(ENTITY e : *list*)
{
if (e instanceof IgnoreValidator)
{
AutoBeanENTITY bean = AutoBeanUtils.getAutoBean(e);
if (!bean.isFrozen())
{
((IgnoreValidator)e).setIgnore(true);
}
}
}
}
});
}

Also you need to replace default validator by your validator.
Just create 3 classes:

ValidationProvider:
*MyValidationProvider *which extends *HibernateValidator*

ValidatorFactory:

*ValidatorFactoryDecorator *implements *ValidatorFactory*

Validator:
*ValidatorDecorator *implements *Validator*

Your MyValidationProvider must create your ValidatorFactoryDecorator which 
accepts *super.buildValidatorFactory(configurationState)* as delegate.

Your ValidatorFactoryDecorator must return ValidatorDecorator which accepts 
*delegate.getValidator()* as delegate.

Your validator must *decorate *default validator and dispatch all method 
calls to default validator expect method *validate*.
this method may be implemented something like this:
 

@Override
public T SetConstraintViolationT validate(T object, Class?... 
groups)
{
if (object instanceof IgnoreValidator)
{
IgnoreValidator deletable = (IgnoreValidator)object;
if (deletable.isIgnore())
{
return Collections.emptySet();
}
}

return delegate.validate(object, groups);
}

thus you will not perform validation those objects that do not need to be 
validated

do not forget add 
META-INF/validation.xml
and
META-INF/services/javax.validation.spi.ValidationProvider

META-INF must be in
ROOT
|_META-INF -- don't put validation.xml here
|_WEB-INF
|__ classes
   |_META-INF
|__validation.xml
http://stackoverflow.com/questions/8701482/bean-validation-validation-xml-ignored

in META-INF/services/javax.validation.spi.ValidationProvider just add one 
line - full name of your MyValidationProvider 


After you had implemented this.
You will be able to edit proxy A and proxies B in one RequestContext.
and safety delete proxies B in another RequestContext.
After you had fired delete request your B proxies will be marked to ignore 
validation.
and you can fire save request for A proxy.

I've checked this workaround.
It's seems worked.

Can someone can point any invisible problems of this solution?


On Saturday, August 13, 2011 at 4:47:05 PM UTC+3, Jesse Hutton wrote:

 I have a entity proxy A that contains a collection of relations (ListB), 
 which corresponds to a standard @OneToMany association in JPA. My edit view 
 of proxy A contains a HasDataEditorB implementation managing the list of 
 associations. The form also allows an arbitrary number of new B proxies to 
 be added as relations. When adding a new B, I have a popup form that 
 implements EditorB, which I use to edit the properties of the new 
 instance. When that form is confirmed, I flush its editor driver, and add 
 the proxy instance to the HasDataEditorB list in the main form. In this 
 way, new B instances are only created on the server when A is persisted and 
 the object graph is sent along with the request. In order for this to work, 
 I have to use the RequestContext that is managing edits of A when I create 
 new B proxy instances. And it works great if the B instances I instantiate 
 can always be submitted in a valid state.

 The problem I'm having is that once I create a new proxy B in the 
 RequestContext managing A, I can't seem to remove it. For example, if I 
 click the Create new B button and then close the popup form immediately, 
 the new proxy created for adding the aborted B is stuck in the 
 RequestContext. Even though B is never added to the HasDataEditorB 
 element in the form for A, it will be submitted as part of the set of 
 objects being edited by the RequestContext. This can lead to a state where 
 the form for A cannot be submitted due to validation errors from lingering 
 

Re: RequestFactory - ClassNotFound: JsonException but gwt-dev in WEB-INF/lib

[andymel]

Thanks a lot Thomas! Perfect hint. Much smaller and it works :)
But let me dig deeper...You say: Do not ever deploy gwt-dev or gwt-user!. 
Because of the size (83kb vs 39mb) or is there also another reason why you 
say it that strict?
Because I still don't see why the JSONException class was not found in the 
gwt-dev library.




Am Donnerstag, 12. Februar 2015 11:28:55 UTC+1 schrieb Thomas Broyer:

 Do not ever deploy gwt-dev or gwt-user!
 There's a gwt-servlet.jar for that, and a gwt-servlet-deps.jar including 
 its dependencies, for those who don't use managed dependencies (through 
 Maven, Gradle, Ivy, etc.)

 On Thursday, February 12, 2015 at 12:51:47 AM UTC+1, andymel wrote:

 Hi,

 I get the following exception when I try to run my compiled gwt project 
 with a tomcat server:

 Feb 12, 2015 12:34:03 AM org.apache.catalina.core.StandardWrapperValve 
 invoke
 SEVERE: Servlet.service() for servlet [requestFactoryServlet] in context 
 with path [/gwtproj] threw exception [Servlet execution threw an exception] 
 with root cause
 java.lang.ClassNotFoundException: org.json.JSONException
 at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1711)
 at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1556)
 at 
 com.google.web.bindery.autobean.shared.impl.StringQuoter.split(StringQuoter.java:73)
 at 
 com.google.web.bindery.autobean.shared.AutoBeanCodex.decode(AutoBeanCodex.java:54)
 at 
 com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:132)
 at 
 com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:133)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
 at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
 at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
 at 
 org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
 at 
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
 at 
 org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)

 I added the gwt-dev.jar in the WEB-INF/lib directory after I got that 
 exception the first time and I can see it in the lib folder on the server. 
 But the Exception is still thrown. The app starts and can be used, but when 
 it comes to the first usage of the requestfactory the exception is thrown.

 I have undeployed/recompiled/deployed the app multiple time now. 
 Any idea?

 Thanks!
 Andy



-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory - ClassNotFound: JsonException but gwt-dev in WEB-INF/lib

[Thomas Broyer]

Do not ever deploy gwt-dev or gwt-user!
There's a gwt-servlet.jar for that, and a gwt-servlet-deps.jar including 
its dependencies, for those who don't use managed dependencies (through 
Maven, Gradle, Ivy, etc.)

On Thursday, February 12, 2015 at 12:51:47 AM UTC+1, andymel wrote:

 Hi,

 I get the following exception when I try to run my compiled gwt project 
 with a tomcat server:

 Feb 12, 2015 12:34:03 AM org.apache.catalina.core.StandardWrapperValve 
 invoke
 SEVERE: Servlet.service() for servlet [requestFactoryServlet] in context 
 with path [/gwtproj] threw exception [Servlet execution threw an exception] 
 with root cause
 java.lang.ClassNotFoundException: org.json.JSONException
 at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1711)
 at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1556)
 at 
 com.google.web.bindery.autobean.shared.impl.StringQuoter.split(StringQuoter.java:73)
 at 
 com.google.web.bindery.autobean.shared.AutoBeanCodex.decode(AutoBeanCodex.java:54)
 at 
 com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:132)
 at 
 com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:133)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
 at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
 at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
 at 
 org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
 at 
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
 at 
 org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)

 I added the gwt-dev.jar in the WEB-INF/lib directory after I got that 
 exception the first time and I can see it in the lib folder on the server. 
 But the Exception is still thrown. The app starts and can be used, but when 
 it comes to the first usage of the requestfactory the exception is thrown.

 I have undeployed/recompiled/deployed the app multiple time now. 
 Any idea?

 Thanks!
 Andy


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

RequestFactory - ClassNotFound: JsonException but gwt-dev in WEB-INF/lib

[andymel]

Hi,

I get the following exception when I try to run my compiled gwt project 
with a tomcat server:

Feb 12, 2015 12:34:03 AM org.apache.catalina.core.StandardWrapperValve 
invoke
SEVERE: Servlet.service() for servlet [requestFactoryServlet] in context 
with path [/gwtproj] threw exception [Servlet execution threw an exception] 
with root cause
java.lang.ClassNotFoundException: org.json.JSONException
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1711)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1556)
at 
com.google.web.bindery.autobean.shared.impl.StringQuoter.split(StringQuoter.java:73)
at 
com.google.web.bindery.autobean.shared.AutoBeanCodex.decode(AutoBeanCodex.java:54)
at 
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:132)
at 
com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:133)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

I added the gwt-dev.jar in the WEB-INF/lib directory after I got that 
exception the first time and I can see it in the lib folder on the server. 
But the Exception is still thrown. The app starts and can be used, but when 
it comes to the first usage of the requestfactory the exception is thrown.

I have undeployed/recompiled/deployed the app multiple time now. 
Any idea?

Thanks!
Andy

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory - ValueProxy is null

[Jens]

From the official GWT documentation:



When querying the server, RequestFactory does not automatically populate 
relations in the object graph. To do this, use the with() method on a 
request and specify the related property name as a String:

RequestPerson findReq = 
requestFactory.personRequest().find(personId).with(address);

It is also necessary to use the with() method to retrieve any properties 
with types extending ValueProxy. The with() method takes multiple String 
arguments, so you can specify multiple property names at once. To specify 
nested properties, use dot notation. Putting it all together, you might have

RequestPerson findReq = 
find(personId).with(phone,address.city,address.zip)


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

RequestFactory - ValueProxy is null

[andymel]

Hi,

I have written a small program to test the RequestFactory. I have a 
TestEntity class and a TestValue class on the server and corresponding 
TestEntityProxy and TestValueProxy on the client.

public class TestEntity {

private static long staticIDpool = 0;
 private Long id;
private String testString;
private TestValue testValue; 
 public TestEntity() {
super();
id = Long.valueOf(staticIDpool++);
}

public Long getId() {
return id;
}

 public String getTestString() {
return testString;
}
public void setTestString(String testValue1) {
this.testString = testValue1;
}

public TestValue getTestValue() {
return testValue;
}
public boolean setTestValue(TestValue testValue) {
this.testValue = testValue;
return true;
}
 @Override
public String toString() {
return Entity [+testString+, +testValue+];
}
}

public class TestValue {

private String s1;
 public TestValue() {
s1 = default1 (set on server);
}
 public String getS1() {
return s1;
}
public boolean setS1(String s) {
this.s1 = s;
return true;
}

@Override
public String toString() {
return TestValue [+s1+];
}
}

The proxies
@ProxyFor(value = TestEntity.class, locator = EntityLocator.class)
public interface TestEntityProxy extends EntityProxy {
 String getTestString();
 TestValueProxy getTestValue();
}

@ProxyFor(TestValue.class)
public interface TestValueProxy extends ValueProxy {
String getS1();
}

The EntityDAO and Locators
public class EntityDAO {
 private final static Logger LOG = Logger.getLogger();
 private static EntityDAO singletonInst;
 private EntityDAO(){} // use getInstance() to get the singleton instance
 public static EntityDAO getInstance(){
if(singletonInst==null)singletonInst = new EntityDAO();
return singletonInst;
}

public TestEntity createDefaultTestEntity(){
LOG.info(server createDefaultTestEntity());

TestValue v = new TestValue();
v.setS1(testVALString (set on server));

TestEntity e = new TestEntity();//v, teststring set on server);
e.setTestString(teststring set on server);
e.setTestValue(v);
 LOG.info(server created! +e);
return e;
}
}

public class EntityLocator extends LocatorTestEntity, Long {

@Override
public TestEntity create(Class? extends TestEntity clazz) {
return EntityDAO.getInstance().createDefaultTestEntity();
}

@Override
public TestEntity find(Class? extends TestEntity clazz, Long id) {
return null;
}

@Override
public ClassTestEntity getDomainType() {
return TestEntity.class;
}

@Override
public Long getId(TestEntity domainObject) {
return domainObject.getId();
}

@Override
public ClassLong getIdType() {
return Long.class;
}

@Override
public Object getVersion(TestEntity domainObject) {
return null;
}

}

public class EntityDaoLocator implements ServiceLocator {
 public Object getInstance(Class? clazz) {
return EntityDAO.getInstance();
}

}

My RequestFactory
public interface TestRequestFactory extends RequestFactory {

@Service(value = EntityDAO.class, locator = EntityDaoLocator.class)
public interface EntityRequestContext extends RequestContext{
RequestTestEntityProxy createDefaultTestEntity();
}
 public EntityRequestContext getEntityRequestContext();
}

And finally the entryPoint
public void onModuleLoad() {

TestRequestFactory requestFactory = GWT.create(TestRequestFactory.class);
requestFactory.initialize(new SimpleEventBus());

requestFactory.getEntityRequestContext().createDefaultTestEntity().fire(new 
ReceiverTestEntityProxy() {

@Override
public void onSuccess(TestEntityProxy e) {
TestValueProxy v = e.getTestValue();
String vs = null;
if(v!=null){
vs = v.getS1();
}
Window.alert(e.getTestString()+ / +vs);
}
 @Override
public void onFailure(ServerFailure error) {
try{
super.onFailure(error); 
}catch(Exception e){
Window.alert(error.getMessage());
}
}
});
} 

The Text in the alert dialog is teststring set on server / null. So the 
String is transmitted to the client but the test vale set in the entity is 
null. On server side the toString of the entity (log message at the end of 
createDefaultTestEntity()) returns server created! Entity [teststring set 
on server, TestValue [testVALString (set on server)]]
So the testValue is set in here.

Please, can anybody tell me what I did wrong. Cause at the moment I can't 
see the difference to the tutorials I read.
Thanks alot!! 
Andy

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory - ValueProxy is null

[andymel]

Jens, it works! Thanks a lot for this brief and great answer!




Am Donnerstag, 22. Januar 2015 19:08:22 UTC+1 schrieb Jens:

 From the official GWT documentation:



 When querying the server, RequestFactory does not automatically populate 
 relations in the object graph. To do this, use the with() method on a 
 request and specify the related property name as a String:

 RequestPerson findReq = 
 requestFactory.personRequest().find(personId).with(address);

 It is also necessary to use the with() method to retrieve any properties 
 with types extending ValueProxy. The with() method takes multiple String 
 arguments, so you can specify multiple property names at once. To specify 
 nested properties, use dot notation. Putting it all together, you might have

 RequestPerson findReq = 
 find(personId).with(phone,address.city,address.zip)




-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

GWT RequestFactory. Could not locate setter for property id in type ...ui.server.entity.mc.BasketItem at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator die(ServiceLayerDecorator.

[stepan kachan]

Hi all, i decided to use GWT Request Factory instead of RPC because of 
complex type objects in my project. I face this error everytime when i try 
to remove entity from List. 

public class BasketItem implements Serializable{
private Integer id;
private PaymentState paymentState;

public BasketItem() {
super();
}

public BasketItem(PaymentState paymentState) {
this.paymentState = paymentState;
}
public Integer getId() {
return id;
}

void setId(Integer id) {
this.id = id;
}

public PaymentState getPaymentState() {
return paymentState;
}

public void setPaymentState(PaymentState paymentState) {
this.paymentState = paymentState;
}
}


@ProxyFor(value = BasketItem.class)
public interface BasketItemProxy extends ValueProxy {

public Integer getId();

public PaymentStateProxy getPaymentState();
}


@Service(value = BasketFacadeRemote.class, locator = 
BasketFacadeServiceLocator.class)
public interface BasketRequestContext extends RequestContext {
RequestInteger registerBasketPayment(PaymentStateProxy payment);
RequestBoolean editBasketPayment(BasketItemProxy item);
RequestBoolean confirmBasketPayment();
RequestBoolean confirmBasketPayment(BasketItemProxy item);
RequestBoolean cancelBasketPayment(BasketItemProxy item);
RequestBoolean cancelBasketPayment(ListBasketItemProxy items);
RequestListBasketItemProxy getBasketListItems();
RequestBasketProxy getBasket();
}


public interface BasketFacadeRemote {
Integer registerBasketPayment(PaymentState payment);
Boolean editBasketPayment(BasketItem item);
Boolean confirmBasketPayment();
Boolean confirmBasketPayment(BasketItem item);
Boolean cancelBasketPayment(BasketItem item);
Boolean cancelBasketPayment(ListBasketItem items);
ListBasketItem getBasketListItems();
Basket getBasket();
}


Here is a snippet of code where I try to call cancelBasketPayment method, 
and here I cath this error :


 final BasketRequestContext basketRequestContext = 
EntityService.get().getBasketRequestContext();
  ArrayListBasketItemProxy removeList = new 
ArrayListBasketItemProxy();
  for (BasketItemProxy bi : 
PaymentsBasketLayout.getDgSelectionModel().getSelectedSet()) {
  
removeList.add(RequestFactoryUtil.cloneProxy(BasketItemProxy.class, bi, 
basketRequestContext));
  }
  
basketRequestContext.cancelBasketPayment(removeList).fire(new 
CustomReceiverBoolean() {
  @Override
  public void onSuccess(Boolean response) {
 // PROCESS
  
  }

Please help...

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RequestFactory. Could not locate setter for property id in type ...ui.server.entity.mc.BasketItem at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator die(ServiceLayerDecorat

[Thomas Broyer]

On Monday, October 20, 2014 10:23:03 AM UTC+2, stepan kachan wrote:

 Hi all, i decided to use GWT Request Factory instead of RPC because of 
 complex type objects in my project. I face this error everytime when i try 
 to remove entity from List. 

 public class BasketItem implements Serializable{
 private Integer id;
 private PaymentState paymentState;

 public BasketItem() {
 super();
 }

 public BasketItem(PaymentState paymentState) {
 this.paymentState = paymentState;
 }
 public Integer getId() {
 return id;
 }

 void setId(Integer id) {
 this.id = id;
 }


Your setter is not 'public', that's (IIRC) the reason (if not done already, 
we should probably add warnings in the annotation processor / 
ValidationTool)

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RPC vs. RequestFactory vs. RestyGWT

[Ralf Klemmer]

First, thanks for all your replies! 

If I understand Thomas right, it is possible to use RF as a single endpoint 
for GWT-Clients and Rest-Clients. Well that's great to know. Are there any 
plans to increase the documentation coverage in RF?

Also my questions wasn't exclusively meant to be technical.

A GWT beginner does the following learning steps (of course not complete):
1. learn RPC
2. application and objects grow and you look for alternatives: 
RequestFactory to the rescue!
3. highly motivated you start learning
4. two weeks later you might ask yourself if this was a good idea, of 
course you made it work, but you had to struggle a lot. And your gut 
feeling stays: Is this really the best solution?

That was partly my personal experience. Then I found RestyGWT and after 4 
hours all worked as expected and I had removed hundreds lines of code - 
great feeling for me!

If RestyGWT is not an option to replace RF, then RF has to provide dead 
simple and understandable official tutorials, sample projects and good 
documentation! If no one knows what RF can do for you, then it's like being 
non existent.
And in the context of the myth that GWT is dead, GWT should as easy and 
fun to learn as it was years ago. That should be one of the main goals for 
the steering committee. If you look at the official site and see articles 
from 2009, that's not what you would expect from a modern framework! Help 
the GWT community to grow by bringing the learning and programming fun back.

What are your thoughts?

Am Donnerstag, 16. Oktober 2014 17:22:08 UTC+2 schrieb Thomas Broyer:



 On Thursday, October 16, 2014 3:22:47 PM UTC+2, Ümit Seren wrote:

 I have been using RequestFactory extensively for a project and I must say 
 that although it is pretty well engineered, the learning curve is quite 
 high. 


 +1
  

 If you have a CRUD heacy application where you send and receive lots of 
 data, it might be a good solution (because it only sends deltas). 


 Well, RF is good at RPC too (using ValueProxy).
 I think Google is using it mostly that way, with the JSON-RPC dialect (I 
 don't think they use the native dialect, that allows batching, etc.).

 However there are also some pain points: For example on the server side it 
 uses Reflection to initialize the server instances which is slower than if 
 the code would be generated. 


 I was thinking about generating code for the server (or JVM clients), but 
 the current use of ServiceLayers is likely to greatly limit the gains in 
 performance…
 Still, walking the object hierarchies might benefit from such codegen.
  

 Also currently there is no real further development ongoing (apart from 
 some bugfixes). 


 …but I never found the time and energy to actually work on the codegen.
  

 Another downside is that there is really strong coupling between backend 
 and frontend with RF. 


 Though less strong that with GWT-RPC, because the client and server have 
 to use compatible versions of the proxies (compatible in a way similar to 
 how ProtoBufs are compatible with one another), not necessarily the exact 
 same class as in GWT-RPC (well, there are solutions I believe for GWT-RPC, 
 by having several serialization policies at once on the server).
  

 In many cases you might need a public API to access the data from non GWT 
 clients, so you might end up implementing two endpoints (RF and REST).


 Well, RF has a well-defined (though not well-documented) protocol, and 
 it's capable of using JSON-RPC (though only on client-side), so you 
 *could* use a single endpoint.
 But I otherwise agree with your point.



-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RPC vs. RequestFactory vs. RestyGWT

[Thomas Broyer]

On Friday, October 17, 2014 11:59:02 AM UTC+2, Ralf Klemmer wrote:

 First, thanks for all your replies! 

 If I understand Thomas right, it is possible to use RF as a single 
 endpoint for GWT-Clients and Rest-Clients. Well that's great to know.


All you need is to use RequestFactorySource.create() instead of 
GWT.create(), and provide a RequestTransport (there's a UrlRequestTransport 
using java.net.URL and HttpURLConnection but it's not really meant to be 
used in production (you'd prefer using Apache HttpClient or OkHttp).
 

 Are there any plans to increase the documentation coverage in RF?


Not really actually.
If you want something to be documented (or better documented), feel free to 
file requests in the issue tracker; or even better contribute a patch to 
the documentation.
 

 Also my questions wasn't exclusively meant to be technical.

 A GWT beginner does the following learning steps (of course not complete):
 1. learn RPC
 2. application and objects grow and you look for alternatives: 
 RequestFactory to the rescue!
 3. highly motivated you start learning
 4. two weeks later you might ask yourself if this was a good idea, of 
 course you made it work, but you had to struggle a lot. And your gut 
 feeling stays: Is this really the best solution?


It's not.
It has many benefits over GWT-RPC, but it's clearly not the best solution 
out there.

We're still searching for the best solution, and we'd like to have 
something better in a future version of GWT that could replace both GWT-RPC 
and RequestFactory, hopefully next year.
 

 That was partly my personal experience. Then I found RestyGWT and after 4 
 hours all worked as expected and I had removed hundreds lines of code - 
 great feeling for me!

 If RestyGWT is not an option to replace RF, then RF has to provide dead 
 simple and understandable official tutorials, sample projects and good 
 documentation! If no one knows what RF can do for you, then it's like being 
 non existent.
 And in the context of the myth that GWT is dead, GWT should as easy and 
 fun to learn as it was years ago. That should be one of the main goals for 
 the steering committee. If you look at the official site and see articles 
 from 2009, that's not what you would expect from a modern framework! Help 
 the GWT community to grow by bringing the learning and programming fun back.

 What are your thoughts?


With 2.7 and SDM, we're focusing on the programming fun ;-)
and would be glad to receive contributions to the docs from the community. 
People who need the doc are in the best position to improve it when they 
had to look things up elsewhere. When you know something really well, you 
can answer questions, but it's hard to know upfront what people need to 
know and how to teach them. So don't be shy and head to Gerrit or the issue 
tracker ;-)

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

RPC vs. RequestFactory vs. RestyGWT

[Ralf Klemmer]

I've used RPC, RequestFactory and now RestyGWT in some GWT projects.
In my opinion RequestFactory development should be canceled and replaced by 
RestyGWT (or something like that).
My key arguments for that drastic opinion:

RPC
+ easy to learn
- proprietary
- problems when trying to send hierarchical entities over the wire
- mostly leads to DTOs, which leads to boilerplate code for mapping DTOs 
and entities, which leads to hardly maintainable code if you have to deal 
with hierarchical objects (e.g. entity A contains entity B which contains 
list of entity C)

RequestFactory
- proprietary
- high learning curve
- bad documentation (almost every is very old)
- development is slow (compared to other techniques)
-  boilerplate code
+ standard GWT communication
+ integration with Editor framework
+ transfer of data delta between client and server

RestyGWT
- no official part of the GWT framework and the potential risk of 
development cancelation
+ really, really easy
+ Java standard
+ great documentation (client side on RestyGWT site, server side on 
RestyGWT and every other REST documentation)
+ out-of-the-box accessible by any other device that can handle rest 
services
+ nearly no boilerplate code

What's your opinion about that? Is RequestFactory the right way or not? 
What are your experiences?

I'm looking forward to your answers,
Ralf

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RPC vs. RequestFactory vs. RestyGWT

[Vassilis Virvilis]

I am using RestyGWT although I am still using it in a RPC type of way and
not in a RESTful way.

The main reason is that I can split the project to server part and client
part more easily. The server part goes with all of my other services
without gwt jars where it can share code etc...

 Vassilis

On Thu, Oct 16, 2014 at 1:15 PM, Ralf Klemmer ralf.klem...@gmail.com
wrote:

 I've used RPC, RequestFactory and now RestyGWT in some GWT projects.
 In my opinion RequestFactory development should be canceled and replaced
 by RestyGWT (or something like that).
 My key arguments for that drastic opinion:

 RPC
 + easy to learn
 - proprietary
 - problems when trying to send hierarchical entities over the wire
 - mostly leads to DTOs, which leads to boilerplate code for mapping DTOs
 and entities, which leads to hardly maintainable code if you have to deal
 with hierarchical objects (e.g. entity A contains entity B which contains
 list of entity C)

 RequestFactory
 - proprietary
 - high learning curve
 - bad documentation (almost every is very old)
 - development is slow (compared to other techniques)
 -  boilerplate code
 + standard GWT communication
 + integration with Editor framework
 + transfer of data delta between client and server

 RestyGWT
 - no official part of the GWT framework and the potential risk of
 development cancelation
 + really, really easy
 + Java standard
 + great documentation (client side on RestyGWT site, server side on
 RestyGWT and every other REST documentation)
 + out-of-the-box accessible by any other device that can handle rest
 services
 + nearly no boilerplate code

 What's your opinion about that? Is RequestFactory the right way or not?
 What are your experiences?

 I'm looking forward to your answers,
 Ralf

 --
 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 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.




-- 
Vassilis Virvilis

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RPC vs. RequestFactory vs. RestyGWT

[Ümit Seren]

I have been using RequestFactory extensively for a project and I must say 
that although it is pretty well engineered, the learning curve is quite 
high. 
If you have a CRUD heacy application where you send and receive lots of 
data, it might be a good solution (because it only sends deltas). 
However there are also some pain points: For example on the server side it 
uses Reflection to initialize the server instances which is slower than if 
the code would be generated. 
Also currently there is no real further development ongoing (apart from 
some bugfixes). 

Another downside is that there is really strong coupling between backend 
and frontend with RF. 
In many cases you might need a public API to access the data from non GWT 
clients, so you might end up implementing two endpoints (RF and REST). 
If I would start again I probably would choose REST over RF just because it 
clearly separates frontend from backend. 



 

On Thursday, October 16, 2014 12:15:55 PM UTC+2, Ralf Klemmer wrote:

 I've used RPC, RequestFactory and now RestyGWT in some GWT projects.
 In my opinion RequestFactory development should be canceled and replaced 
 by RestyGWT (or something like that).
 My key arguments for that drastic opinion:

 RPC
 + easy to learn
 - proprietary
 - problems when trying to send hierarchical entities over the wire
 - mostly leads to DTOs, which leads to boilerplate code for mapping DTOs 
 and entities, which leads to hardly maintainable code if you have to deal 
 with hierarchical objects (e.g. entity A contains entity B which contains 
 list of entity C)

 RequestFactory
 - proprietary
 - high learning curve
 - bad documentation (almost every is very old)
 - development is slow (compared to other techniques)
 -  boilerplate code
 + standard GWT communication
 + integration with Editor framework
 + transfer of data delta between client and server

 RestyGWT
 - no official part of the GWT framework and the potential risk of 
 development cancelation
 + really, really easy
 + Java standard
 + great documentation (client side on RestyGWT site, server side on 
 RestyGWT and every other REST documentation)
 + out-of-the-box accessible by any other device that can handle rest 
 services
 + nearly no boilerplate code

 What's your opinion about that? Is RequestFactory the right way or not? 
 What are your experiences?

 I'm looking forward to your answers,
 Ralf


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RPC vs. RequestFactory vs. RestyGWT

[Thomas Broyer]

On Thursday, October 16, 2014 3:22:47 PM UTC+2, Ümit Seren wrote:

 I have been using RequestFactory extensively for a project and I must say 
 that although it is pretty well engineered, the learning curve is quite 
 high. 


+1
 

 If you have a CRUD heacy application where you send and receive lots of 
 data, it might be a good solution (because it only sends deltas). 


Well, RF is good at RPC too (using ValueProxy).
I think Google is using it mostly that way, with the JSON-RPC dialect (I 
don't think they use the native dialect, that allows batching, etc.).

However there are also some pain points: For example on the server side it 
 uses Reflection to initialize the server instances which is slower than if 
 the code would be generated. 


I was thinking about generating code for the server (or JVM clients), but 
the current use of ServiceLayers is likely to greatly limit the gains in 
performance…
Still, walking the object hierarchies might benefit from such codegen.
 

 Also currently there is no real further development ongoing (apart from 
 some bugfixes). 


…but I never found the time and energy to actually work on the codegen.
 

 Another downside is that there is really strong coupling between backend 
 and frontend with RF. 


Though less strong that with GWT-RPC, because the client and server have to 
use compatible versions of the proxies (compatible in a way similar to 
how ProtoBufs are compatible with one another), not necessarily the exact 
same class as in GWT-RPC (well, there are solutions I believe for GWT-RPC, 
by having several serialization policies at once on the server).
 

 In many cases you might need a public API to access the data from non GWT 
 clients, so you might end up implementing two endpoints (RF and REST).


Well, RF has a well-defined (though not well-documented) protocol, and it's 
capable of using JSON-RPC (though only on client-side), so you *could* use 
a single endpoint.
But I otherwise agree with your point.

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RPC vs. RequestFactory vs. RestyGWT

[Jonathan Franchesco Torres Baca]

Hi, I share resources to reduce online learning.

good luck!

MOOC: https://holamundodev.appspot.com/preview

Post: http://www.enjava2.com/2014/07/devol.html

CRUD in GitHub:
Dailypoor - code : https://github.com/chescot2302/dailypoor

Link App: https://dailypoor.appspot.com/

APP in GitHub:
Devol - code : https://github.com/chescot2302/devol

Link App: https://devolpay.appspot.com/#X


2014-10-16 8:22 GMT-05:00 Ümit Seren uemit.se...@gmail.com:

 I have been using RequestFactory extensively for a project and I must say
 that although it is pretty well engineered, the learning curve is quite
 high.
 If you have a CRUD heacy application where you send and receive lots of
 data, it might be a good solution (because it only sends deltas).
 However there are also some pain points: For example on the server side it
 uses Reflection to initialize the server instances which is slower than if
 the code would be generated.
 Also currently there is no real further development ongoing (apart from
 some bugfixes).

 Another downside is that there is really strong coupling between backend
 and frontend with RF.
 In many cases you might need a public API to access the data from non GWT
 clients, so you might end up implementing two endpoints (RF and REST).
 If I would start again I probably would choose REST over RF just because
 it clearly separates frontend from backend.





 On Thursday, October 16, 2014 12:15:55 PM UTC+2, Ralf Klemmer wrote:

 I've used RPC, RequestFactory and now RestyGWT in some GWT projects.
 In my opinion RequestFactory development should be canceled and replaced
 by RestyGWT (or something like that).
 My key arguments for that drastic opinion:

 RPC
 + easy to learn
 - proprietary
 - problems when trying to send hierarchical entities over the wire
 - mostly leads to DTOs, which leads to boilerplate code for mapping DTOs
 and entities, which leads to hardly maintainable code if you have to deal
 with hierarchical objects (e.g. entity A contains entity B which contains
 list of entity C)

 RequestFactory
 - proprietary
 - high learning curve
 - bad documentation (almost every is very old)
 - development is slow (compared to other techniques)
 -  boilerplate code
 + standard GWT communication
 + integration with Editor framework
 + transfer of data delta between client and server

 RestyGWT
 - no official part of the GWT framework and the potential risk of
 development cancelation
 + really, really easy
 + Java standard
 + great documentation (client side on RestyGWT site, server side on
 RestyGWT and every other REST documentation)
 + out-of-the-box accessible by any other device that can handle rest
 services
 + nearly no boilerplate code

 What's your opinion about that? Is RequestFactory the right way or not?
 What are your experiences?

 I'm looking forward to your answers,
 Ralf

  --
 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 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Vraptor 3.5.2 + RequestFactory Gwt

[Thiago borges martins]

Boa tarde Amigos,

Estou integrando Vraptor com o GWT e tenho algumas duvidas em relação a 
forma de fazer a ligação através do RequestFactory.

No RequestFactory tem a interface ServiceLocator que serve para fazer a 
ligação entre com o serviço do lado java. Já trabalhei com EBJ3 do lado do 
java onde fazemos a implementação usando o InitialContext.doLookup( 
java:global/ejb/ + clazz.getSimpleName() ).

Gostaria de saber como posso fazer essa mesma chamada usando o VRaptor.

Alguém poderia me ajudar?

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Vraptor 3.5.2 + RequestFactory Gwt

[Thomas Broyer]

AFAICT, VRaptor uses CDI, and CDI isn't that different from Guice; which 
means you should be able to 
use 
https://github.com/tbroyer/gwt-maven-archetypes/tree/master/guice-rf-activities/src/main/resources/archetype-resources/__rootArtifactId__-server/src/main/java
 
as an inspiration (replace Guice's Injector with CDI's BeanManager).

(BTW, thanks Google for the Portuguese → English translation)

On Tuesday, October 14, 2014 3:28:59 PM UTC+2, Thiago borges martins wrote:

 Boa tarde Amigos,

 Estou integrando Vraptor com o GWT e tenho algumas duvidas em relação a 
 forma de fazer a ligação através do RequestFactory.

 No RequestFactory tem a interface ServiceLocator que serve para fazer a 
 ligação entre com o serviço do lado java. Já trabalhei com EBJ3 do lado do 
 java onde fazemos a implementação usando o InitialContext.doLookup( 
 java:global/ejb/ + clazz.getSimpleName() ).

 Gostaria de saber como posso fazer essa mesma chamada usando o VRaptor.

 Alguém poderia me ajudar?


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: requestfactory-apt.jar misvalidates java.util.Map?

[Gordan Krešić]

On Tuesday, September 9, 2014 6:45:46 PM UTC+2, Thomas Broyer wrote:

 Hmm, it might be that Maps are only supported as properties within 
 proxies. Unit tests only cover that at least (and IIRC, we were aware of 
 the limitation but nobody worked on that final step).


It seems that doesn't matter where it is used: it gives warning when used 
as proxy's property too (and again if I invert use case and use Map inside 
a List):

public class EntityA {
public MapEntityA, EntityB getSimpleMap() { return 
Collections.emptyMap(); }
public MapEntityA, ListEntityB getListWithinMap() { return 
Collections.emptyMap(); }
public ListMapEntityA, EntityB getMapWithinList() { return 
Collections.emptyList(); }
}

@ProxyFor(EntityA.class)
public interface EntityAProxy extends EntityProxy {
MapEntityAProxy, EntityBProxy getSimpleMap(); /* ok */
MapEntityAProxy, ListEntityBProxy getListWithinMap(); /* error */
ListMapEntityAProxy, EntityBProxy getMapWithinList(); /* error */
}

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: requestfactory-apt.jar misvalidates java.util.Map?

[Gordan Krešić]

https://code.google.com/p/google-web-toolkit/issues/detail?id=5974 seems to 
cover this, but from comments it is unclear whether it is solved in 
compiler but not in annotations processor and why its status is still New. 
Documentation seems updated 
since https://code.google.com/p/google-web-toolkit/issues/detail?id=5974#c7 
(it now clearly states that MapK,V where K and V are transportable 
types is transportable).

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: requestfactory-apt.jar misvalidates java.util.Map?

[Thomas Broyer]

On Wednesday, September 10, 2014 11:49:10 AM UTC+2, Gordan Krešić wrote:

 https://code.google.com/p/google-web-toolkit/issues/detail?id=5974 seems 
 to cover this, but from comments it is unclear whether it is solved in 
 compiler but not in annotations processor and why its status is still New. 
 Documentation seems updated since 
 https://code.google.com/p/google-web-toolkit/issues/detail?id=5974#c7 (it 
 now clearly states that MapK,V where K and V are transportable types is 
 transportable).


Ah yes, sorry, I read your first post too fast. Indeed, nested 
parameterized types still aren't supported. I removed scalar from the doc 
as an attempt to cover proxies, but forgot to explicitly exclude 
collections and maps.

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

RequestFactory: get original (frozen) proxy from edit()-ed instance

[Gordan Krešić]

In some of my editors, I'm implementing ValueAwareEditorP and using 
provided proxy value in setValue to obtain editor-specific data (most 
simple example would be to get suggestions for some sub-editors). Problem 
is that proxy instance that I was given in setValue is already edited in 
driver's RequestContext, so I'm unable to use it as parameter in another 
context (for obtaining suggestions). Error is well known 
IllegalArgumentException: Attempting to edit an EntityProxy previously 
edited by another RequestContext.

My current workaround is to first obtain fresh instance (via 
RequestContext.find(EntityProxyIdP) and then use that (frozen) instance 
for performing my initial request (e.g. MyRequest.getSuggestions(P)). 
Drawback is that I have one unnecessary round-trip to the server.

Another solution wound be to refactor getSuggestions method to accept only 
id and rebuild full object on server side, but that seems to me as working 
around RequestFactory instead of using its provided services.

Least feasible solution is to propagate frozen proxy instance from top 
level editor all the way down editor hierarchy, but that leads to spaghetti 
code.

I know that RequestContext holds original (non-edit()ed, frozen) instance 
for every EntityProxy (for calculating diffs that it needs to send to 
server) - is there any way to get that original proxy from edited()-ed 
instance?

Any other suggestions?

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory: get original (frozen) proxy from edit()-ed instance

[Thomas Broyer]

On Tuesday, September 9, 2014 2:06:59 PM UTC+2, Gordan Krešić wrote:

 In some of my editors, I'm implementing ValueAwareEditorP and using 
 provided proxy value in setValue to obtain editor-specific data (most 
 simple example would be to get suggestions for some sub-editors). Problem 
 is that proxy instance that I was given in setValue is already edited in 
 driver's RequestContext, so I'm unable to use it as parameter in another 
 context (for obtaining suggestions). Error is well known 
 IllegalArgumentException: Attempting to edit an EntityProxy previously 
 edited by another RequestContext.

 My current workaround is to first obtain fresh instance (via 
 RequestContext.find(EntityProxyIdP) and then use that (frozen) instance 
 for performing my initial request (e.g. MyRequest.getSuggestions(P)). 
 Drawback is that I have one unnecessary round-trip to the server.

 Another solution wound be to refactor getSuggestions method to accept only 
 id and rebuild full object on server side, but that seems to me as working 
 around RequestFactory instead of using its provided services.


Sending the proxy will rebuild full object on server side anyway, so 
it's more a matter of taste (plus, whether you're OK returning suggestions 
for an object that's not in its persisted state: you could create a 
context, edit the object, change a few properties then call getSuggestions 
and fire, and the suggestions would be based on a modified entity, that 
won't be persisted).
Sending only the ID allows you to use an optimized request to load the 
object from database (but might lead to loading it twice if calling 
getSuggestions in the same context as one where such a proxy is edit()ed).

I would optimize for the common case and only pass the ID as an argument.
 


 Least feasible solution is to propagate frozen proxy instance from top 
 level editor all the way down editor hierarchy, but that leads to spaghetti 
 code.

 I know that RequestContext holds original (non-edit()ed, frozen) instance 
 for every EntityProxy (for calculating diffs that it needs to send to 
 server) - is there any way to get that original proxy from edited()-ed 
 instance?


Using AutoBeanUtils you can get the underlying AutoBean, then use getTag to 
get the parent AutoBean (use 
com.google.web.bindery.shared.impl.Constants.PARENT_OBJECT as the key), and 
finally call as() to view it as an EntityProxy.

Any other suggestions?


You could pass a ValueProxy as argument to your getSuggestions, and copy 
relevant properties from the EntityProxy. That way you don't need to load 
the object from the database on the server side, but you send all the data 
in the request, rather than just the entity ID.
On the other hand, as I said above, only passing the ID as an argument, you 
can optimize your database query.

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory: get original (frozen) proxy from edit()-ed instance

[Gordan Krešić]

On Tuesday, September 9, 2014 2:33:26 PM UTC+2, Thomas Broyer wrote:


 I know that RequestContext holds original (non-edit()ed, frozen) instance 
 for every EntityProxy (for calculating diffs that it needs to send to 
 server) - is there any way to get that original proxy from edited()-ed 
 instance?


 Using AutoBeanUtils you can get the underlying AutoBean, then use getTag 
 to get the parent AutoBean (use 
 com.google.web.bindery.shared.impl.Constants.PARENT_OBJECT as the key), and 
 finally call as() to view it as an EntityProxy.


Ninja Thomas to the rescue :)

Tnx.

Just for notice to future readers, Constants are in package 
com.google.web.bindery.requestfactory.shared.impl

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

requestfactory-apt.jar misvalidates java.util.Map?

[Gordan Krešić]

In my RequestContext a have a method with signature:

RequestVoid doSomething(java.util.MapEntityAProxy, 
java.util.ListEntityBProxy myMap);

for which I'm having error java.util.Map cannot be used here.

As per 
http://www.gwtproject.org/doc/latest/DevGuideRequestFactory.html#transportable 
myMap *should* be transportable. GWT compilation doesn't give me any error.

If I drop java.util.List from method and leave just 
java.util.MapEntityAProxy, EntityBProxy that validates ok.

GWT is 2.6.1

Is this a bug in requestfactory-apt.jar or am I missing something?

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: requestfactory-apt.jar misvalidates java.util.Map?

[Thomas Broyer]

Hmm, it might be that Maps are only supported as properties within proxies. 
Unit tests only cover that at least (and IIRC, we were aware of the 
limitation but nobody worked on that final step).

On Tuesday, September 9, 2014 6:07:47 PM UTC+2, Gordan Krešić wrote:

 In my RequestContext a have a method with signature:

 RequestVoid doSomething(java.util.MapEntityAProxy, 
 java.util.ListEntityBProxy myMap);

 for which I'm having error java.util.Map cannot be used here.

 As per 
 http://www.gwtproject.org/doc/latest/DevGuideRequestFactory.html#transportable
  
 myMap *should* be transportable. GWT compilation doesn't give me any 
 error.

 If I drop java.util.List from method and leave just 
 java.util.MapEntityAProxy, EntityBProxy that validates ok.

 GWT is 2.6.1

 Is this a bug in requestfactory-apt.jar or am I missing something?


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory: .with causes NPE on server if returned value is null

[Gordan Krešić]

Is it possible that this issue reemerged on Tomcat 8 using GWT 2.6.1?

Test case is working properly on Tomcat 7.0.32, but when the same app is 
started under Tomcat 8.0.9 described NPE is again thrown in server code. At 
first I suspected that it has something to do with POST payload encoding, 
but I couldn't find any discrepancies in my Tomcat 7/8 configurations. Is 
there anything else that I can try to investigate?

I'm not sure what is weirder: that this issue could be Tomcat related or 
that I'm the one stepping on it again :)

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Ignoring requestFactory responses on page reload

[Samin Pour]

Thomas,

Thank you for the detailed answer (as always) :)

Cheers
Samin

On Thursday, June 19, 2014 9:01:21 PM UTC+10, Thomas Broyer wrote:

 If you go to http://jsfiddle.net/vX8uK/ you'll see that you'll have an 
 onbeforeunload event (in GWT, Window.ClosingEvent) before the request is 
 abort with status=0, and then you have the onunload (in GWT, CloseEvent).
 That means you can listen to Window.ClosingEvent and set a flag to ignore 
 subsequent errors. In case you have a prompt in Window.ClosingEvent added 
 by other means (e.g. Places  Activities), then you'll have to handle the 
 case where the user canceled the navigation and unset your flag; you can do 
 that, for example, by resetting the flag in case of successful response, 
 and/or listen to some mouse or keyboard events.
 To centralize the flag processing, use a custom RequestTransport extending 
 the DefaultRequestTransport and wrapping the RequestCallback to deal with 
 the responses (at the RequestBuilder level, before they're transformed to 
 RequestFactory's Receiver calls)

 On Thursday, June 19, 2014 8:40:14 AM UTC+2, Samin Pour wrote:

 Hi Alberto,

 Thanks for your tip :) Unfortunately I can't inform the user to wait (I 
 mean the product description is to let the user to do what ever they want 
 without disturbing them) So I need to find the way to let the Receiver 
 class not to wait for the response.

 Any ideas?

 Thanks again
 Samin

 On Tuesday, June 17, 2014 5:04:50 PM UTC+10, Alberto Mancini wrote:

 Hi Samir,
 the page refresh should call the closinghandler cause a refresh is a 
 page unload followed by a load and the closing handler essentially 
 is a listener to 'onbeforeunload' event. 

 Cheers,
Alberto 

 Note: 
 there are issues with the returned message so if you go for a closing 
 handler read this also: 

 http://stackoverflow.com/questions/5398772/firefox-4-onbeforeunload-custom-message






 On Tue, Jun 17, 2014 at 7:10 AM, Samin Pour sam...@gmail.com wrote:

 Thanks Alberto :)

 Isn't this handler triggered for closing the Window? I'm just 
 refreshing a page which doesn't fire the associated event. Or am I missing 
 something?

 Thanks again
 Samin 


 On Friday, June 13, 2014 10:31:25 PM UTC+10, Alberto Mancini wrote:

 Hi,
 may be not a solution in your context but a choice can be also using 
 http://www.gwtproject.org/javadoc/latest/com/google/gwt/
 user/client/Window.html#addWindowClosingHandler%28com.
 google.gwt.user.client.Window.ClosingHandler%29
 to inform the user that should wait until the response is ready. 
 I think it is at least less dangerous than ignoring eventual errors. 

 Alberto. 





  -- 
 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 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-we...@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.




-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

GWT RequestFactory: IllegalArgumentException for setter only fields

[Arpit]

Why is it mandatory to have both getters and setters for a field in RF 
Proxy interfaces? For some fields (like plain text password), you want 
setters only.
e.g.

@ProxyFor(value = User.class)
public interface UserProxy extends ValueProxy {
void setPassword(String password);
}


User class has both getters and setters.


public class User implements Serializable {

private String password;

public String getPassword() {
return password;
}

public void setPassword(String password) {
this.password = password;
}



When I set the password on proxy, I get an IllegalArgumentException:

UserProxy user = userRequest.create(UserProxy.class);
user.setPassword(abc);



Above code results in following error:
java.lang.IllegalArgumentException: password
at 
com.google.web.bindery.autobean.shared.impl.AutoBeanCodexImpl.doCoderFor(AutoBeanCodexImpl.java:525)
at 
com.google.web.bindery.autobean.shared.impl.AbstractAutoBean.setProperty(AbstractAutoBean.java:276)
...
...

This error goes away if I add a 'getPassword()' method in UserProxy 
interface but that defeats the purpose. Any help is appreciated. 

Thanks,
Arpit

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RequestFactory: IllegalArgumentException for setter only fields

[Thomas Broyer]

See https://code.google.com/p/google-web-toolkit/issues/detail?id=5760

I don't get why having a getter defeats the purpose. Just because you 
have a getter does not mean there's a value to get.
You could also have a setPassword service method instead (you can 
probably use your existing User#setPassword using an 
InstanceRequestUserProxy,Void setPassword(String password) method)

On Monday, June 23, 2014 12:05:34 AM UTC+2, Arpit wrote:

 Why is it mandatory to have both getters and setters for a field in RF 
 Proxy interfaces? For some fields (like plain text password), you want 
 setters only.
 e.g.

 @ProxyFor(value = User.class)
 public interface UserProxy extends ValueProxy {
 void setPassword(String password);
 }


 User class has both getters and setters.

 
 public class User implements Serializable {
 
 private String password;
 
 public String getPassword() {
 return password;
 }
 
 public void setPassword(String password) {
 this.password = password;
 }



 When I set the password on proxy, I get an IllegalArgumentException:

 UserProxy user = userRequest.create(UserProxy.class);
 user.setPassword(abc);



 Above code results in following error:
 java.lang.IllegalArgumentException: password
 at 
 com.google.web.bindery.autobean.shared.impl.AutoBeanCodexImpl.doCoderFor(AutoBeanCodexImpl.java:525)
 at 
 com.google.web.bindery.autobean.shared.impl.AbstractAutoBean.setProperty(AbstractAutoBean.java:276)
 ...
 ...

 This error goes away if I add a 'getPassword()' method in UserProxy 
 interface but that defeats the purpose. Any help is appreciated. 

 Thanks,
 Arpit


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Ignoring requestFactory responses on page reload

[Samin Pour]

Hi Alberto,

Thanks for your tip :) Unfortunately I can't inform the user to wait (I 
mean the product description is to let the user to do what ever they want 
without disturbing them) So I need to find the way to let the Receiver 
class not to wait for the response.

Any ideas?

Thanks again
Samin

On Tuesday, June 17, 2014 5:04:50 PM UTC+10, Alberto Mancini wrote:

 Hi Samir,
 the page refresh should call the closinghandler cause a refresh is a page 
 unload followed by a load and the closing handler essentially 
 is a listener to 'onbeforeunload' event. 

 Cheers,
Alberto 

 Note: 
 there are issues with the returned message so if you go for a closing 
 handler read this also: 

 http://stackoverflow.com/questions/5398772/firefox-4-onbeforeunload-custom-message






 On Tue, Jun 17, 2014 at 7:10 AM, Samin Pour sam...@gmail.com 
 javascript: wrote:

 Thanks Alberto :)

 Isn't this handler triggered for closing the Window? I'm just refreshing 
 a page which doesn't fire the associated event. Or am I missing something?

 Thanks again
 Samin 


 On Friday, June 13, 2014 10:31:25 PM UTC+10, Alberto Mancini wrote:

 Hi,
 may be not a solution in your context but a choice can be also using 
 http://www.gwtproject.org/javadoc/latest/com/google/gwt/
 user/client/Window.html#addWindowClosingHandler%28com.
 google.gwt.user.client.Window.ClosingHandler%29
 to inform the user that should wait until the response is ready. 
 I think it is at least less dangerous than ignoring eventual errors. 

 Alberto. 





  -- 
 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 google-web-toolkit+unsubscr...@googlegroups.com javascript:.
 To post to this group, send email to google-we...@googlegroups.com 
 javascript:.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.




-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Ignoring requestFactory responses on page reload

[Thomas Broyer]

If you go to http://jsfiddle.net/vX8uK/ you'll see that you'll have an 
onbeforeunload event (in GWT, Window.ClosingEvent) before the request is 
abort with status=0, and then you have the onunload (in GWT, CloseEvent).
That means you can listen to Window.ClosingEvent and set a flag to ignore 
subsequent errors. In case you have a prompt in Window.ClosingEvent added 
by other means (e.g. Places  Activities), then you'll have to handle the 
case where the user canceled the navigation and unset your flag; you can do 
that, for example, by resetting the flag in case of successful response, 
and/or listen to some mouse or keyboard events.
To centralize the flag processing, use a custom RequestTransport extending 
the DefaultRequestTransport and wrapping the RequestCallback to deal with 
the responses (at the RequestBuilder level, before they're transformed to 
RequestFactory's Receiver calls)

On Thursday, June 19, 2014 8:40:14 AM UTC+2, Samin Pour wrote:

 Hi Alberto,

 Thanks for your tip :) Unfortunately I can't inform the user to wait (I 
 mean the product description is to let the user to do what ever they want 
 without disturbing them) So I need to find the way to let the Receiver 
 class not to wait for the response.

 Any ideas?

 Thanks again
 Samin

 On Tuesday, June 17, 2014 5:04:50 PM UTC+10, Alberto Mancini wrote:

 Hi Samir,
 the page refresh should call the closinghandler cause a refresh is a page 
 unload followed by a load and the closing handler essentially 
 is a listener to 'onbeforeunload' event. 

 Cheers,
Alberto 

 Note: 
 there are issues with the returned message so if you go for a closing 
 handler read this also: 

 http://stackoverflow.com/questions/5398772/firefox-4-onbeforeunload-custom-message






 On Tue, Jun 17, 2014 at 7:10 AM, Samin Pour sam...@gmail.com wrote:

 Thanks Alberto :)

 Isn't this handler triggered for closing the Window? I'm just refreshing 
 a page which doesn't fire the associated event. Or am I missing something?

 Thanks again
 Samin 


 On Friday, June 13, 2014 10:31:25 PM UTC+10, Alberto Mancini wrote:

 Hi,
 may be not a solution in your context but a choice can be also using 
 http://www.gwtproject.org/javadoc/latest/com/google/gwt/
 user/client/Window.html#addWindowClosingHandler%28com.
 google.gwt.user.client.Window.ClosingHandler%29
 to inform the user that should wait until the response is ready. 
 I think it is at least less dangerous than ignoring eventual errors. 

 Alberto. 





  -- 
 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 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-we...@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.




-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Ignoring requestFactory responses on page reload

[Alberto Mancini]

Hi Samir,
the page refresh should call the closinghandler cause a refresh is a page
unload followed by a load and the closing handler essentially
is a listener to 'onbeforeunload' event.

Cheers,
   Alberto

Note:
there are issues with the returned message so if you go for a closing
handler read this also:
http://stackoverflow.com/questions/5398772/firefox-4-onbeforeunload-custom-message






On Tue, Jun 17, 2014 at 7:10 AM, Samin Pour sami...@gmail.com wrote:

 Thanks Alberto :)

 Isn't this handler triggered for closing the Window? I'm just refreshing a
 page which doesn't fire the associated event. Or am I missing something?

 Thanks again
 Samin


 On Friday, June 13, 2014 10:31:25 PM UTC+10, Alberto Mancini wrote:

 Hi,
 may be not a solution in your context but a choice can be also using
 http://www.gwtproject.org/javadoc/latest/com/google/gwt/
 user/client/Window.html#addWindowClosingHandler%28com.
 google.gwt.user.client.Window.ClosingHandler%29
 to inform the user that should wait until the response is ready.
 I think it is at least less dangerous than ignoring eventual errors.

 Alberto.





  --
 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 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Ignoring requestFactory responses on page reload

[Samin Pour]

Thanks Alberto :)

Isn't this handler triggered for closing the Window? I'm just refreshing a 
page which doesn't fire the associated event. Or am I missing something?

Thanks again
Samin 


On Friday, June 13, 2014 10:31:25 PM UTC+10, Alberto Mancini wrote:

 Hi,
 may be not a solution in your context but a choice can be also using 

 http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/client/Window.html#addWindowClosingHandler%28com.google.gwt.user.client.Window.ClosingHandler%29
 to inform the user that should wait until the response is ready. 
 I think it is at least less dangerous than ignoring eventual errors. 

 Alberto. 







-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Ignoring requestFactory responses on page reload

[Samin Pour]

 Hi Everyone

My question might be very basic but couldn't find the answer anywhere. 

I'm working with requestFactory and send some requests to the server at 
almost the same time. One of these request takes couple of seconds, if the 
user refresh the page before the  response is ready,  obviously the 
onFailure() method of the Receiver class will be called to catch the 
Error (the message is just Server Error 0) and therefore throw an 
Exception into user's face.

Now this my question, can I ask the receiver not to wait for the response 
anymore? Or is there a way to check for all the awaiting receivers and tell 
them to ignore all incoming responses? I know I can ignore the 
ServerFailure on the OnFailure() method or just log it, but then I can't 
distinguish between a page refresh or real server malfunction.

Any ideas? Would be happy if somebody can help  :)

Cheers
Samin


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Ignoring requestFactory responses on page reload

[Alberto Mancini]

Hi,
may be not a solution in your context but a choice can be also using
http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/client/Window.html#addWindowClosingHandler%28com.google.gwt.user.client.Window.ClosingHandler%29
to inform the user that should wait until the response is ready.
I think it is at least less dangerous than ignoring eventual errors.

Alberto.








On Thu, Jun 12, 2014 at 9:22 AM, Samin Pour sami...@gmail.com wrote:

  Hi Everyone

 My question might be very basic but couldn't find the answer anywhere.

 I'm working with requestFactory and send some requests to the server at
 almost the same time. One of these request takes couple of seconds, if the
 user refresh the page before the  response is ready,  obviously the
 onFailure() method of the Receiver class will be called to catch the
 Error (the message is just Server Error 0) and therefore throw an
 Exception into user's face.

 Now this my question, can I ask the receiver not to wait for the response
 anymore? Or is there a way to check for all the awaiting receivers and tell
 them to ignore all incoming responses? I know I can ignore the
 ServerFailure on the OnFailure() method or just log it, but then I can't
 distinguish between a page refresh or real server malfunction.

 Any ideas? Would be happy if somebody can help  :)

 Cheers
 Samin


  --
 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 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

How to send data blob (i.e. the equivalent of a byte[]) with RequestFactory?

[TimOnGmail]

Hi all...

So I've got an app that's recording audio on the client side, and then 
sending it in chunks to the server.

Currently, I'm using a flash component (from the wami-recorder project), 
and that flash components is sending each chunk of audio data to a servlet.

This works fine, but I want to have the GWT app handle the send so that it 
can both manage the upload AND keep a buffer locally of audio data for 
playback later.

Reading various similar questions about sending byte[] arrays to server (or 
receiving them back), all I see is suggestions to use XMLHttpRequests from 
a native method (calling to a servlet), or using some FileUpload 
functionality (tweaks required).  I don't see anything about using 
RequestFactory to do it.

We *could* use GWT-RPC to do it, I suppose.

Does anyone know the EASIEST, most GWT-native way of doing this, without 
too many bells and whistles?

- Tim

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT, RequestFactory, MVP, JDO and DataNucleus

[Paul Mazzuca]

A good starting point for MVP is the MobileWebApp example packaged with 
GWT.   I have experience with MVP using JDO (DataNucleus), GWT 
RequestFactory, and AppEngine.  I have found this combination to be very 
fast and responsive for the client.  Scaling with AppEngine is not an issue 
if you design your model correctly.   I don't have any examples publicly 
available, however if you have more specific questions, I can try and 
answer them.  Overall, the setup of the architecture you are specifying can 
be a little bit of work in the short term, however as your project grows, 
both in code size and developers, it becomes much easier to manage than 
alternative methods, in my opinion. 

On Wednesday, April 2, 2014 3:24:09 AM UTC-7, Mic L wrote:

 Hello,
 Are there any examples how to use GWT, RequestFactory, MVP, JDO and 
 DataNucleus all together?

 Is MVP supported under GAE/J? How is it possible to scale MVP without 
 GAE/J?

 Thank you in advance.

 Mic


-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

GWT, RequestFactory, MVP, JDO and DataNucleus

[Mic L]

Hello,
Are there any examples how to use GWT, RequestFactory, MVP, JDO and 
DataNucleus all together?

Is MVP supported under GAE/J? How is it possible to scale MVP without GAE/J?

Thank you in advance.

Mic

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory Validation Tool

[Thomas Broyer]

Eclipse (thus STS) is quite bad at annotation processing. It regularly 
fails (forcing you to disable and re-enable it, and/or change the output 
folder and changing it back again).
Try using the maven-processor-plugin (and configure maven-compiler-plugin 
with procnone/proc) and configure m2e-apt to delegate to the plugin (or 
manually run Maven generate-sources)

On Thursday, March 27, 2014 6:57:51 PM UTC+1, joja wrote:

 Hello, 
 I have a question: Is it necessary to do a maven build (package) in Spring 
 Tool Suite in order to run the RequestFactory Validation Tool 
 to validate the GWT ProxyForName and ServiceName annotations? 

 Without only  doing a Project - clean - build I get this error: 
  RequestFactory Validation Tool must be run... 

 anybody knows how to fix this ? 

 I followed: 

 http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation
  
 but this is not enough... 

 Thanks! 



-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: RequestFactory Validation Tool

[Thomas Broyer]

[+cc google-web-toolkit@googlegroups]

If Eclipse (and m2e-apt) is correctly configured to do the annotation
processing, and doesn't fail at doing it, then yes you should be able to
use a “pure Eclipse” workflow, with no need to invoke Maven.


On Fri, Mar 28, 2014 at 1:28 PM, joris datken...@hotmail.com wrote:

 Is it, when i have done your modifications, possible to run my application
 with only doing Project - clean -build? or do i still have to do a maven
 build (goal package)?

 Thanks..


 --
 Date: Fri, 28 Mar 2014 03:30:44 -0700
 From: t.bro...@gmail.com
 To: google-web-toolkit@googlegroups.com
 CC: Google-Web-Toolkit@googlegroups.com; datken...@hotmail.com
 Subject: Re: RequestFactory Validation Tool

 Eclipse (thus STS) is quite bad at annotation processing. It regularly
 fails (forcing you to disable and re-enable it, and/or change the output
 folder and changing it back again).
 Try using the maven-processor-plugin (and configure maven-compiler-plugin
 with procnone/proc) and configure m2e-apt to delegate to the plugin (or
 manually run Maven generate-sources)

 On Thursday, March 27, 2014 6:57:51 PM UTC+1, joja wrote:

 Hello,
 I have a question: Is it necessary to do a maven build (package) in Spring
 Tool Suite in order to run the RequestFactory Validation Tool
 to validate the GWT ProxyForName and ServiceName annotations?

 Without only  doing a Project - clean - build I get this error:
  RequestFactory Validation Tool must be run...

 anybody knows how to fix this ?

 I followed:
 http://code.google.com/p/google-web-toolkit/wiki/
 RequestFactoryInterfaceValidation
 but this is not enough...

 Thanks!




-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

RequestFactory Validation Tool

[joja]

Hello,
I have a question: Is it necessary to do a maven build (package) in Spring
Tool Suite in order to run the RequestFactory Validation Tool
to validate the GWT ProxyForName and ServiceName annotations?

Without only  doing a Project - clean - build I get this error:
 RequestFactory Validation Tool must be run... 

anybody knows how to fix this ?

I followed:
http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation
but this is not enough...

Thanks!

-- 
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.