SuperDevMode not so super
In a larger GWT multi project app and it took me several hours to get the new SuperDevMode running (I found this videohttp://jeff-davis.blogspot.de/2012/07/setting-up-gwt-25s-superdevmode.htmlvery helpful). Now, I'm a bit disappointed about the coolest new feature of 2.5 and I wonder if I have missed something. - Compilation is slow. It takes between 1 and 2 minutes plus the bootstrap time of my server app. The app has sth above 20k LOC and heavily uses RequestFactory and GIN code generators, maybe that's the reason? So overall startup performance is worse than with standard DevMode. - Code changes require a recompile. In DevMode non-structural changes are applied automatically by the Eclipse Debugger. - Debugging the code in the Browser is ... hm, it works. But honestly, nothing compare to a IDE debugger. Browsing through the source tree in Chrome is a pain with thousands of classes. - GWT CodeServer is very resource intensive. During compilation, I cannot use my machine for anything else. If it's running it takes more than 1GB of RAM. Is anyone successfully using SuperDevMode for larger apps? -- 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/-/JciNEGe96oYJ. 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: Vaadin 7 to include GWT
What does this exactly mean? What will be possible with Vaadin 7 that didn't work before? https://vaadin.com/gwt looks nice but I got only some minor new points: - Vaadin keeps its own GWT branch. To meet all requirements that are hardly possible with GWT (which was not designed to be a runtime)? - Vaadin Ldt. offers first level GWT support. What's missing? -- 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/-/8K6d7VKVm3IJ. 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: Hibernate prematurely flushing within RequestFactoryServlet while building object
Hi Eric, is setting the hibernate flush mode to COMMIT an option? That would mean that no flush is executed before running a query. Regards, Stefan. -- 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/-/iw6cs7bEpbIJ. 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: EntityProxy, AutoBeanVisitor and Hibernate lazy properties.
Hi Tiago, I just made a little test and it works as expected. Only those getters are called which are referenced in the with() statement. Maybe there's an issue with your entityProxies? Can you provide some details about your setup? Regards, Stefan. -- 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/-/pvviVfi3ogsJ. 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: EntityProxy, AutoBeanVisitor and Hibernate lazy properties.
You can use the OpenEntityManagerInView pattern (servlet filter with Spring) to ensure a EntityManager session is open during the RF-request. Regards, Stefan. -- 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/-/lKzthWaODcEJ. 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: Unit testing classes that depends on RequestFactory
I wrote a small tutorial about writing plain JRE unit tests for RequestFactory classes. The basic idea is to use the request factory infrastructure for entity conversion, etc. and replace the transport layer with a In memory transport. The backend service layer is mocked using Mockito. http://cleancodematters.wordpress.com/2011/06/18/tutorial-gwt-request-factory-%E2%80%93-part-ii/ Regards, Stefan. -- 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/-/QZCawiZk2boJ. 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: Aw: Unit testing classes that depends on RequestFactory
Caching of services (which are mocks in such a scenario) is a problem indeed. One easy solution on GWT side would be to have this cache servlet-specific (i.e. ServiceLayer specific) and not as static field. I worked around this by calling Mockito#reset() whenever the service is acquired from my helper class. You're right, these are more integration tests than plain junit tests, however this is absolutely useful, e.g. to test the String parameters in .with() methods. The overhead is relatively small. We have some hundred RF-tests that run within seconds. The main problem in my view are the proxy interfaces which are hard to handle. A POJO based solution (DTOs) would help very much, however, I am not sure if this is technically possible. -- 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/-/Tzv5JS09JTAJ. 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: When does Locator.getDomainType() gets called?
Well, if David Chandler says its not called (in his code comment), and you cannot find any calling piece of code, I think returning null is fine. I do so, too, and didn't run into any problems so far. Regards, Stefan. -- 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/-/JRpyts1x6VMJ. 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.
Purpose of JSR-BeanValidation in RequestFactory
I wonder if the JSR 303 bean validation at the client-server-interface is really helpful. I stumbled upon two restrictions why I decided to deactivate the validation: - Beans created within the client might be populated in the back-end. For instance, I have a @NotNull column which contains the creationDate of an entity. It doesn't make sense to let clients set this value, instead it is set just before persisting the first time. - Beans object graph needs to be complete for relations with cardinality 1 or 1..n. Again a @NotNull association prevents partially filled beans to be send back to the server. Opinions? Regards, Stefan. -- 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/-/Bt_UircGSkIJ. 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: RequestFactory: Usage of the EntityService / EntityLocator / ServiceLocator pattern
Is there anywhere a concrete code sample for this pattern? I'm considering to use Dep. Injection too. Here's another example for a classic DAO pattern combined with Spring: http://cleancodematters.wordpress.com/2011/06/04/tutorial-gwt-request-factory-part-i/ -- 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/-/ROtnqPNljuUJ. 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.
Security for RequestFactoryServlet and static cache in ServiceLayerCache
To allow some RequestFactory calls to be executed with and some without an authenticated session, I thought of providing two different RequestFactoryServlets at two different urls. The first one is secured by an http filter and the second is not. The unsecured version adds a special ServiceLayerDecorator to restrict access to some services from the back-end. The reason why this doesn't work is the static method cache in ServiceLayerCache. As the instance of ServiceLayerCache is only created once per servlet, I don't see a reason why to use a static field here. If this would be a normal field, I think the solution could work. Before opening a feature request, I'd like to hear other opinions. Regards, Stefan. -- 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/-/TUttajlsbUJtSWtK. 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: Security for RequestFactoryServlet and static cache in ServiceLayerCache
Hi Thomas, thanks for the feedback. Indeed the problem was to only intercept #createServiceInstance() but not #invoke(). Now, it works. Thanks, Stefan. -- 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/-/UVBEQWJ6WjEzYTBK. 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: More logs on requestfactory ?
Your implementation on the server very likely throws a
NullPointerException. The message Server Error: is prefixed by the
DefaultExceptionHandler. You can replace the latter with a custom
version that logs all exceptions. Therefore you have to provide a
custom version of the RequestFactoryServlet. Here's an example:
public class CustomRequestFactoryServlet extends RequestFactoryServlet
{
static class LoquaciousExceptionHandler implements ExceptionHandler
{
private static final Logger LOG =
LoggerFactory.getLogger( LoquaciousExceptionHandler.class );
@Override
public ServerFailure createServerFailure( Throwable throwable ) {
LOG.error( Server error, throwable );
return new ServerFailure( throwable.getMessage(),
throwable.getClass().getName(), null, true );
}
}
public CustomRequestFactoryServlet() {
super( new LoquaciousExceptionHandler() );
}
}
More information:
http://cleancodematters.wordpress.com/2011/05/29/improved-exceptionhandling-with-gwts-requestfactory/
--
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.
Stale entities in RequestFactory after transaction rollback
I have the following situation: - I'm sending an entity with an sub-entity to the server using the RequestFactory pattern. Both are not persisted yet and have no id assigned. (sth. like a user with an associated organization) - On the server side both entities are persisted using JPA, but when persisting the second entity, an exception is thrown. - The transaction is rolled back, however, the first entity now has an id assigned. The JPA spec says that the state of these entities is not defined and they should not be used anymore as they are detached from the entity context. - In SimpleRequestProcessor#createReturnOperations() an reference to the entity bean (that now has an id but had not before) is still available. - service#isAlive() returns false for this entity (as detached from entity context) which causes GWT to send a DELETE operation back to the client - This is bad because it the deleted entity is not send to the server again on subsequent request. Any ideas? Thanks Regards, Stefan. -- 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: 2.1.1 RequestFactory: Persist method cannot be found
Hi Thomas, thanks for the link. It works now. Regards, Stefan. -- 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.
2.1.1 RequestFactory: Persist method cannot be found
I try to use the locator pattern to separate Entities and Services.
Unfortunately, the persist method cannot be mapped to my service
implementation.
Error message:
19.01.2011 18:09:54 com.abc.OrganizationRequest
com.google.gwt.requestfactory.shared.InstanceRequest persist()
Could not find matching method in com.abc.OrganizationService.
Possible matches:
void persist(com.abc.Organization )
This is my setup:
@Service(value = OrganizationService.class, locator =
SpringServiceLocator.class)
public interface OrganizationRequest extends RequestContext {
InstanceRequestOrganizationProxy, Void persist();
}
public interface OrganizationService {
void persist( Organization organization );
}
After debugging the problem seems to be, that
OrganizationService.persist() is expected to have no arguments (which
makes only sense if the method is within the entity directly). Any
idea?
Thanks,
Stefan.
--
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.
