1 of 1 people found this helpful
Thanks for the feedback about the missing tutorial/guide. I've added a JIRA for a new tutorial that shows how to add Errai to an existing GWT application:
I am glad you had success getting up and running!
Regarding DevMode performance:
- Breaking down your app into separate GWT modules will definitely improve the startup and refresh time!
- A simpler way to achieve the same (in case modularization is a lot of work) is to configure white or black lists of types. So, basically you can tell Errai IOC which types or packages to ignore when generating code: ErraiApp.properties - Errai - Project Documentation Editor
- DevMode performance is a main area of focus for us in Errai 3 (and in GWT 3 as well). We've already made progress on speeding it up for marshalling on a separate branch that will hopefully be ready and merged into master in the next couple of days.
So a few steps forward: I was working on 2.4.3 Final as I was hesitant to work off of an in-progress release, but the white/black lists are 3.0. I upgraded to188.8.131.5231205-M3 and started by configuring the whitelist like:
I kept getting NullPointerExceptions(pasted below for reference). Running the debugger a bit, I learned that I needed to be whitelisting com.google.gwt.* It might be helpful on TypeInjector.getBeanInstance on or about line 219 to do something like:
if(creationalCallbackVarName == null)
throw new InjectionFailure("Failed to instantiate field: " + injectableInstance.getField().getName() + " type: " + injectableInstance.getField().getGenericType())
Also, it might not fit, but adding com.google.gwt.* to the implicitWhiteList in InjectionContext seems like a reasonable sanity measure too.
Unfortunately, this didn't really bring the refresh time down in development mode, it hovers right at 20 seconds per refresh :-/
NPE for not whitelisting com.google.gwt.*
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Caused by: java.lang.NullPointerException
Thanks, I've added com.google.gwt.* to the implicit type whitelist. I am definitely eager to find out why refreshing takes 20s in your case. Any diagnostic information you can provide would really be helpful.
For instance your console should log statements like this after refreshing: "generated marshalling class in ..ms", "generated IOC boostrapping class in ..ms". You can find those generated classes in your .errai folder (they should also point us to where the time is spent).
I don't see exactly the log statements you're looking for in the devmode gui logs (which I set to -logLevel DEBUG). If I need to increase logging elsewhere, let me know. Also, the increased logging significantly slows it down too, adding about 10s it seems. In case you're wondering, I have a pretty quick development workstation with SSDs -- non-errai devmode is plenty fast.
00:00:38.897 [INFO] Loading module erraitest
... ( stuff that takes about 3.3s)
00:00:42.279 [DEBUG] Rebinding org.jboss.errai.marshalling.client.api.MarshallerFactory
00:00:46.600 [INFO] Checking ErraiApp.properties for configured types ...
00:00:53.700 [DEBUG] Generator returned type 'org.jboss.errai.marshalling.client.api.MarshallerFactoryImpl; mode USE_ALL_NEW_WITH_NO_CACHING; in 10885 ms
00:00:56.068 [DEBUG] Rebinding org.jboss.errai.marshalling.client.api.MarshallerFramework
00:00:56.101 [DEBUG] Rebinding org.jboss.errai.bus.client.api.messaging.MessageBus
... (rebinding standard GWT packages) ...
00:01:05.850 [DEBUG] Rebinding org.jboss.errai.ioc.client.QualifierEqualityFactory
00:01:06.355 [DEBUG] Rebinding org.jboss.errai.ioc.client.container.IOCEnvironment
00:01:06.366 [DEBUG] Rebinding org.jboss.errai.ioc.client.Bootstrapper
00:01:06.881 [DEBUG] Rebinding org.jboss.errai.databinding.client.BindableProxyLoader
00:01:07.155 [INFO] Module erraitest has been loaded
From the log it looks like generating the marshallers took almost 11 seconds. Do you have a lot of @Portable types in your project?
I have just pushed the marshaller generator improvements which speed up marshaller generation quite a bit. Can you try using the latest 3.0-SNAPSHOTs and see if it improves this situation? For our test suite and a community user (who built a huge application) this change made a big difference.
Still taking roughly 20 seconds to refresh on 3.0-SNAPSHOT. I do see that the timing from before that was 11 seconds is down to 6 seconds, looks like a big improvement!
To answer your other question, we currently have 2 classes defined as @Portable, 1 class is @EntryPoint, and 1 class is @Templated as we're still evaluating this as a new platform. For the fun of it, I deleted everything that wasn't Errai from our project, and I can refresh DevMode in about 2 seconds. I've also tried pretty exhaustively to white/black-list out everything except the Errai code. My guess is that something is still scanning the non-Errai code we have.
Unless you know of other things I should try, I'm going to try to re-structure some to lower the class-scanning overhead. We have about 1,500 java/GWT UI files and (unfortunately) that expands out to around 10,000 .class files since we have a ton of anonymously implemented callbacks, handlers, etc.
OK thanks for the update. You can take a look at all the generated Errai files in your .errai folder, especially the generated BootstrapperImpl.java. It should NOT contain the classes you blacklisted. Is that the case for you?
Looking through our scanning logic I see that our GwtValidatorScanner that doesn't limit itself to Errai modules (GWT modules that have an ErraiApp.properties). So, that's a scanner that would run through the whole classpath. Do you inherit from org.jboss.errai.validation.Validation? If so, there's a special blacklist property you could use (errai.validation.blacklist).
We are actively working on improving the DevMode start up and refresh performance. Any feedback you have is really appreciated!
BootstrapperImpl.java is ~600 lines long and only contains references to the 4 classes that I would expect.
I was not inheriting org.jboss.errai.validation.Validation, but I added it and the blacklist property, and had no discernible difference. I think the net result of adding it and blacklisting it was to tell it to do nothing though
Could you inspect all matching annotated classes/templates and if the sum-total hash of all the files was unchanged from the previous generate operation, you skip that phase and just let it use the old copies? I don't know much about the intricacies of your libraries and may be over-simplifying what you need to do, but that's what we do in some of the in-house model/view/controller generator code we have to keep from constantly re-generating the same code.
So I've spent the last few days on 3.0-SNAPSHOT with some successes and some failures, one thing I'm confused about is the (seemingly) rigorous package structure needed for Errai to function properly. In the sample archetype, there are 3 main packages:
1 of 1 people found this helpful
If you want to change this default you can specify a source path in your gwt.xml file (i.e. <source path="shared" />):
Ha, shoot...you're right. Apologies for throwing blame on that one