Re: GWT 2.7.0 RequestFactory + Spring + JPA + Hibernate optimistic locking implementation
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
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
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
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
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
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
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.
Re: GWT 2.4.0+ RequestFactory EntityProxy Validation
Thank you. I will implement one of the strategies mentioned there. Jens jens.nehlme...@gmail.com wrote:Thats a known quirk. Take a look at: https://groups.google.com/d/topic/google-web-toolkit/d9gZMff7RlI/discussion -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/cl6a6utMBkcJ. 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 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.
Re: GWT 2.4.0+ RequestFactory EntityProxy Validation
I have found out a few more details relating to this problem.
I have an Editor that implements LeafValueEditorListPhoneProxy.
When a user wants to add a new PhoneProxy to my editor I call
context.create().
Sometimes the user cancels the process.
When the user cancels the process the PhoneProxy created remains in the
list of beans that are sent to the server for constraint validation. This
always fails because the PhoneProxy has been cleared out by the cancel
operation.
It seems like there may be a bug here. The canceled ProxyPhone bean shows
up in the list to be validated but when I override the
ServiceLayerDecorator.validate method bypassing validation it is removed
prior to the persist() method.
Also, Is there a way for me to tell the context to discard the canceled
PhoneProxy?
Thanks!
Steve
On Monday, November 12, 2012 1:44:15 PM UTC-7, Steven Jardine wrote:
When trying to save a complex EntityProxy I receive validation errors on
empty entities that should not be there. When I inspect the entity to be
sent to the server I see a total of 6 entities to be saved but when I
inspect the IdToEntityMap that is used for validation I see a total of 9
entities to be validated. The 3 additional entities are just empty
entities. If I disable validation through my ServiceLayerDecorator the
empty entities do not show up on the server, just the entities I submitted.
Here is the entities I see when validate is called:
{1@1...@com.mjnservices.lms.core.shared.model.proxy.EmailProxy=com.google.web.bindery.autobean.vm.impl.ProxyAutoBean@42538425,
2@1...@com.mjnservices.lms.core.shared.model.proxy.PhoneProxy=com.google.web.bindery.autobean.vm.impl.ProxyAutoBean@33d2158c,
3@1...@com.mjnservices.lms.core.shared.model.proxy.AddressProxy=com.google.web.bindery.autobean.vm.impl.ProxyAutoBean@58d48756,
5@0...@com.mjnservices.lms.core.shared.model.proxy.PhoneProxy=com.google.web.bindery.autobean.vm.impl.ProxyAutoBean@69014ca9,
1@0...@com.mjnservices.lms.core.shared.model.proxy.EmailProxy=com.google.web.bindery.autobean.vm.impl.ProxyAutoBean@5450211a,
1@0...@com.mjnservices.lms.core.shared.model.proxy.AddressProxy=com.google.web.bindery.autobean.vm.impl.ProxyAutoBean@35ca01cb,
3@0...@com.mjnservices.lms.core.shared.model.proxy.PhoneProxy=com.google.web.bindery.autobean.vm.impl.ProxyAutoBean@58ad5d34,
3@0...@com.mjnservices.lms.core.shared.model.proxy.ContactProxy=com.google.web.bindery.autobean.vm.impl.ProxyAutoBean@78b8f5f5,
3@0...@com.mjnservices.lms.core.shared.model.proxy.RegisteredUserProxy=com.google.web.bindery.autobean.vm.impl.ProxyAutoBean@f62b12d}
The first 3 are the empty ones and the last 6 are the ones I submitted.
Does anyone have any ideas why I would have additional entities present for
validation?
Thanks!
Steve
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/mwOF13XSJIwJ.
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.
Re: GWT 2.4.0+ RequestFactory EntityProxy Validation
Thats a known quirk. Take a look at: https://groups.google.com/d/topic/google-web-toolkit/d9gZMff7RlI/discussion -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/cl6a6utMBkcJ. 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.
Re: GWT and RequestFactory
This was recently discussed in this GWT Group post.https://groups.google.com/forum/?fromgroups#!topic/google-web-toolkit/NStp5K8Ej2o On Tuesday, July 3, 2012 6:18:09 AM UTC-4, nessrinovitta wrote: Hello everyone ! Does the RequestFactory API allow us to build Web Services with the REST style of architecture ? help plzz ! -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/b0npudR38c4J. 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.
Re: GWT with RequestFactory ::::: com.google.appengine.tools.development.LocalResourceFileServlet doGet WARNING: No file found for: /gwtRequest
Okay, I have some questions: 1) Have you developed a web application? 2) What framework, pattern or technology you have used for development? Spring or EJB3? I ask these questions, because the development will be the same, using GWT, JSF, Flex or pure html. So I advise you before making any crud screen or screens that access data from a database, define how it will service layer, since there is thousands of how to implement for both and you will find people who will say that Spring is better and EBJ3 others that are better, but you aconcelho to do with which one you identify. Below is some links about GWT and EJB3 with the RF: http://www.javacodegeeks.com/2010/09/gwt-ejb3-maven-jboss-51-integration.html http://cleancodematters.wordpress.com/2011/06/04/tutorial-gwt-request-factory-part-i/ Any questions just post. Thiago Borges Martins Systems analyst On 26 abr, 02:47, laxman lingampally lingampall.lax...@gmail.com wrote: hi thinks a lot first I want to thanks you for these superb on GWT RequestFactory, they really helped me getting started quickly. i don't now about symbolMaps , i think it is google datastore, but i am trying to store in mysql database. i created a web application with GWT RequestFactory and for persistence i use the hibernate and mysql datastore but , to transfert data between server and client i should use mysql or sql server but i don't know how can i do it, so i will be grateful if someone can help me with example or any information please help me. Thanks Regards. laxman On Wed, Apr 25, 2012 at 7:20 PM, thiago borges martins tborgesmart...@gmail.com wrote: Make the following change to your web.xml and see if it will funionar: servlet servlet-namerequestFactoryServlet/servlet-name servlet- classcom.google.web.bindery.requestfactory.server.RequestFactoryServlet/ servlet-class init-param param-namesymbolMapsDirectory/param-name !-- You'll need to compile with -extras and move the symbolMaps directory to this location if you want stack trace deobfuscation to work -- param-valueWEB-INF/classes/symbolMaps//param-value param-nameuserInfoClass/param-name param-valuecom.dynatech.server.domain.NameData/param-value /init-param /servlet servlet-mapping servlet-namerequestFactoryServlet/servlet-name url-pattern/gwtRequest/url-pattern /servlet-mapping this stretch you need to check where the GWT is generating a compilation of sources, perhaps because the problem is that he is not able to find the java-script compiled. In my case it's in this directory url-pattern/br.com.tbm.consult.Application/gwtRequest/ url- pattern To identify the directory you just go in the target folder after compilation if you are using maven. if you are using the standard build of gwt you should be in the war directory. Any problems just post. On 25 abr, 07:19, laxman lingampally lingampall.lax...@gmail.com wrote: Hi all, please help me. i am wworking on gwt woth requestfactory, at that time getting above error. *here web.xml i configared .RequestFactoryServlet but it is internally calling LocalResourceFileServlet.* Why itis happening?? web.xml. servlet servlet-namerequestFactoryServlet/servlet-name servlet-classcom.google.web.bindery.requestfactory.server.RequestFactoryServlet/servlet-class init-param param-nameuserInfoClass/param-name param-valuecom.dynatech.server.domain.NameData/param-value /init-param /servlet servlet-mapping servlet-namerequestFactoryServlet/servlet-name url-pattern/gwtRequest/url-pattern /servlet-mapping thanks in advace, thanks regards. laxman -- 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 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.
Re: GWT with RequestFactory using Hibernate !!
What is your doubt in relation to RF and hibernate? because the RF will communicate with your service and domain. Part of persistence will continue in the same way the only difference is that you will have an interface that represents the service and an interface for the domain as the link below: https://developers.google.com/web-toolkit/doc/latest/DevGuideRequestFactory any questions just ask. On 25 abr, 08:01, laxman lingampally lingampall.lax...@gmail.com wrote: Hi all, please tell me How it is work. Thaks Regards. Laxman -- 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.
Re: GWT with RequestFactory ::::: com.google.appengine.tools.development.LocalResourceFileServlet doGet WARNING: No file found for: /gwtRequest
Make the following change to your web.xml and see if it will funionar: servlet servlet-namerequestFactoryServlet/servlet-name servlet- classcom.google.web.bindery.requestfactory.server.RequestFactoryServlet/ servlet-class init-param param-namesymbolMapsDirectory/param-name !-- You'll need to compile with -extras and move the symbolMaps directory to this location if you want stack trace deobfuscation to work -- param-valueWEB-INF/classes/symbolMaps//param-value param-nameuserInfoClass/param-name param-valuecom.dynatech.server.domain.NameData/param-value /init-param /servlet servlet-mapping servlet-namerequestFactoryServlet/servlet-name url-pattern/gwtRequest/url-pattern /servlet-mapping this stretch you need to check where the GWT is generating a compilation of sources, perhaps because the problem is that he is not able to find the java-script compiled. In my case it's in this directory url-pattern/br.com.tbm.consult.Application/gwtRequest/ url- pattern To identify the directory you just go in the target folder after compilation if you are using maven. if you are using the standard build of gwt you should be in the war directory. Any problems just post. On 25 abr, 07:19, laxman lingampally lingampall.lax...@gmail.com wrote: Hi all, please help me. i am wworking on gwt woth requestfactory, at that time getting above error. *here web.xml i configared .RequestFactoryServlet but it is internally calling LocalResourceFileServlet.* Why itis happening?? web.xml. servlet servlet-namerequestFactoryServlet/servlet-name servlet-classcom.google.web.bindery.requestfactory.server.RequestFactoryServlet/servlet-class init-param param-nameuserInfoClass/param-name param-valuecom.dynatech.server.domain.NameData/param-value /init-param /servlet servlet-mapping servlet-namerequestFactoryServlet/servlet-name url-pattern/gwtRequest/url-pattern /servlet-mapping thanks in advace, thanks regards. laxman -- 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.
Re: GWT with RequestFactory ::::: com.google.appengine.tools.development.LocalResourceFileServlet doGet WARNING: No file found for: /gwtRequest
hi thinks a lot first I want to thanks you for these superb on GWT RequestFactory, they really helped me getting started quickly. i don't now about symbolMaps , i think it is google datastore, but i am trying to store in mysql database. i created a web application with GWT RequestFactory and for persistence i use the hibernate and mysql datastore but , to transfert data between server and client i should use mysql or sql server but i don't know how can i do it, so i will be grateful if someone can help me with example or any information please help me. Thanks Regards. laxman On Wed, Apr 25, 2012 at 7:20 PM, thiago borges martins tborgesmart...@gmail.com wrote: Make the following change to your web.xml and see if it will funionar: servlet servlet-namerequestFactoryServlet/servlet-name servlet- classcom.google.web.bindery.requestfactory.server.RequestFactoryServlet/ servlet-class init-param param-namesymbolMapsDirectory/param-name !-- You'll need to compile with -extras and move the symbolMaps directory to this location if you want stack trace deobfuscation to work -- param-valueWEB-INF/classes/symbolMaps//param-value param-nameuserInfoClass/param-name param-valuecom.dynatech.server.domain.NameData/param-value /init-param /servlet servlet-mapping servlet-namerequestFactoryServlet/servlet-name url-pattern/gwtRequest/url-pattern /servlet-mapping this stretch you need to check where the GWT is generating a compilation of sources, perhaps because the problem is that he is not able to find the java-script compiled. In my case it's in this directory url-pattern/br.com.tbm.consult.Application/gwtRequest/ url- pattern To identify the directory you just go in the target folder after compilation if you are using maven. if you are using the standard build of gwt you should be in the war directory. Any problems just post. On 25 abr, 07:19, laxman lingampally lingampall.lax...@gmail.com wrote: Hi all, please help me. i am wworking on gwt woth requestfactory, at that time getting above error. *here web.xml i configared .RequestFactoryServlet but it is internally calling LocalResourceFileServlet.* Why itis happening?? web.xml. servlet servlet-namerequestFactoryServlet/servlet-name servlet-classcom.google.web.bindery.requestfactory.server.RequestFactoryServlet/servlet-class init-param param-nameuserInfoClass/param-name param-valuecom.dynatech.server.domain.NameData/param-value /init-param /servlet servlet-mapping servlet-namerequestFactoryServlet/servlet-name url-pattern/gwtRequest/url-pattern /servlet-mapping thanks in advace, thanks regards. laxman -- 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 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.
Re: GWT 2.4 RequestFactory Exception when receiving data from BackEnd
Caused by: java.lang.RuntimeException: Server Error: null at com.google.web.bindery.requestfactory.shared.Receiver.onFailure(Receiver.java:44) So I would say you most likely have a Nullpointer Exception on server side while executing a service method. -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/AO0z4c9Oiw8J. 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.
Re: GWT 2.4 RequestFactory Exception when receiving data from BackEnd
Have u tried to override the onFailure and onviolation methods in ur Receiver? They give you better clarity on the error? Do u any constraints/ validation on the entity? If they are not met your request would fail Thanks Ashwin Sent from my iPhone On Sep 15, 2011, at 1:24 PM, POODevelopper imra...@gmail.com wrote: Finally RequestFactory work with Spring back end, but I have another issue : Is that i receive an exception on client when he process the data, the server service is call but I get this exception on client. Everything is set up correctly the Proxy Value Object, the Request Object and the RequestFactory. I just can't determine the cause for this exception it is making me crazy !!! I tired to create a method on the service which return a simple String and it work but for the complex type GxpensesTransaction no chance. Below the exception I'm getting : SEVERE: One or more exceptions caught, see full set in UmbrellaException#getCauses com.google.web.bindery.event.shared.UmbrellaException: One or more exceptions caught, see full set in UmbrellaException#getCauses at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext.fail(AbstractRequestContext.java: 727) at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext $StandardPayloadDialect.processPayload(AbstractRequestContext.java: 331) at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext $5.onTransportSuccess(AbstractRequestContext.java:1108) at com.google.web.bindery.requestfactory.gwt.client.DefaultRequestTransport $1.onResponseReceived(DefaultRequestTransport.java:136) at com.google.gwt.http.client.Request.fireOnResponseReceived(Request.java: 287) at com.google.gwt.http.client.RequestBuilder $1.onReadyStateChange(RequestBuilder.java:395) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:597) at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java: 103) at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java: 71) at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java: 172) at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessagesWhileWaitingForReturn(BrowserChannelServer.java: 337) at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java: 218) at com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java: 136) at com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java: 561) at com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java: 269) at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java: 91) at com.google.gwt.core.client.impl.Impl.apply(Impl.java) at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:213) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:597) at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java: 103) at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java: 71) at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java: 172) at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java: 292) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java: 546) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java: 363) at java.lang.Thread.run(Thread.java:680) Caused by: java.lang.RuntimeException: Server Error: null at com.google.web.bindery.requestfactory.shared.Receiver.onFailure(Receiver.java: 44) at org.gxpenses.client.activity.AccountActivity $1.onFailure(AccountActivity.java:81) at com.google.web.bindery.requestfactory.shared.impl.AbstractRequest.onFail(AbstractRequest.java: 118) at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext.fail(AbstractRequestContext.java: 707) at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext $StandardPayloadDialect.processPayload(AbstractRequestContext.java: 331) at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext $5.onTransportSuccess(AbstractRequestContext.java:1108) at com.google.web.bindery.requestfactory.gwt.client.DefaultRequestTransport $1.onResponseReceived(DefaultRequestTransport.java:136) at com.google.gwt.http.client.Request.fireOnResponseReceived(Request.java:
Re: GWT 2.4 RequestFactory Exception when receiving data from BackEnd
I executed a JUnit Test on the services and there was no null pointer
Exception.
Also there is no constraint validation on the Entity. How can I make
the exception message more clear ??
Below the Code of the entity :
@Document(collection=transactions)
public class Transaction implements Serializable {
private static final long serialVersionUID = 4999532858364711856L;
@Id private ObjectId id;
@SuppressWarnings(unused)
private String strId;
@Indexed private ObjectId accountId;
@Indexed private ObjectId destTransactionId;
private String type;
private Date date;
private Double amount;
private String payee;
private String tags;
public Transaction() {
date = new Date();
}
public Transaction(String type, Date date, Double amount, String
payee) {
super();
this.type = type;
this.date = date;
this.amount = amount;
this.payee = payee;
}
public ObjectId getId() {
return id;
}
public void setId(ObjectId id) {
this.id = id;
}
public ObjectId getAccountId() {
return accountId;
}
public void setAccountId(ObjectId accountId) {
this.accountId = accountId;
}
public ObjectId getDestTransactionId() {
return destTransactionId;
}
public void setDestTransactionId(ObjectId destTransactionId) {
this.destTransactionId = destTransactionId;
}
public String getType() {
return type;
}
public void setType(String type) {
this.type = type;
}
public Date getDate() {
return date;
}
public void setDate(Date date) {
this.date = date;
}
public Double getAmount() {
return amount;
}
public void setAmount(Double amount) {
this.amount = amount;
}
public String getPayee() {
return payee;
}
public void setPayee(String payee) {
this.payee = payee;
}
public String getTags() {
return tags;
}
public void setTags(String tags) {
this.tags = tags;
}
public ListString getSplitedTags() {
ListString tagsList = null;
if(tags != null)
tagsList = Arrays.asList(tags.split( ));
return tagsList == null ? new ArrayListString() : tagsList;
}
public String getStrId() {
return getId().toStringMongod();
}
public void setStrId(String strId) {
this.strId = strId;
}
}
On Sep 15, 8:02 am, Ashwin Desikan ashwin.desi...@gmail.com wrote:
Have u tried to override the onFailure and onviolation methods in ur
Receiver? They give you better clarity on the error?
Do u any constraints/ validation on the entity? If they are not met your
request would fail
Thanks
Ashwin
Sent from my iPhone
On Sep 15, 2011, at 1:24 PM, POODevelopper imra...@gmail.com wrote:
Finally RequestFactory work with Spring back end, but I have another
issue : Is that i receive an exception on client when he process the
data, the server service is call but I get this exception on client.
Everything is set up correctly the Proxy Value Object, the Request
Object and the RequestFactory. I just can't determine the cause for
this exception it is making me crazy !!!
I tired to create a method on the service which return a simple String
and it work but for the complex type GxpensesTransaction no chance.
Below the exception I'm getting :
SEVERE: One or more exceptions caught, see full set in
UmbrellaException#getCauses
com.google.web.bindery.event.shared.UmbrellaException: One or more
exceptions caught, see full set in UmbrellaException#getCauses
at
com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext.fa
il(AbstractRequestContext.java:
727)
at
com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext
$StandardPayloadDialect.processPayload(AbstractRequestContext.java:
331)
at
com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext
$5.onTransportSuccess(AbstractRequestContext.java:1108)
at
com.google.web.bindery.requestfactory.gwt.client.DefaultRequestTransport
$1.onResponseReceived(DefaultRequestTransport.java:136)
at
com.google.gwt.http.client.Request.fireOnResponseReceived(Request.java:
287)
at com.google.gwt.http.client.RequestBuilder
$1.onReadyStateChange(RequestBuilder.java:395)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
Re: GWT 2.4 RequestFactory Exception when receiving data from BackEnd
Put a breakpoint in com.google.web.bindery.requestfactory.server.DefaultExceptionHandler, or provide your own ExceptionHandler to the RequestFactoryServlet to log the exceptions (with their stacktrace). -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/lyVrUjpEtEkJ. 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.
Re: GWT 2.4 RequestFactory Exception when receiving data from BackEnd
Thank you guys for the hint, I used this article to set up a proper Exception handling : http://cleancodematters.wordpress.com/2011/05/29/improved-exceptionhandling-with-gwts-requestfactory/ I have found that the Property destTransactionId was Null. GWT need to handle Exceptions well Out of the Box. For a beginner it's really difficult. On Sep 15, 10:54 am, Thomas Broyer t.bro...@gmail.com wrote: Put a breakpoint in com.google.web.bindery.requestfactory.server.DefaultExceptionHandler, or provide your own ExceptionHandler to the RequestFactoryServlet to log the exceptions (with their stacktrace). -- 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.
Re: GWT 2.4: RequestFactory versus GWT-RPC
+1 On Jul 18, 9:25 am, Elhanan Maayan elh.mailg...@gmail.com wrote: i think google should clarify it's own philosophy in a special article in the developer guide, because as of right now , there way too many black holes on the subject of transports and frameworks that use them GWT-RPC JSON RequestFactory AutoBeans XML. i know that autobeans and rtf both uses json under, but that would only clarify the situation. an FAQ and a table matrix should be created specifying how each technology is based used AND it's future directions (like for example the use GWT-RPC in android, possible break in future version of java etc... , and other platforms compared to other technologies) also some basic benchmarks would be usedfull. On Mon, Jul 18, 2011 at 10:08 AM, Michel Jonker michel.jon...@e-office.comwrote: Hi, Thanks for this encouragement. I am a newby at GWT/App Engine and want to start creating applications that follow Google's philiosofy. Later (when I am more comfortable) I probably can add my own patterns and stuff. The main lesson I learned from this discussion is that GWT-RPC comes with serialization 'challenges'. Which is not such a problem when you work with web applications but is a much bigger issue when you have distributed apps (like Android connected to App Engine). Thanks for all the replies Michel On 14 jul, 22:24, Aidan O'Kelly aida...@gmail.com wrote: I'm using RequestFactory for a 'non-data-orientated' app and its works very nicely. Chained method invocation: MyServiceRC serviceRequest = appRequestFactory.MyServiceRC(); serviceRequest.giveMeAString().to(stringReceiver); if (needPojo == true) serviceRequest.giveMeAPojo().to(pojoReceiver); // Pojo would be a ValueProxy for example. // Now fire both methods in one RPC request, and do whatever processing we want once both completed. serviceRequest.fire(processStringAndPojoReceiver); A pretty nice way to call server side methods. You are certainly not restricted just to persisting and retrieving datastore objects with RequestFactory. On Thu, Jul 14, 2011 at 10:36 AM, Michel Jonker michel.jon...@e-office.com wrote: Hi, This is a cross post from the AppEngine group, but since I got no response there, I want to try this group. I am trying to figure out the best practise to consume my App Engine services from both Android and GWT. Since the services are not that data oriented, I first considered GWT- RPC. But given the fact that the GPE 2.4 sample project voor Android comes with RequestFactory, I am leaning towards this approach. I was hoping someone could validate this 'best practise' : When you have both Android and GWT consumers of your App Engine service, apply the RequestFactory pattern. TIA Michel Jonker -- 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 athttp:// 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 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 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.
Re: GWT 2.2.0 RequestFactory + Spring 3.0.x Integration (SOLVED) - NEW LINK
Works like charm, thanks a lot for the post! -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/C6JsuJVunwYJ. 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.
Re: GWT 2.2.0 RequestFactory + Spring 3.0.x Integration (SOLVED) - NEW LINK
Thanks for share! 2011/8/10 j.singh.developer j.singh.develo...@gmail.com The blog discussed in one of my post is no longer in production. If you looking for the GWT + Spring integration solution, please visit this link http://jsinghfoss.wordpress.com/2011/08/10/gwt-2-2-0-requestfactory-spring-3-0-x-integration/ -- 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 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.
Re: GWT 2.4: RequestFactory versus GWT-RPC
Hi, Thanks for this encouragement. I am a newby at GWT/App Engine and want to start creating applications that follow Google's philiosofy. Later (when I am more comfortable) I probably can add my own patterns and stuff. The main lesson I learned from this discussion is that GWT-RPC comes with serialization 'challenges'. Which is not such a problem when you work with web applications but is a much bigger issue when you have distributed apps (like Android connected to App Engine). Thanks for all the replies Michel On 14 jul, 22:24, Aidan O'Kelly aida...@gmail.com wrote: I'm using RequestFactory for a 'non-data-orientated' app and its works very nicely. Chained method invocation: MyServiceRC serviceRequest = appRequestFactory.MyServiceRC(); serviceRequest.giveMeAString().to(stringReceiver); if (needPojo == true) serviceRequest.giveMeAPojo().to(pojoReceiver); // Pojo would be a ValueProxy for example. // Now fire both methods in one RPC request, and do whatever processing we want once both completed. serviceRequest.fire(processStringAndPojoReceiver); A pretty nice way to call server side methods. You are certainly not restricted just to persisting and retrieving datastore objects with RequestFactory. On Thu, Jul 14, 2011 at 10:36 AM, Michel Jonker michel.jon...@e-office.com wrote: Hi, This is a cross post from the AppEngine group, but since I got no response there, I want to try this group. I am trying to figure out the best practise to consume my App Engine services from both Android and GWT. Since the services are not that data oriented, I first considered GWT- RPC. But given the fact that the GPE 2.4 sample project voor Android comes with RequestFactory, I am leaning towards this approach. I was hoping someone could validate this 'best practise' : When you have both Android and GWT consumers of your App Engine service, apply the RequestFactory pattern. TIA Michel Jonker -- 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 athttp://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 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.
Re: GWT 2.4: RequestFactory versus GWT-RPC
i think google should clarify it's own philosophy in a special article in the developer guide, because as of right now , there way too many black holes on the subject of transports and frameworks that use them GWT-RPC JSON RequestFactory AutoBeans XML. i know that autobeans and rtf both uses json under, but that would only clarify the situation. an FAQ and a table matrix should be created specifying how each technology is based used AND it's future directions (like for example the use GWT-RPC in android, possible break in future version of java etc... , and other platforms compared to other technologies) also some basic benchmarks would be usedfull. On Mon, Jul 18, 2011 at 10:08 AM, Michel Jonker michel.jon...@e-office.comwrote: Hi, Thanks for this encouragement. I am a newby at GWT/App Engine and want to start creating applications that follow Google's philiosofy. Later (when I am more comfortable) I probably can add my own patterns and stuff. The main lesson I learned from this discussion is that GWT-RPC comes with serialization 'challenges'. Which is not such a problem when you work with web applications but is a much bigger issue when you have distributed apps (like Android connected to App Engine). Thanks for all the replies Michel On 14 jul, 22:24, Aidan O'Kelly aida...@gmail.com wrote: I'm using RequestFactory for a 'non-data-orientated' app and its works very nicely. Chained method invocation: MyServiceRC serviceRequest = appRequestFactory.MyServiceRC(); serviceRequest.giveMeAString().to(stringReceiver); if (needPojo == true) serviceRequest.giveMeAPojo().to(pojoReceiver); // Pojo would be a ValueProxy for example. // Now fire both methods in one RPC request, and do whatever processing we want once both completed. serviceRequest.fire(processStringAndPojoReceiver); A pretty nice way to call server side methods. You are certainly not restricted just to persisting and retrieving datastore objects with RequestFactory. On Thu, Jul 14, 2011 at 10:36 AM, Michel Jonker michel.jon...@e-office.com wrote: Hi, This is a cross post from the AppEngine group, but since I got no response there, I want to try this group. I am trying to figure out the best practise to consume my App Engine services from both Android and GWT. Since the services are not that data oriented, I first considered GWT- RPC. But given the fact that the GPE 2.4 sample project voor Android comes with RequestFactory, I am leaning towards this approach. I was hoping someone could validate this 'best practise' : When you have both Android and GWT consumers of your App Engine service, apply the RequestFactory pattern. TIA Michel Jonker -- 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 athttp:// 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 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 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.
Re: GWT 2.4: RequestFactory versus GWT-RPC
woo hoo! mabye i'll get to convince our CTO to use RF, he wants to avoid that becouse he says if the client will be in sliverlight, that won't work. On Fri, Jul 15, 2011 at 7:27 PM, David Chandler drfibona...@google.comwrote: We jumped the gun a bit, but 2.4 is pretty close to becoming latest :-) /dmc On Friday, July 15, 2011, Thomas Broyer wrote: Hmm, shouldn't it have been for trunk? I believe @ExtraTypes and polymorphism support are not in 2.3, only in the upcoming 2.4. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/AClSV62TkrQJ. 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. -- David Chandler Developer Programs Engineer, GWT+GAE w: http://code.google.com/ b: http://turbomanage.wordpress.com/ b: http://googlewebtoolkit.blogspot.com/ t: @googledevtools -- 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 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.
Re: GWT 2.4: RequestFactory versus GWT-RPC
Hmm, shouldn't it have been for trunk? I believe @ExtraTypes and polymorphism support are not in 2.3, only in the upcoming 2.4. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/AClSV62TkrQJ. 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.
Re: GWT 2.4: RequestFactory versus GWT-RPC
considering it's talking about requestfactory-server.jar hmm, pretty much yea:) (is 2.4 THAT close?) On Fri, Jul 15, 2011 at 11:38 AM, Thomas Broyer t.bro...@gmail.com wrote: Hmm, shouldn't it have been for trunk? I believe @ExtraTypes and polymorphism support are not in 2.3, only in the upcoming 2.4. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/AClSV62TkrQJ. 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 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.
Re: GWT 2.4: RequestFactory versus GWT-RPC
We jumped the gun a bit, but 2.4 is pretty close to becoming latest :-)
/dmc
On Friday, July 15, 2011, Thomas Broyer wrote:
Hmm, shouldn't it have been for trunk? I believe @ExtraTypes and
polymorphism support are not in 2.3, only in the upcoming 2.4.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/AClSV62TkrQJ.
To post to this group, send email to
google-web-toolkit@googlegroups.comjavascript:_e({}, 'cvml',
'google-web-toolkit@googlegroups.com');
.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com javascript:_e({}, 'cvml',
'google-web-toolkit%2bunsubscr...@googlegroups.com');.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
--
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/
b: http://turbomanage.wordpress.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools
--
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.
Re: GWT 2.4: RequestFactory versus GWT-RPC
If you use GWT-RPC and JPA (with Hibernate provider) you will have serialization problemshttp://code.google.com/intl/es/webtoolkit/articles/using_gwt_with_hibernate.html. To solution this, you have this alternatives: 1) Use DTO 2) Use Gilead 3) Use a Filterhttp://books.google.com/books?id=OG816JSZYVcCpg=PA159lpg=PA159dq=hibernate+filter+gwtsource=blots=BM1BDJyWl9sig=Q18Zdh2kOVQmWu2n8L4IpGs-uIohl=esei=VxIfTtrhMsOCgAeY_oyYAwsa=Xoi=book_resultct=resultresnum=4ved=0CDkQ6AEwAw#v=onepageq=hibernate%20filter%20gwtf=false. You can read this http://groups.google.com/group/google-web-toolkit-contributors/msg/b3ccc61d4eebd21ctoo and herehttp://groups.google.com/group/google-web-toolkit/browse_thread/thread/7e46e8c33e7ee5dayou have a sample implementation with GWT 2.3.0. With RF you will no have this problem and is efficient. But as you said, is oriented to data services and (to me) is more complicated. GWT-RPC is more general and you will write less code. Hope helps to decide. 2011/7/14 Michel Jonker michel.jon...@e-office.com Hi, This is a cross post from the AppEngine group, but since I got no response there, I want to try this group. I am trying to figure out the best practise to consume my App Engine services from both Android and GWT. Since the services are not that data oriented, I first considered GWT- RPC. But given the fact that the GPE 2.4 sample project voor Android comes with RequestFactory, I am leaning towards this approach. I was hoping someone could validate this 'best practise' : When you have both Android and GWT consumers of your App Engine service, apply the RequestFactory pattern. TIA Michel Jonker -- 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 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.
Re: GWT 2.4: RequestFactory versus GWT-RPC
With ValueProxy, you can with RequestFactory do everything you would with GWT-RPC (well, with the major exception of polymorphism –though this will be fixed soon– and transportable types –which don't include java.util.Map for instance, though once again will be fixed in due time–). GWT-RPC can also be a real pain (particularly with non-web apps) as the client and server must be compiled from the exact same code or they won't be able to deserialize what the other end point sent. And I can assure you'll likely hit those even while developing your app! RF on the other hand makes migrations easier (no serialization policy files, to begin with). But honestly, if you want to build an Android app, I wonder why you hesitate: support for GWT-RPC from Java is not official, and likely to break with a future version of GWT, whereas Android is officially a target plaform for RF. Just use ValueProxy all over the place if you don't need EntityProxy, it'll be just like RPC. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/2EmtzJM4fHwJ. 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.
Re: GWT 2.4: RequestFactory versus GWT-RPC
I'm using RequestFactory for a 'non-data-orientated' app and its works very nicely. Chained method invocation: MyServiceRC serviceRequest = appRequestFactory.MyServiceRC(); serviceRequest.giveMeAString().to(stringReceiver); if (needPojo == true) serviceRequest.giveMeAPojo().to(pojoReceiver); // Pojo would be a ValueProxy for example. // Now fire both methods in one RPC request, and do whatever processing we want once both completed. serviceRequest.fire(processStringAndPojoReceiver); A pretty nice way to call server side methods. You are certainly not restricted just to persisting and retrieving datastore objects with RequestFactory. On Thu, Jul 14, 2011 at 10:36 AM, Michel Jonker michel.jon...@e-office.com wrote: Hi, This is a cross post from the AppEngine group, but since I got no response there, I want to try this group. I am trying to figure out the best practise to consume my App Engine services from both Android and GWT. Since the services are not that data oriented, I first considered GWT- RPC. But given the fact that the GPE 2.4 sample project voor Android comes with RequestFactory, I am leaning towards this approach. I was hoping someone could validate this 'best practise' : When you have both Android and GWT consumers of your App Engine service, apply the RequestFactory pattern. TIA Michel Jonker -- 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 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.
Re: GWT 2.4: RequestFactory versus GWT-RPC
FYI, bobv updated the RF developer guide yesterday with a separate section on transportable types, discussion of polymorphic type-mapping rules, and slight re-wording of the Overview section. http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html /dmc On Thu, Jul 14, 2011 at 4:24 PM, Aidan O'Kelly aida...@gmail.com wrote: I'm using RequestFactory for a 'non-data-orientated' app and its works very nicely. Chained method invocation: MyServiceRC serviceRequest = appRequestFactory.MyServiceRC(); serviceRequest.giveMeAString().to(stringReceiver); if (needPojo == true) serviceRequest.giveMeAPojo().to(pojoReceiver); // Pojo would be a ValueProxy for example. // Now fire both methods in one RPC request, and do whatever processing we want once both completed. serviceRequest.fire(processStringAndPojoReceiver); A pretty nice way to call server side methods. You are certainly not restricted just to persisting and retrieving datastore objects with RequestFactory. On Thu, Jul 14, 2011 at 10:36 AM, Michel Jonker michel.jon...@e-office.com wrote: Hi, This is a cross post from the AppEngine group, but since I got no response there, I want to try this group. I am trying to figure out the best practise to consume my App Engine services from both Android and GWT. Since the services are not that data oriented, I first considered GWT- RPC. But given the fact that the GPE 2.4 sample project voor Android comes with RequestFactory, I am leaning towards this approach. I was hoping someone could validate this 'best practise' : When you have both Android and GWT consumers of your App Engine service, apply the RequestFactory pattern. TIA Michel Jonker -- 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 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. -- David Chandler Developer Programs Engineer, GWT+GAE w: http://code.google.com/ b: http://turbomanage.wordpress.com/ b: http://googlewebtoolkit.blogspot.com/ t: @googledevtools -- 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.
Re: Aw: Re: GWT 2.3 RequestFactory problem
Just glad to be able to give a little something back after all the help this forum has given me :-) -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Mk1RdjduZmg1VElK. 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.
Re: Aw: Re: GWT 2.3 RequestFactory problem
Eric, I was stuck on this for a couple of days... Thanks a lot for the help If my thing ever becomes a commercial success, keep this email as your IOU :-) -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/amUtUTE1ajdsZ0VK. 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.
Re: GWT 2.3 RequestFactory problem
Yes everything looks good. And as i pointed out above there seems to
be
sort of a type check against the base class which is located in the
old package.
Am i wrong with that?
I am still not able to run my application :(
On 5 Mai, 23:51, David Chandler drfibona...@google.com wrote:
QBiT,
Have you cleaned your project? I was seeing some weirdness in RF after
moving to 2.3, then realized I still had the GWT 2.2 jar on the classpath...
/dmc
On Thu, May 5, 2011 at 10:19 AM, QBiT qbit0...@googlemail.com wrote:
Hello,
when i refactored my sources to fit the new package structure (
com.google.web.bindery.requestfactory ) of the requestfactory i ended up
with a mess :/
When i try to launch my application i get the following error:
SCHWERWIEGEND: de.systemagmbh.gf.dwr.ui.shared.context.ReportRequestContext
is not a RequestContext
05.05.2011 16:05:51
com.google.gwt.requestfactory.server.ServiceLayerDecorator die
SCHWERWIEGEND: The RequestContext type
de.systemagmbh.gf.dwr.ui.shared.context.ReportRequestContext did not pass
validation
05.05.2011 16:05:51
com.google.gwt.requestfactory.server.RequestFactoryServlet doPost
SCHWERWIEGEND: Unexpected error
com.google.gwt.requestfactory.server.UnexpectedException: The
RequestContext type
de.systemagmbh.gf.dwr.ui.shared.context.ReportRequestContext did not pass
validation
at
com.google.gwt.requestfactory.server.ServiceLayerDecorator.die(ServiceLayerDecorator.java:205)
After a debugging session i found out that perhaps something went wrong
with the move to the new package.
This is what i have found:
In the class ResolverServiceLayer the method
validator.validateRequestContext(requestContextClass); sets the validator to
poisened.
@Override
public Method resolveRequestContextMethod(String requestContextClass,
String methodName) {
synchronized (validator) {
validator.antidote();
validator.validateRequestContext(requestContextClass);
if (validator.isPoisoned()) {
die(null, The RequestContext type %s did not pass validation,
requestContextClass);
}
}
Class? searchIn = forName(requestContextClass);
for (Method method : searchIn.getMethods()) {
if (method.getName().equals(methodName)) {
return method;
}
}
return report(Could not locate %s method %s::%s,
RequestContext.class.getSimpleName(),
requestContextClass, methodName);
}
This is because of the following in the RequestFactoryInterfaceValidator.
The method isAssignable(logger, requestContextIntf, requestContextType) goes
wrong.
public void validateRequestContext(String binaryName) {
if (fastFail(binaryName)) {
return;
}
Type requestContextType =
Type.getObjectType(BinaryName.toInternalName(binaryName));
final ErrorContext logger = parentLogger.setType(requestContextType);
// Quick sanity check for calling code
if (!isAssignable(logger, requestContextIntf, requestContextType)) {
logger.poison(%s is not a %s, print(requestContextType),
RequestContext.class.getSimpleName());
return;
}
Type domainServiceType = getDomainType(logger, requestContextType);
if (domainServiceType == errorType) {
logger.poison(
The type %s must be annotated with a @%s or @%s annotation,
BinaryName.toSourceName(binaryName),
Service.class.getSimpleName(),
ServiceName.class.getSimpleName());
return;
}
for (RFMethod method : getMethodsInHierarchy(logger,
requestContextType)) {
// Ignore methods in RequestContext itself
if (findCompatibleMethod(logger, requestContextIntf, method, false,
true,
true) != null) {
continue;
}
// Check the client method against the domain
checkClientMethodInDomain(logger, method, domainServiceType,
!clientToLocatorMap.containsKey(requestContextType));
maybeCheckReferredProxies(logger, method);
}
checkUnresolvedKeyTypes(logger);
}
And this finally is because my Context is not extended from the old
RequestContext anymore.
The isAssignable() method does the following:
private boolean isAssignable(ErrorContext logger, Type possibleSupertype,
Type possibleSubtype) {
// Fast-path for same type
if (possibleSupertype.equals(possibleSubtype)) {
return true;
}
// Supertype calculation is cached
ListType allSupertypes = getSupertypes(logger, possibleSubtype);
return allSupertypes.contains(possibleSupertype);
}
The list allSupertypes contains OBJECT my RequestContext interface and its
superclass wich is ...bindery..requestContext.
The problem is that possible superType somehow* is the old RequestContext
(old package) *which can obviously then not be
in the possible supertypes list.
What
Re: GWT 2.3 RequestFactory problem
I saw this same problem in my environment. In my case I had upgraded all of the RequestFactory references in my Java classes to the new package, but forgot to switch the RequestFactoryServlet class in my web.xml file: servlet servlet-namerequestFactoryServlet/servlet-name servlet-classcom.google.web.bindery.requestfactory.server.RequestFactoryServlet/servlet-class /servlet You might check that, my Eclipse findreplace kung fu missed that one. -- 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.
Aw: Re: GWT 2.3 RequestFactory problem
Eric, thanks a lot. You figured it out, that was exactly the problem. Now everything works as expected. Problem solved. -- 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.
Re: GWT 2.3 RequestFactory problem
QBiT,
Have you cleaned your project? I was seeing some weirdness in RF after
moving to 2.3, then realized I still had the GWT 2.2 jar on the classpath...
/dmc
On Thu, May 5, 2011 at 10:19 AM, QBiT qbit0...@googlemail.com wrote:
Hello,
when i refactored my sources to fit the new package structure (
com.google.web.bindery.requestfactory ) of the requestfactory i ended up
with a mess :/
When i try to launch my application i get the following error:
SCHWERWIEGEND: de.systemagmbh.gf.dwr.ui.shared.context.ReportRequestContext
is not a RequestContext
05.05.2011 16:05:51
com.google.gwt.requestfactory.server.ServiceLayerDecorator die
SCHWERWIEGEND: The RequestContext type
de.systemagmbh.gf.dwr.ui.shared.context.ReportRequestContext did not pass
validation
05.05.2011 16:05:51
com.google.gwt.requestfactory.server.RequestFactoryServlet doPost
SCHWERWIEGEND: Unexpected error
com.google.gwt.requestfactory.server.UnexpectedException: The
RequestContext type
de.systemagmbh.gf.dwr.ui.shared.context.ReportRequestContext did not pass
validation
at
com.google.gwt.requestfactory.server.ServiceLayerDecorator.die(ServiceLayerDecorator.java:205)
After a debugging session i found out that perhaps something went wrong
with the move to the new package.
This is what i have found:
In the class ResolverServiceLayer the method
validator.validateRequestContext(requestContextClass); sets the validator to
poisened.
@Override
public Method resolveRequestContextMethod(String requestContextClass,
String methodName) {
synchronized (validator) {
validator.antidote();
validator.validateRequestContext(requestContextClass);
if (validator.isPoisoned()) {
die(null, The RequestContext type %s did not pass validation,
requestContextClass);
}
}
Class? searchIn = forName(requestContextClass);
for (Method method : searchIn.getMethods()) {
if (method.getName().equals(methodName)) {
return method;
}
}
return report(Could not locate %s method %s::%s,
RequestContext.class.getSimpleName(),
requestContextClass, methodName);
}
This is because of the following in the RequestFactoryInterfaceValidator.
The method isAssignable(logger, requestContextIntf, requestContextType) goes
wrong.
public void validateRequestContext(String binaryName) {
if (fastFail(binaryName)) {
return;
}
Type requestContextType =
Type.getObjectType(BinaryName.toInternalName(binaryName));
final ErrorContext logger = parentLogger.setType(requestContextType);
// Quick sanity check for calling code
if (!isAssignable(logger, requestContextIntf, requestContextType)) {
logger.poison(%s is not a %s, print(requestContextType),
RequestContext.class.getSimpleName());
return;
}
Type domainServiceType = getDomainType(logger, requestContextType);
if (domainServiceType == errorType) {
logger.poison(
The type %s must be annotated with a @%s or @%s annotation,
BinaryName.toSourceName(binaryName),
Service.class.getSimpleName(),
ServiceName.class.getSimpleName());
return;
}
for (RFMethod method : getMethodsInHierarchy(logger,
requestContextType)) {
// Ignore methods in RequestContext itself
if (findCompatibleMethod(logger, requestContextIntf, method, false,
true,
true) != null) {
continue;
}
// Check the client method against the domain
checkClientMethodInDomain(logger, method, domainServiceType,
!clientToLocatorMap.containsKey(requestContextType));
maybeCheckReferredProxies(logger, method);
}
checkUnresolvedKeyTypes(logger);
}
And this finally is because my Context is not extended from the old
RequestContext anymore.
The isAssignable() method does the following:
private boolean isAssignable(ErrorContext logger, Type possibleSupertype,
Type possibleSubtype) {
// Fast-path for same type
if (possibleSupertype.equals(possibleSubtype)) {
return true;
}
// Supertype calculation is cached
ListType allSupertypes = getSupertypes(logger, possibleSubtype);
return allSupertypes.contains(possibleSupertype);
}
The list allSupertypes contains OBJECT my RequestContext interface and its
superclass wich is ...bindery..requestContext.
The problem is that possible superType somehow* is the old RequestContext
(old package) *which can obviously then not be
in the possible supertypes list.
What is going on here?
What could i have done wrong?
Is it right now not possible to move to the new Requestfactory packages
because something was overlooked here?
I do not want to use all these deprecated classes?
Do we need to wait for a fix here?
Hope for some help on this one
QB!T
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To
Re: GWT 2.2 / RequestFactory - Can domain objects be interfaces as opposed to concrete classes?
I would personal like to see a layer that considered base types, beyond Object of the concrete type. However it seems that Entity should really just be simple POJOs, even if the interface is just exposing getter and setters. Maybe someone from the GWT team will have some inspiration on this subject for a future release. -- 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.
Re: GWT 2.2 / RequestFactory - Can domain objects be interfaces as opposed to concrete classes?
Thanks Thomas and John for for your inputs. Would you see this workaround as the default behaviour in future GWT releases? On 18 fév, 18:13, John Maitland jfgmaitl...@googlemail.com wrote: I had the same problem and managed to implement a new ServiceLayerDecorator. See.. http://groups.google.com/group/google-web-toolkit/browse_thread/threa... Regards, John -- 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.
Re: GWT 2.2 / RequestFactory - Can domain objects be interfaces as opposed to concrete classes?
IIRC, the only blocker is the RequestFactoryInterfaceValidator (RFIV), which stops looping over super classes as soon as it finds java.lang.Object (and implemented interfaces come after Object in the list of super classes being iterated). This means it could be worked around by using a ServiceLayerDecorator that bypasses the RFIV (by re-implementing all the methods implemented by the ResolverServiceLayer; the hard thing then is to implement resolveClientType correctly). -- 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.
Re: GWT 2.2 / RequestFactory - Can domain objects be interfaces as opposed to concrete classes?
I had the same problem and managed to implement a new ServiceLayerDecorator. See.. http://groups.google.com/group/google-web-toolkit/browse_thread/thread/36d0ed4f87be/45af985914ac1780?lnk=gstq=maitland#45af985914ac1780 Regards, John -- 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.
Re: [gwt-contrib] RequestFactory - EntityProxy AutoBean Category
You can't do these things yet, but we've been discussing them. On Thu, Feb 3, 2011 at 5:08 AM, Krishna krishnacal...@gmail.com wrote: Hi, Does RequestFactory EntityProxy supports AutoBean Category (http:// code.google.com/p/google-web-toolkit/wiki/AutoBean#Categories) ? i. e. Can I define a Category for an EnitityProxy? If yes, how can I do that? It would be nice to define a category direct as an annotated Entity method... If the method requires only getters/setters and other category methods. I know its not easy to restrict. Is it hard to allow Proxy as an abstract class? Thanks! Krishna Caldas -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: GWT - Basic RequestFactory example
Thanks for your reply Miroslav,
unortunatelly when i am trying to Run as Web Application in Eclipse, i
got this error:
Initializing AppEngine server
Logging to JettyLogger(null) via
com.google.apphosting.utils.jetty.JettyLogger
Successfully processed C:\development\springsource\workspace
\MySampleApplication\war\WEB-INF/appengine-web.xml
Successfully processed C:\development\springsource\workspace
\MySampleApplication\war\WEB-INF/web.xml
[WARN] failed
com.google.apphosting.utils.jetty.DevAppEngineWebAppContext@608760{/,C:
\development\springsource\workspace\MySampleApplication\war}:
java.lang.NoClassDefFoundError: com/google/inject/servlet/
GuiceServletContextListener
[WARN] failed JettyContainerService$ApiProxyHandler@157ea4a:
java.lang.NoClassDefFoundError: com/google/inject/servlet/
GuiceServletContextListener
[WARN] Error starting handlers
java.lang.NoClassDefFoundError: com/google/inject/servlet/
GuiceServletContextListener
I think, that i have problems with Guice library, but when i try to
change libraries to 3.0R2, i got same error.
--
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.
Re: GWT - Basic RequestFactory example
Hello, Are you sure that all jar from lib folder are added in your classpath ? It seems that guice-servlet-3.0-rc1.jar is missing. Also you can check whether you have only one version of guice in your classpath. -- 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.
Re: GWT - Basic RequestFactory example
Hello Miroslav, sorry, my fault. You are right. Now everything works. I will test your example. Can you explain to me, why i better to use Injection of RequestFactory? Many thanks, Lubor On 19 led, 13:10, Miroslav Genov mge...@gmail.com wrote: Hello, Are you sure that all jar from lib folder are added in your classpath ? It seems that guice-servlet-3.0-rc1.jar is missing. Also you can check whether you have only one version of guice in your classpath. -- 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.
Re: GWT - Basic RequestFactory example
In my example, dependency injection is used over the server side service classes, so I can inject into them other classes using DI. This gives me the ability to test my services in isolation and also few more advantages such as scopes and etc. -- 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.
Re: GWT - Basic RequestFactory example
I had a small sample project that could help: https://github.com/mgenov/injecting-request-factory I don't know how simple is it, but it may help you some how. -- 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.
Re: GWT 2.1.1 RequestFactory Persist method
Thank you Thomas, that was all, you are very helpful. -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Persist method
thank you Thomas. Before trying the new service layer, I have looked this thread, http://groups.google.com/group/google-web-toolkit/browse_thread/thread/846564e9fc303be0, to understand how it works. I have pasted my code here. http://paste.pocoo.org/show/310712/. It must be a mis-declaration of your service method (stub and/or implementation) or a mis-implementation of your ServiceLocator. Probably is a mis-implementation of my ServiceLocator, but I am not sure. As far as I can see, the problem with the persist method is this: When the new request for persist is created as following example, RequestVoid createReq = request.persist().using(EntityObject); it gets as parameter the EntityObject. Then request factory, tries to persist the object, but when it invokes the persist method, it assumes that the object which owns the method is the entity object, as it used to, before the use of the service layer. But now it is different, because the object that owns the method is the service object. I have somehow inform the ServiceLayerDecorator about this change. Maybe I could do that through servicelocator, but I haven' t understand fully how the request factory manages to RequestFactory sends diffs on the wire (client-to-server) as you have said before, in the thread that you mention. -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Persist method
You declared your method as InstanceRequestUserProxy, Void, i.e. this is an instance method of UserProxy, that returns void. If your method is in your service, then it has to be a RequestVoid and takes the UserProxy/UserDAO as argument. -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Persist method
Hi I am trying to use the service layer of GWT 2.1.1. I have created the infrastracture meaning: 1. An entity proxy, entity and entity locator 2. A request, a service and a service locator I am using an interface which I annotate as service, and which I implement. Everything works ok, except that of the persist and probably remove methods. The problem is that, I cannot have access to the object that is going to be saved, because I need to have access to the instance that will be saved. When I tried to, I am getting the following error: ERROR] Could not invoke method persist java.lang.IllegalArgumentException: object is not an instance of declaring class at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:597) at com.google.appengine.tools.development.agent.runtime.Runtime.invoke(Runtime.java: 100) at com.google.gwt.requestfactory.server.ReflectiveServiceLayer.invoke(ReflectiveServiceLayer.java: 164) at com.google.gwt.requestfactory.server.ServiceLayerDecorator.invoke(ServiceLayerDecorator.java: 89) at com.google.gwt.requestfactory.server.ServiceLayerDecorator.invoke(ServiceLayerDecorator.java: 89) at com.google.gwt.requestfactory.server.SimpleRequestProcessor.processInvocationMessages(SimpleRequestProcessor.java: 440) at com.google.gwt.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java: 218) at com.google.gwt.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java: 125) at com.google.gwt.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java: 118) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: 511) When I am debugging, I can see that the problem is that in the ServiceLayerDecorator.invoke(Method domainMethod, Object... args) it gets the domain method right, it is the persist method of the service interface, but in the arguments it refers to the entity DAO. So what to do? I should extend the ServiceLayerDecorator, trying to make the invoke method to get the right parameters, or I should try some other solution. Can someone help please? -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Persist method
On Tuesday, December 28, 2010 12:19:37 AM UTC+1, giannisdag wrote: Hi I am trying to use the service layer of GWT 2.1.1. I have created the infrastracture meaning: 1. An entity proxy, entity and entity locator 2. A request, a service and a service locator I am using an interface which I annotate as service, and which I implement. Er, you mean that you have similar methods on your service stub (interface) and service implementation (referenced by the @Service annotation), right? When I am debugging, I can see that the problem is that in the ServiceLayerDecorator.invoke(Method domainMethod, Object... args) it gets the domain method right, it is the persist method of the service interface, but in the arguments it refers to the entity DAO. So what to do? Hard to tell without seeing your code (at lease how you declared the method in both the service stub and implementation, and how you implemented your ServiceLocator) I should extend the ServiceLayerDecorator, trying to make the invoke method to get the right parameters, or I should try some other solution. Definitely try another solution! Can someone help please? If you used RF without the locators, then it really is similar: - service methods had to be static on the service implementation class, now they can be instance method, with the ServiceLocator providing the instance - instance methods (those returning InstanceRequest) had a resolution bug: they were looked up on the service class rather than the domain object. - domain objects had to have a no-arg constructor, findXxx static method, and getId and getVersion instance methods, now you can use a Locator to fulfill those requirements (instantiation, finder, and id and version provider) by other means. It must be a mis-declaration of your service method (stub and/or implementation) or a mis-implementation of your ServiceLocator. -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
I cannot understand how I could persist a domain object, using the new service layer. Because when I call pm.makePersistent(arg); I need to have access to the instance of the domain object that is going to be stored. Before, I could just write pm.makePersistent(this); according to the example, referring to the domain object. But know, where I call the same method through a service, how can I have access to the domain object. Should I call Locator, and how exactly could I do that? -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
from your explanation I get the feeling that Locators are DAOs, is this correct ? placing calls like these: EntityManager#find(clazz,id) inside a Locator, means Locator is now responsible for accessing datastore to perform actions. it also means that our DAOs are somehow directly coupled with RequestFactoryServlet. A common design approach is to have a Service Layer and a DataAccessLayer, that communicate through interfaces. when the request comes from the client, it gets routed to the Service object responsible for performing a business logic to fulfill clients request. In doing so, the Service object, may interact with a number of DAOs, to perform the task. and if Required, this Service object returns the data that has to be given to the client. in GWT 2.1.1 RequestFactory Servlet, ServiceLocator can be used to locate the Service Object responsible for fulfilling client request. However, how the ServiceObject communicates with server-side DAO to get its data is the ServiceObject concern, not the RequestFactoryServlet. In otherwords, our Service Object itself knows how to locate DAOs, therefore why do we need this Locator for our EntityObjects ? On Dec 22, 2:19 am, Thomas Broyer t.bro...@gmail.com wrote: Well, as always, it depends what you need and what you can do. If you can implement a single Locator class that works for all your entities, then go with it; and otherwise make one for each entity. For instance, if you have a base class for your entities that provides an ID and version, then you can easily cast any entity to that class to implement getId and getVersion, and you probably can implement getIdType by returning a fixed type. You can clazz.newInstance() in the create() or use PersistenceManager#newInstace with JDO. And you can easily find using the Class and ID with JPA using EntityManager#find(clazz,id), or with JDO using PersistenceManager#getObjectById(clazz,id). -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
RequestFactory sends diffs on the wire (client-to-server), so how would your Service Object (as you call it) would receive a complete domain object if the diff isn't applied to an object retrieved from the database/datastore? Things are a bit more blury than service layer on top of data access layer. If you want to name things, RequestFactoryServlet is part of your service layer, and delegates a few (a very few) things to DAOs (Locator, or static findXxx methods), and all the business logic to other pieces (services, as referenced in @Service/@ServiceName, or instance methods on your domain objects) (as for the SL vs. DAL, I never bought that; the few times I used that strict approach, one was almost useless; JPA/JDO/whatever *are* the DAL, you hardly need an additional layer, and each layer removes some ways of optimizing things, notably database/datastore requests; but that's another debate) -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
Thank you so much for your feedback on this. I am going to experiment more, using your guidelines. as for the need for additional layer, a valid use case could be this: lets say you are going to deploy your app on GAE. for the persistence, there are several options: - JDO/JPA - DataStore LowLevel APIs - Objectify, Twig Persist many of these technologies are new and subject to (rapid) change, it is a good idea to use interfaces to declare our DataAccess contract without exposing infrastructure related detail that is specific to each of those technologies. if one has 20 domain objects(entities), and for each entity, certain requests/methods : findX, findXInRange, findByX, it can get out of hand quickly. it would be very difficult to swap one persistence technology for another, sometime down the road. the idea is, - loose coupling - easily swapping infrastructure specific code, without affecting other part of system (easy refactoring, testing,) - clearly defined contracts in the form of interfaces, when you look at an interface you can see what is expected of this DAO, rather than going through hundreds of lines of codes, some of which scattered with try/catch/finally blocks (i am exaggerating a bit, IDEs can provide a quick overview) having said that, if one is working on a project that uses a legacy database, a database that's been in that environment for years, where DBAs have developed custom scripts, and its been used in day to day operation of that business/organization for many years, and there are policies within that business/organization to continue using that database in the future, I agree, using abstractions might be an overkill. As with most things, I believe it all depends on the requirements/ constraints. -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
SL vs DAL, one example of how they are different is that: let's say we have a DAO for accessing a Customer entity a DAO for accessing Account entity a DAO for accessing History/Trend entity // maybe not a good example, but just three separate entities a Service(object) living in a ServiceLayer, needs to access these three entities, analyze them and based on a current condition, apply a policy, and then notify the interested parties. the Logic for sending Notification is in another Object. the Logic for Accessing/Finding those entities are in another object. our Service(object) responsibility is to perform some operation, with the help of those other objects. (through collaboration). in this case, our Service is not just a basic CRUD. to complicate things further, (in a real world scenario), not all of the data might come from same DataStore, one using a local DataStore, one a WebService to retrieve realtime data, so when going beyond basic CRUD, the need for a Separate(isolated) ServiceLayer and DataAccessLayer, becomes more obvious. -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
On Wednesday, December 22, 2010 12:59:16 AM UTC+1, zixzigma wrote:
Thank you, it all makes sense now.
However what you described is how GWT RF uses those details
to do its magic behind the scenes.
I am not clear what our responsibility is then ?
Provide the right values so RF can do its magic ?
What should go inside the Locator ?
From the code I posted,
http://paste.pocoo.org/show/308153/
I don't know what I should put in there.
I have a ServiceLocator ( one per application),
that locates Services. those Services are independent from GWT RF,
they can connect to persistent stores, do whatever they want.
and return a retult/perform action that is expected by RequestContext.
and what you described for Locators
@ProxyFor(value=PersonEntity, locator=EntityLocator)
public interface PersonProxy {
from your explanation I understood why Locator is important,
but what should we/the developers put in it ?
and do we need one per Entity or one per Application ?
Well, as always, it depends what you need and what you can do.
If you can implement a single Locator class that works for all your
entities, then go with it; and otherwise make one for each entity.
For instance, if you have a base class for your entities that provides an ID
and version, then you can easily cast any entity to that class to implement
getId and getVersion, and you probably can implement getIdType by returning
a fixed type.
You can clazz.newInstance() in the create() or use
PersistenceManager#newInstace with JDO.
And you can easily find using the Class and ID with JPA using
EntityManager#find(clazz,id), or with JDO using
PersistenceManager#getObjectById(clazz,id).
Basically, you could very well have only one Locator class per id type.
Oh, and something to keep in mind: the Locator and *your services* instances
(not the ServiceLocator instances though) are cached aggressively and reused
for all subsequent requests, so make sure they are thread-safe !
(have a look at the ServiceLayerCache class to see all memoized methods)
--
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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
I use the same pattern explained here with JPA/Spring for the Entity Locator
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/20ea2aea53aa29d3/687ff2df944c483c
public class MyDataLocator extends LocatorMyData, Long {
private MyRepository getRepository() {
HttpServletRequest request =
RequestFactoryServlet.getThreadLocalRequest();
ApplicationContext context =
WebApplicationContextUtils.getWebApplicationContext(request.getSession().getServletContext());
MyRepository repository = context.getBean(MyRepository.class);
return repository;
}
@Override
public MyData create(Class? extends MyData clazz) {
MyRepository repository = getRepository();
repository.persist(new MyData());
*return null;*
}
@Override
public MyData find(Class? extends MyData clazz, Long id) {
MyRepository myRepository = getRepository();
MyData entity = myRepository.findByPrimaryKey(id);
return entity;
}
@Override
public ClassMyData getDomainType() {
return MyData.class;
}
@Override
public Long getId(MyData domainObject) {
return domainObject.getId();
}
@Override
public ClassLong getIdType() {
return Long.class;
}
@Override
public Long getVersion(MyData domainObject) {
return domainObject.getVersion();
}
@Override
public boolean isLive(MyData domainObject) {
return super.isLive(domainObject);
}
}
MyRepository is a Spring Repository with an injected EntityManager.
The only problem I still have is, that entityManager.persist(entity) returns
void.
And returning the created instance is a bad idea, since the primary key ID
is not yet generated.
*Do we really have to return the created object or may we return null*? The
only way out I see is to make another call to the repository and read the
newly generated object, when using JPA.
By the way, Repository must start and commit the DB Transaction.
Daniel
--
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-tool...@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.
Re: [gwt-contrib] RequestFactory entity proxies can't be cloned
Added an issue for this: http://code.google.com/p/google-web-toolkit/issues/detail?id=5794 -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: GWT 2.1.1 RequestFactory Strange Exception
I realized I was using the 2.1 style to create my RequestFactory I came across this, while digging into code: * ServiceLayer serviceLayer = ServiceLayer.create(); * SimpleRequestProcessor processor = new SimpleRequestProcessor(serviceLayer); * EventBus eventBus = new SimpleEventBus(); * MyRequestFactory f = RequestFactoryMagic.create(MyRequestFactory.class); * f.initialize(eventBus, new InProcessRequestTransport(processor)); now I am going to experiment (in test mode) with this, see if I am correct in my guess. -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
From the RequestFactory documentation: Four special methods are required on all entities as they are used by the RequestFactory servlet: A no-arg constructor. This may be the implicit default constructor. 1. id_type getId() -- IDs can be String or Long 2. static entity_type findEntity(id_type id) 3. Integer getVersion() You could argue that this means that you cannot easily make a separate service and I believe you would be right. The only way to do this, I believe, is to create a Locator for each proxy. I asked the same question a couple of days ago. See http://groups.google.com/group/google-web-toolkit/browse_thread/thread/c929fb1d4239f7e0 -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
@ProxyFor(value = Person.class, locator = PersonLocator.class) then having a PersonLocator which implements LocatorPerson would fix this for you. But in order to get your static service methods (besides just the find method), you need a ServiceLocator for your service: @Service(value = PersonService.class, locator = MyServiceLocator.class) I'm not sure if the locator for the service is necessary if it has a default constructor. We use Spring, so we have a service locator that just pulls the bean out of spring. -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
On Dec 21, 6:25 am, Matt Moriarity matt.moriar...@gmail.com wrote: But in order to get your static service methods (besides just the find method), you need a ServiceLocator for your service: do all these methods have to be static ? I thought the idea behind 2.1.1 was to get rid of static ? I am a bit confused on what is meant by the term service methods. Normally we have a Service Layer, and a Data Access Layer Data Access Layer (all the DAOs), responsible for communicating with persistent stores to find objects of a given type findCustomerById, ByEmail, AllCustomers, AllCustomersWithCriteriaX all of this goes into CustomerDAO then you need a Service Layer, that uses many of these DAOs to satisfy a use case. PersonService, might use PersonDAO, AccountDAO, and more ..., performs a business logic on them and take some action. in RequestFactory 2.1.1, do you think the ServiceLayer and ServiceLocator is just for locating the DAOs or the Service objects as I described ? (because in RequestFactory 2.1 even the DataAccess (DAOs) where inside Entity class. to achieve the complete isolation we need a ServiceLayer + DataAccessLayer on top of our Entities. with RF 2.1.1, can we specify just the Service method in GWT, and leaving the job of dealing with DAOS to the Service object ? @ProxyFor(value = Person.class, locator = PersonLocator.class) then having a PersonLocator which implements LocatorPerson would fix this for you. @Service(value = PersonService.class, locator = MyServiceLocator.class) I'm not sure if the locator for the service is necessary if it has a default constructor. We use Spring, so we have a service locator that just pulls the bean out of spring. I am planning to use it with Spring too. in your case (spring), you need all 4 attributes ? on PersonProxy we use @ProxyFor(EntityObject, EntityLocator) on PersonService we use @Service(ServiceObject, ServiceObjectLocator) so the EntityLocator is the DAO ? and ServiceLocator queries spring context to find the Service method to handle the EntityLocator ? yet, all of these methods have to be static ? Thank You -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
in RequestFactory 2.1.1 documentations (source code), there are many references to Domain and Domain Environment, I am unclear what is meant by Domain Environment. is it on the server side where RequestFactory work stops and our work begins ? it helps if the documentaton clarify the vocabulary, Locator, Service, ServiceLocator, Domain, Domain Environment, ServiceLayer is ServiceLayer a DAO layer or a true Service Layer. ServiceLayer vs Domain Environment ? what is the distinction between the two ? -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
Thank you guys for the tips. I got it to work! Thank you very much ! I noticed a VERY STRANGE behaviour. following your suggestion, I declared: @ProxyFor(MyPersonEntity, EntityLocator) PersonProxy @Service(MyPersonService, MyServiceLocator) PersonService I noticed when methods in PersonService are declared static, ServiceLocator is bypassed, and is NEVER used by RequestFactory to look up PersonService RF directly goes to PersonService. This was strange, because what is the point of ServiceLocator then, if it is going to be bypassed ? to force RF to go through ServiceLocator, you have to remove static from your Service methods. This is where things get even more STRANGE: if I do not define a Locator, I get exceptions complaining PersonRequest did not pass validation. however if I define a Locator (by extending Locator Interface) I then have to implement bunch of methods: find/create/getId/ getVersion I return NULL from all methods, and it still works ! why is that? and why we are forced to define a Locator, if we already have a Service defined ? my Locator does nothing ! you can see the code here: http://paste.pocoo.org/show/308153/ from the debug statements, I see these methods being invoked: [1022][INFO ][main][EntityLocator:init:22] - #EntityLocator constructor called [1022][INFO ][main][EntityLocator:getId:45] - # get Id # [1023][INFO ][main][EntityLocator:getVersion:57] - ### get Version ### however, I returned null for all of them, still the client receives the correct Id/Version as I set in my PersonService#find method. could someone from GWT Team please explain. I am beginning to love the new RequestFactory, Thank You ! -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
The getId method is used generate a stable id that's transmitted to the client so that the object can be identified when it's later updated, and the find() method (see below) can be called with the appropriate identifier. You don't have to define a getId() in your EntityProxy, and if you do, it'll be resolved as a property, not by calling getId. The getVersion method is used to send to the client the version of the object it knows about, so that when it send it back to the the server (generally with changes), the server can quickly bail if it knows that the server-side version is different (i.e. getVersion is called to send the version to the client, and also at the very beginning of the server-side processing to check that the version known by the client is not out-dated, i.e. an optimistic lock). It's also used, just before returning to the client, to detect if a given object has been changed by the service methods (RF then generates the appropriate payload in the response so that an UPDATE event is dispatched on the client-side) The find method is called to update the domain entity when you send one from the client to the server (RF will actually only send deltas of your changes, not the whole object, that's (one of) the point(s) of RF), e.g. to pass it to a persist() service method. The create method is called when you send to the server an object that you RequestContext#create()-d on the client-side. The isLive method is called for each object sent over the wire on a given request (from client to server and from server to client) to possibly generate the payload in the response so that a DELETE event is dispatched client-side. Finally, getDomainType is useless, it's never called. -- 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-tool...@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.
Re: GWT 2.1.1 RequestFactory Strange Exception
Thank you, it all makes sense now.
However what you described is how GWT RF uses those details
to do its magic behind the scenes.
I am not clear what our responsibility is then ?
What should go inside the Locator ?
From the code I posted,
http://paste.pocoo.org/show/308153/
I don't know what I should put in there.
I have a ServiceLocator ( one per application),
that locates Services. those Services are independent from GWT RF,
they can connect to persistent stores, do whatever they want.
and return a retult/perform action that is expected by RequestContext.
and what you described for Locators
@ProxyFor(value=PersonEntity, locator=EntityLocator)
public interface PersonProxy {
from your explanation I understood why Locator is important,
but what should we/the developers put in it ?
and do we need one per Entity or one per Application ?
sorry I repeated myself, I am still a bit confused : )
--
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-tool...@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.
Re: [gwt-contrib] RequestFactory entity proxies can't be cloned
On Mon, Dec 20, 2010 at 3:10 PM, Matt Moriarity matt.moriar...@gmail.com wrote: I'm attempting to switch to using RequestFactory instead of GWT-RPC and manually creating DTOs. It's been going pretty well, except I've hit one use-case that is just a brick wall. I have a panel that is an EditorDocumentProxy which uses a RequestFactoryEditorDriver to handle the editing. One of the properties of DocumentProxy is another proxy, which I want to edit in a dialog box that shows when a button is clicked in the panel. The dialog is another Editor. The problem is that anytime something changes in this dialog, I want to flush the editor, send the current values to the server for validation, and report any errors right away. This works fine, but the dialog box has a cancel button, which should revert any changes made in the dialog box. I was able to do this before by storing the original value when it's set, and editing a clone while in the dialog box. But entity proxies can't be usefully cloned in any way that I currently see, so I'm at a loss as to how to get this behavior. It only makes sense to clone an (immutable) EntityProxy that's not associated with a RequestContext. Cloning one associated with a pending request would lead to contention about which proxy has the canonical new values to send to the server. The future-proof way: The DocumentEditor can call the DetailEditor with the stableId() of the entity to edit. The DetailEditor fires its own find() request to retrieve a new EntityProxy to edit. If the DetailEditor commits a change back to the server (causing the version number of the entity to change), the DocumentEditor can use the EditorDelegate.subscribe() to receive the notification that the DetailEditor made something change on the server. In the future, RequestFactory will gain a way to cache data locally, so the cost of the redundant call can be eliminated. The slower, but no-request way: Use the ProxySerializer available from the RequestFactory to clone via client-local serialization. If the object that's being cloned has a non-trivial reference graph, this could be somewhat slow. The coloring-outside-the-lines way which will probably break in the future: Use AutoBeanUtils.getAutoBean(someEntityProxy) to retrieve the AutoBean controller for the FooProxy and call clone() on it. You'll need to copy the com.google.gwt.requestfactory.shared.impl.Constants.STABLE_ID tag from the source bean to the cloned bean and call freeze() on the cloned bean to prevent assertion failures. I don't recommend this approach since it relies on the RequestFactory plumbing not changing in the future. -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: GWT 2.1.1 RequestFactory Strange Exception
tracked down the problem, it has to do with validation: RequestFactoryInterfaceValidator this validation fails: RequestFactoryInterfaceValidator v = new RequestFactoryInterfaceValidator( logger, new RequestFactoryInterfaceValidator. ClassLoaderLoader(PersonRequest.class.getClassLoader())); v.validateRequestContext(PersonRequest.class.getName()); assertFalse(v.isPoisoned()); as stated in previous post, the source code can be found here: http://paste.pocoo.org/show/307617/ I tried different combination of classes on @Service Annotation (also locator attribute), different combination of static/non-static. basically trial and error, checked it with expenses sample, and RF wiki, still can't get it to work. I don't know what I am doing wrong, please Help : ( -- 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-tool...@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.
Re: GWT 2.1 RequestFactory and complex properties on my DTO (Entity proxies)
On 9 nov, 03:01, David Chandler drfibona...@google.com wrote: It's still too early to call a release date. The RequestFactory enhancements are in code review and should be going into trunk shortly. See http://gwt-code-reviews.appspot.com/1062801/show Or maybe they're already there: http://code.google.com/p/google-web-toolkit/source/detail?r=9189 The commit log references a different code review though, I don't know what the differences are, maybe Bob could give details? -- 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-tool...@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.
Re: GWT 2.1 RequestFactory and complex properties on my DTO (Entity proxies)
I guess this is the relevant part : A new Proxy interface will be added as a superclass of ValueProxy and EntityProxy to allow RequestFactory.create to operate on both value and entity types. Because ValueProxy doesn't have a stableId() method, there's no way to use a VP with a call to find() or with any other service method that has an EntityProxyId argument. If you think about a Date object, there's no real meaning in giving a Date an id. If an EntityProxy has a value property, all of the properties of the VP are checked for mutations and sent to the server. The value in the domain object will be replaced if anything in the VP's state has changed. http://code.google.com/p/google-web-toolkit/issues/detail?id=5522 http://code.google.com/p/google-web-toolkit/issues/detail?id=5357 On Nov 9, 10:19 am, Thomas Broyer t.bro...@gmail.com wrote: On 9 nov, 03:01, David Chandler drfibona...@google.com wrote: It's still too early to call a release date. The RequestFactory enhancements are in code review and should be going into trunk shortly. Seehttp://gwt-code-reviews.appspot.com/1062801/show Or maybe they're already there:http://code.google.com/p/google-web-toolkit/source/detail?r=9189 The commit log references a different code review though, I don't know what the differences are, maybe Bob could give details? -- 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-tool...@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.
Re: GWT 2.1 RequestFactory and complex properties on my DTO (Entity proxies)
On 9 nov, 18:07, koma k...@koma.be wrote: I guess this is the relevant part : A new Proxy interface will be added as a superclass of ValueProxy and EntityProxy to allow RequestFactory.create to operate on both value and entity types. I don't see Proxy and ValueProxy in any code review linked here. This is what interests us here, but it's still not in review yet (and I don't blame anyone!) -- 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-tool...@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.
Re: GWT 2.1 RequestFactory and complex properties on my DTO (Entity proxies)
Koen, RequestFactory doesn't yet support the transfer of value types, only entity types. It's on tap for 2.1.1: http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1 /dmc On Mon, Nov 8, 2010 at 6:31 PM, koma k...@koma.be wrote: Hi, My entities are persisted via JDO in the Datastore (GAE). I can transfer DTOs to the client by creating EntityProxy objects that match the entity's properties (getters/setters). But how do I transfer the more complex values like com.google.appengine.api.datastore.Email with my DTO object to the client ? these classes com.google.appengine.api.datastore.* are not on the classpath for the client and result in ClassNotFoundExceptions; thx, koen -- 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-tool...@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. -- David Chandler Developer Programs Engineer, Google Web Toolkit http://googlewebtoolkit.blogspot.com/ -- 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-tool...@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.
Re: GWT 2.1 RequestFactory and complex properties on my DTO (Entity proxies)
Hi, When is the 2.1.1 release planned for? Is there some of this already in the trunk? Regards, Tobias On Nov 9, 1:26 am, David Chandler drfibona...@google.com wrote: Koen, RequestFactory doesn't yet support the transfer of value types, only entity types. It's on tap for 2.1.1: http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1 /dmc On Mon, Nov 8, 2010 at 6:31 PM, koma k...@koma.be wrote: Hi, My entities are persisted via JDO in the Datastore (GAE). I can transfer DTOs to the client by creating EntityProxy objects that match the entity's properties (getters/setters). But how do I transfer the more complex values like com.google.appengine.api.datastore.Email with my DTO object to the client ? these classes com.google.appengine.api.datastore.* are not on the classpath for the client and result in ClassNotFoundExceptions; thx, koen -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/google-web-toolkit?hl=en. -- David Chandler Developer Programs Engineer, Google Web Toolkithttp://googlewebtoolkit.blogspot.com/ -- 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-tool...@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.
Re: GWT 2.1 RequestFactory and complex properties on my DTO (Entity proxies)
It's still too early to call a release date. The RequestFactory enhancements are in code review and should be going into trunk shortly. See http://gwt-code-reviews.appspot.com/1062801/show /dmc On Mon, Nov 8, 2010 at 7:50 PM, Tobias thaberm...@gmail.com wrote: Hi, When is the 2.1.1 release planned for? Is there some of this already in the trunk? Regards, Tobias On Nov 9, 1:26 am, David Chandler drfibona...@google.com wrote: Koen, RequestFactory doesn't yet support the transfer of value types, only entity types. It's on tap for 2.1.1: http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1 /dmc On Mon, Nov 8, 2010 at 6:31 PM, koma k...@koma.be wrote: Hi, My entities are persisted via JDO in the Datastore (GAE). I can transfer DTOs to the client by creating EntityProxy objects that match the entity's properties (getters/setters). But how do I transfer the more complex values like com.google.appengine.api.datastore.Email with my DTO object to the client ? these classes com.google.appengine.api.datastore.* are not on the classpath for the client and result in ClassNotFoundExceptions; thx, koen -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/google-web-toolkit?hl=en. -- David Chandler Developer Programs Engineer, Google Web Toolkithttp://googlewebtoolkit.blogspot.com/ -- 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-tool...@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. -- David Chandler Developer Programs Engineer, Google Web Toolkit http://googlewebtoolkit.blogspot.com/ -- 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-tool...@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.
