Re: GWT app doesn't work behind reverse proxy

[David Hoffer]

Jens,

Thanks for the reply and information, it sounds like there is a workaround
then for the GWT part but we still have the same/similar issue with
Tomcat's authentication.  We need to solve that too else its only a partial
solution.

Btw, regarding the GWT serialization issue...I read online some say a way
around this is to use IsSerializable instead of Serializable to mark
objects going across the wire but its not clear if that 'trick' still works
or not.  Also some say to drop GWT RPC and use JSON instead that doesn't
have the same issue.  I don't really care what the format of the data is
going across the wire, I just need the results to work.  Is there an easy
way to switch the RPC format to JSON or some other format that doesn't have
this issue?

-Dave



On Thu, Jul 9, 2015 at 9:29 AM, Jens  wrote:

> The "issue" is that GWT will send you the moduleBaseURL as payload from
> the client to the server and the server uses that value to find the RPC
> policy file on disk. When you use a reverse proxy then the moduleBaseURL
> will not change when passing the proxy, it will always be
> http://domain.com/appname/ or http://domain.com/
> (depends on how you deploy your app). Because of this GWT's default
> implementation of RemoteServiceServlet.doGetSerializationPolicy() does not
> work anymore as it tries to match the moduleBaseURL with the server context
> path which can now be totally different because of the proxy.
>
> So you either have to write custom code to find the RPC policy file on
> your server (thats what I also do at the moment) or you can try overriding
> the default moduleBaseURL on the client by using  content='baseUrl=/appcontext/myapp'> in your host page.
>
> Also keep in mind when you use a reverse proxy that you might need to
> rewrite cookie domains / paths as well. In apache you can do that with
> ProxyPassReverseCookieDomain and ProxyPassReverseCookiePath.
>
>
> -- J.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/Zi_dtUEePlY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: GWT throws random IllegalArgumentException in DevMode

[David Hoffer]

I did try to upgrade to 2.7-rc1 but got some compiler errors, I also
upgraded the gwt maven plugin to 2.7-rc1.  Then I read that SDM was the
default so I added the flag so that DM would be used...but still got the
compiler errors.  Could be that I have some 3rd party GWT code that isn't
compatible or something like that.

I read on http://mojo.codehaus.org/gwt-maven-plugin/whats_new.html that
2.7-rc1 was updated to use 2.6.1??  That seems wrong to me.

So I went back to 2.6.1 as I'm not ready for SDM yet.

-Dave

On Mon, Nov 10, 2014 at 3:27 AM, Thomas Broyer  wrote:

> Then I can't understand how that could happen, sorry… (unless isScript()
> erroneously evaluated to 'true' maybe?)
> That code has changed slightly in 2.7 (for nearly the reverse behavior as
> you're seeing: issue 8548
> ) so
> maybe you could try the RC1?
>
> If you can find the JS snippet corresponding to Impl::apply in Firefox dev
> tools, then maybe you could set a breakpoint there and try to understand
> why/when that happens.
>
>
> On Monday, November 10, 2014 1:06:56 AM UTC+1, dhoffer wrote:
>>
>> I'm using Firefox ESR 24.2.0.
>>
>>
>>
>> On Sun, Nov 9, 2014 at 4:39 PM, Thomas Broyer  wrote:
>>
>>> I'd bet you're using Chrome. Search the issue tracker, it's a known bug
>>> with Chrome and the Dev plugin.
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Google Web Toolkit" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>> topic/google-web-toolkit/Tjrj4HVY10E/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> google-web-toolkit+unsubscr...@googlegroups.com.
>>> To post to this group, send email to google-web-toolkit@googlegroups.com
>>> .
>>> Visit this group at http://groups.google.com/group/google-web-toolkit.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/Tjrj4HVY10E/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: GWT throws random IllegalArgumentException in DevMode

[David Hoffer]

I'm using Firefox ESR 24.2.0.



On Sun, Nov 9, 2014 at 4:39 PM, Thomas Broyer  wrote:

> I'd bet you're using Chrome. Search the issue tracker, it's a known bug
> with Chrome and the Dev plugin.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/Tjrj4HVY10E/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Development Mode will not be supported in Firefox 27+

[David Hoffer]

That is really good news.  I haven't tried this yet (need to upgrade IDEA
to 14) but it sounds like one gets most/all the benefits of DevMode
development/debugging yet it's really using SDM.  Very impressive.

-Dave

On Thu, Nov 6, 2014 at 6:55 AM, Jens  wrote:

> I'm using IntelliJ...I'd like to hear if/how IntelliJ can do this too.
>>
>
> With the released IntelliJ 14 things are a bit easier.
>
> - Create a new GWT run configuration and select "User Super Dev Mode" and
> at the bottom "with JavaScript debugger".
> - IntelliJ will automatically generate a JavaScript debugger run
> configuration. Open that run configuration and you should see your GWT
> project directory tree. In that tree navigate to your source folder (src or
> src/main/java) and double click on the "Remote URL" column next to it. The
> remote URL is where IntelliJ will download source map files from so you
> should paste in something like http://127.0.0.1:9876/sourcemaps/
> .
>
> Now launch the GWT SDM run configuration which should also automatically
> launch the JavaScript Debug configuration. Chrome should now tell you that
> IntelliJ is debugging your site (you may need to install the LiveEdit
> Chrome extension) and you should be able to set break points in your Java
> code and step through the code from within IntelliJ.
>
> Sometimes when you hit a break point the source map file isn't ready yet
> in IntelliJ (seems like a timing problem) and you see the pure JavaScript.
> But once you do the first "step over" IntelliJ should switch to the Java
> source by using source map information. Overall it works pretty well.
>
> But keep in mind that fields and expressions in conditional break points
> are still all JavaScript. You are not debugging Java!
>
> -- J.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Development Mode will not be supported in Firefox 27+

[David Hoffer]

I'm using IntelliJ...I'd like to hear if/how IntelliJ can do this too.

-Dave

On Mon, Nov 3, 2014 at 11:58 AM, Paul Robinson  wrote:

> If you're using eclipse and chrome, then sdbg is good. It's not perfect,
> but it is *much* better than browsing Java source and setting break points
> in the browser.
>
> Paul
> On 3 Nov 2014 17:49, "David Hoffer"  wrote:
>
>> I like where you might be going with your last paragraph (the IntelliJ
>> part)..."Other than that there is the experimental Eclipse plugin named
>> SDBG so you can use your IDE for debugging (but you are still debugging
>> JS!). IntelliJ can do the same out of the box."
>>
>> Are you saying that IntelliJ can somehow use SDM and still be debugging
>> in IntelliJ?  If so I'd like to know more about this.  I was thinking
>> that for SDM to be acceptable...somehow it has to get back to the IDE so I
>> can debug, navigate & edit in one tool.  If this is possible then SDM
>> starts to look better.
>>
>>
>> On Mon, Nov 3, 2014 at 8:36 AM, Jens  wrote:
>>
>>> I definitely use a MVP/C model but not Places.  I don't think I should
>>>> be tided to one and only one MVP approach.
>>>>
>>>
>>> Places are just for navigation. They have nothing to do with MVP. You
>>> can use them without GWTs Activity class.
>>>
>>>
>>>
>>>>   However even if I did it's not clear how that would help the fact
>>>> that the browser has a 'copy' or 'image' of the real thing...at the end of
>>>> the day I need my IDE to make changes.
>>>>
>>>
>>> Yeah it is a bit counter intuitive if you see your Java code in the
>>> browser and want to debug it. The best thing you can do is to place
>>> breakpoints and then step through the code. Navigating the code with
>>> something like ctrl + click as in Java IDEs is not possible with source
>>> maps (although you can search, open file, goto line using shortcuts). Also
>>> conditional break points obviously need to use JavaScript expressions. At
>>> the end you are debugging JavaScript that only got visually transformed
>>> into your original Java code to please your eyes.
>>>
>>> As an alternative you could try the following in Chrome:
>>> - use the SDM parameter -XmethodNameDisplayMode with your desired setting
>>> - Disable source maps in Chrome Dev Tools.
>>>
>>> Now you are dealing with the raw JavaScript (which already looks pretty
>>> similar to your Java code) but when hitting a breakpoint Chrome will
>>> display your Java class/method name for each stack element. So you kind of
>>> see a Java stack trace in Chrome but when clicking on it you see the raw JS
>>> code. The added benefit of using raw JS is that while a break point is
>>> active you can now hover JS code and Chrome will give you additional
>>> information about the code as well as a link to jump to the definition. And
>>> with the Java like stack trace it is easier to spot the code path in your
>>> IDE. Might be an interesting compromise.
>>>
>>> Other than that there is the experimental Eclipse plugin named SDBG so
>>> you can use your IDE for debugging (but you are still debugging JS!).
>>> IntelliJ can do the same out of the box.
>>>
>>> -- J.
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Google Web Toolkit" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> google-web-toolkit+unsubscr...@googlegroups.com.
>>> To post to this group, send email to google-web-toolkit@googlegroups.com
>>> .
>>> Visit this group at http://groups.google.com/group/google-web-toolkit.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Google Web Toolkit" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit+unsubscr...@googlegroups.com.
>> To post to this group, send email to google-web-toolkit@googlegroups.com.
>> Visit this group at http://groups.google.com/group/google-web-toolkit.
>> For more options, visit https://groups.google.com/d/op

Re: Development Mode will not be supported in Firefox 27+

[David Hoffer]

I like where you might be going with your last paragraph (the IntelliJ part
)..."Other than that there is the experimental Eclipse plugin named SDBG so
you can use your IDE for debugging (but you are still debugging JS!).
IntelliJ can do the same out of the box."

Are you saying that IntelliJ can somehow use SDM and still be debugging in
IntelliJ?  If so I'd like to know more about this.  I was thinking that for
SDM to be acceptable...somehow it has to get back to the IDE so I can
debug, navigate & edit in one tool.  If this is possible then SDM starts to
look better.


On Mon, Nov 3, 2014 at 8:36 AM, Jens  wrote:

> I definitely use a MVP/C model but not Places.  I don't think I should be
>> tided to one and only one MVP approach.
>>
>
> Places are just for navigation. They have nothing to do with MVP. You can
> use them without GWTs Activity class.
>
>
>
>>   However even if I did it's not clear how that would help the fact that
>> the browser has a 'copy' or 'image' of the real thing...at the end of the
>> day I need my IDE to make changes.
>>
>
> Yeah it is a bit counter intuitive if you see your Java code in the
> browser and want to debug it. The best thing you can do is to place
> breakpoints and then step through the code. Navigating the code with
> something like ctrl + click as in Java IDEs is not possible with source
> maps (although you can search, open file, goto line using shortcuts). Also
> conditional break points obviously need to use JavaScript expressions. At
> the end you are debugging JavaScript that only got visually transformed
> into your original Java code to please your eyes.
>
> As an alternative you could try the following in Chrome:
> - use the SDM parameter -XmethodNameDisplayMode with your desired setting
> - Disable source maps in Chrome Dev Tools.
>
> Now you are dealing with the raw JavaScript (which already looks pretty
> similar to your Java code) but when hitting a breakpoint Chrome will
> display your Java class/method name for each stack element. So you kind of
> see a Java stack trace in Chrome but when clicking on it you see the raw JS
> code. The added benefit of using raw JS is that while a break point is
> active you can now hover JS code and Chrome will give you additional
> information about the code as well as a link to jump to the definition. And
> with the Java like stack trace it is easier to spot the code path in your
> IDE. Might be an interesting compromise.
>
> Other than that there is the experimental Eclipse plugin named SDBG so you
> can use your IDE for debugging (but you are still debugging JS!). IntelliJ
> can do the same out of the box.
>
> -- J.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Development Mode will not be supported in Firefox 27+

[David Hoffer]

I definitely use a MVP/C model but not Places.  I don't think I should be
tided to one and only one MVP approach.  However even if I did it's not
clear how that would help the fact that the browser has a 'copy' or 'image'
of the real thing...at the end of the day I need my IDE to make changes.

-Dave

On Mon, Nov 3, 2014 at 7:51 AM, Timothy Michael Spear 
wrote:

> David,
>
> The problem is a fundamental disconnect in approach. In using Places, and
> the MVP model, your application is supposed to be a series of much smaller
> applications with minimal navigation required to re-enter a specific point.
> I have very mixed perceptions on this multi-entry point development.
>
> Tim
>
>
> From: David Hoffer 
> Reply-To: 
> Date: Monday, November 3, 2014 at 9:45 AM
> To: Google Web Toolkit 
> Subject: Re: Development Mode will not be supported in Firefox 27+
>
> IMO, the loss of DevMode is a huge problem for GWT, I understand
> SuperDevMode is its replacement but unfortunately that is no where near a
> true replacement at least not yet.
>
> It's a bit hard to explain unless you have used both approaches on a large
> project but the best way I can think of to explain it is that in
> SuperDevMode you see an 'opaque' version of your source in the browser.  So
> yes you can 'see' your Java source in the browser and you can debug
> it...but that's about it.  E.g. you get to have an image or a copy of your
> source in the browser.  However that's all you get in SuperDevMode what you
> don't get is the ability to find and edit your source code.  I have an app
> with hundreds of classes in the client side, there are no tools like my IDE
> has for finding the code i want to jump to so I can inspect, set break
> points, edit code, etc.
>
> So with SuperDevMode everything has to be done twice, you can debug in the
> browser (but navigating the code is very painful) but then when you need to
> make changes you need to re-navigate the code over in the IDE, edit the
> code, and re-deploy.  So in effect the code in the browser is an image of
> the real code...you can't do anything with it really.
>
> I find SuperDevMode to be incredibly inefficient in developing GWT
> applications, especially large ones where the strength of GWT is evident.
> SuperDevMode might be fine for later stages of development, e.g. testing
> stages where you don't need to make large code changes but rather just need
> to fine tune what GWT generated but it's inadequate for development stages.
> Personally I'm keeping an an old version of Firefox so that I can continue
> to use DevMode.
>
> Please let me know if I'm missing something here or are other approaches.
>
> -Dave
>
>
> On Mon, Nov 3, 2014 at 6:21 AM, Leejjon  wrote:
>
>> There's a developer version of Firefox coming out:
>>
>> https://blog.mozilla.org/blog/2014/11/03/the-first-browser-dedicated-to-developers-is-coming/
>>
>> Maybe we can ask Mozilla to export the C++ symbols in this developer
>> version, so the GWT dev plugin can work on this developer version of
>> Firefox.
>>
>> Op dinsdag 4 februari 2014 01:01:41 UTC+1 schreef Brian Slesinsky:
>>>
>>> Mozilla has stopped exporting some C++ symbols that the Firefox plugin
>>> relies on [1]. Therefore it's not possible to support Development Mode in
>>> any new versions of Firefox starting with 27.
>>>
>>> As a workaround, I am doing one last release to get the plugin working
>>> again with Firefox 24.2 (and hopefully newer point releases on the ESR
>>> track). If you wish to continue to use Development Mode on Firefox, you
>>> will need to download this version from Mozilla [2]. For more details see
>>> the issue tracker [3].
>>>
>>> Long-term, the plan is to improve Super Dev Mode.
>>>
>>> I apologize for the late notice; when I said at GWT.create that Firefox
>>> could stop working with any release, I didn't expect it to be the next one.
>>>
>>> - Brian
>>>
>>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=920731
>>> [2] http://download.cdn.mozilla.net/pub/mozilla.org/firefox/
>>> releases/24.2.0esr/
>>> [3] https://code.google.com/p/google-web-toolkit/issues/detail?id=8553
>>>
>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Google Web Toolkit" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe
>> .
>> To unsubscribe from this group an

Re: Development Mode will not be supported in Firefox 27+

[David Hoffer]

IMO, the loss of DevMode is a huge problem for GWT, I understand
SuperDevMode is its replacement but unfortunately that is no where near a
true replacement at least not yet.

It's a bit hard to explain unless you have used both approaches on a large
project but the best way I can think of to explain it is that in
SuperDevMode you see an 'opaque' version of your source in the browser.  So
yes you can 'see' your Java source in the browser and you can debug
it...but that's about it.  E.g. you get to have an image or a copy of your
source in the browser.  However that's all you get in SuperDevMode what you
don't get is the ability to find and edit your source code.  I have an app
with hundreds of classes in the client side, there are no tools like my IDE
has for finding the code i want to jump to so I can inspect, set break
points, edit code, etc.

So with SuperDevMode everything has to be done twice, you can debug in the
browser (but navigating the code is very painful) but then when you need to
make changes you need to re-navigate the code over in the IDE, edit the
code, and re-deploy.  So in effect the code in the browser is an image of
the real code...you can't do anything with it really.

I find SuperDevMode to be incredibly inefficient in developing GWT
applications, especially large ones where the strength of GWT is evident.
SuperDevMode might be fine for later stages of development, e.g. testing
stages where you don't need to make large code changes but rather just need
to fine tune what GWT generated but it's inadequate for development stages.
Personally I'm keeping an an old version of Firefox so that I can continue
to use DevMode.

Please let me know if I'm missing something here or are other approaches.

-Dave


On Mon, Nov 3, 2014 at 6:21 AM, Leejjon  wrote:

> There's a developer version of Firefox coming out:
>
> https://blog.mozilla.org/blog/2014/11/03/the-first-browser-dedicated-to-developers-is-coming/
>
> Maybe we can ask Mozilla to export the C++ symbols in this developer
> version, so the GWT dev plugin can work on this developer version of
> Firefox.
>
> Op dinsdag 4 februari 2014 01:01:41 UTC+1 schreef Brian Slesinsky:
>>
>> Mozilla has stopped exporting some C++ symbols that the Firefox plugin
>> relies on [1]. Therefore it's not possible to support Development Mode in
>> any new versions of Firefox starting with 27.
>>
>> As a workaround, I am doing one last release to get the plugin working
>> again with Firefox 24.2 (and hopefully newer point releases on the ESR
>> track). If you wish to continue to use Development Mode on Firefox, you
>> will need to download this version from Mozilla [2]. For more details see
>> the issue tracker [3].
>>
>> Long-term, the plan is to improve Super Dev Mode.
>>
>> I apologize for the late notice; when I said at GWT.create that Firefox
>> could stop working with any release, I didn't expect it to be the next one.
>>
>> - Brian
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=920731
>> [2] http://download.cdn.mozilla.net/pub/mozilla.org/firefox/
>> releases/24.2.0esr/
>> [3] https://code.google.com/p/google-web-toolkit/issues/detail?id=8553
>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: GWT using SDM throws error at app startup

[David Hoffer]

My bad.  Somehow I almost convinced myself that GWT was wrapping my 'view'
variable with a getter called getView that I didn't see what the stack
trace was really telling me. (If I would have called my variable x this
would have been obvious.)  Yes you are right there was a case where a
widget that does have a getView method could be called at startup where the
instance is null.  I have corrected this and all works well.  I had tried
to load the JS file in notepad++ but it's so large it crashed the editor,
thanks for the debugging tips & link to the Chrome shortcuts I will check
this out as well.

-Dave



On Sun, Aug 31, 2014 at 3:43 AM, Jens  wrote:

> The stack trace says the error is inside setBookingSheetRowData().
>
> But just don't be afraid to look at the JS code. Open Chrome Dev Tools, go
> to the sources tab, open adloader-0.js (and wait a bit as it is maybe a
> large file), hit ctrl + g and enter the line numbers of the stack trace.
> For setBookingSheetRowData() it is line number 104761 and for $getView it
> is 31671. The JS code will look relatively similar to your Java code, as
> GWT does not do any optimizations.
> Then you can set a breakpoint to see what is going on. You can also set a
> breakpoint on "java" level by going to the sources tab, hit ctrl + o to
> open LoadAdsPrepareGridPresenter.java provided by source maps and then
> set a breakpoint for view.setBookingSheetRowData(model.
> getGridBookingSheetRowModels());
>
> Some shortcuts to know:
> https://developer.chrome.com/devtools/docs/shortcuts
>
> -- J.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/1lsSTQluIxE/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: GWT using SDM throws error at app startup

[David Hoffer]

Hum...I'm not entirely clear how that maps to the java code.  As I follow
that stack trace I think this comes down to this code:

public class LoadAdsPrepareGridPresenter {

private final ILoadAdsPrepareGridModel model;
private final ILoadAdsPrepareGridView view;

public LoadAdsPrepareGridPresenter(final ILoadAdsPrepareGridModel model,
   final ILoadAdsPrepareGridView view) {
this.model = model;
this.view = view;

model.addListener(new ILoadAdsPrepareGridModelListener() {
@Override
public void gridRowsChanged() {
view.setBookingSheetRowData(
model.getGridBookingSheetRowModels());
}
});

So are you saying that the member variable 'view' is null?  This is
injected into the class so it's not possible for it to be null...and it's
final.

Or are you saying that view is not null but it's somehow calling getView()?
 I don't think this is the case but I wanted to be sure.  (In my java code
the view doesn't have any method called 'getView()' I'm assuming
'getView()' is something generated by GWT to get the view variable.).

-Dave



On Sat, Aug 30, 2014 at 12:58 PM, Jens  wrote:

> GWT often (if not always) transforms methods that are not overridden into
> static methods. Such static methods begin with a $ sign.
>
> In your stack trace you can see Unknown.$getView is causing the exception
> with message "Can not read property 'view' of undefined". That basically
> means in your Java code you have called null.getView() because GWT
> transforms this into something like $getView(instance) { return
> instance.view; } with instance being "undefined" (= null).
>
> So it is either a bug in your app which can cause NullPointer exceptions
> or you have found a very rare case which causes the GWT compiler to produce
> wrong JS.
>
> -- J.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/1lsSTQluIxE/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: GWT SDM throws error inspecting results in Chrome debugger

[David Hoffer]

To be more clear...this happens just stepping into the code.

-Dave


On Fri, Aug 22, 2014 at 8:17 PM, dhoffer  wrote:

> I finally got SuperDevMode to work and am trying to debug using Chrome but
> when I step through the code when I get to the lower level it always throws
> and exception like the following so I haven't been able to inspect any
> variables yet. What is causing this?
>
> SEVERE: (TypeError) __gwt$exception: : Cannot read property
> 'name_0' of null com.google.gwt.core.client.JavaScriptException:
> (TypeError) __gwt$exception: : Cannot read property 'name_0' of
> null: at Unknown.$getName_7(adloader-0.js@21:86301)
>
> I'm using GWT version 2.6.1
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/KmfMH0Xo-BM/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Need to add HTML5 desktop to browser DnD support in GWT application

[David Hoffer]

Nicolas,

Thanks much for the link to this component.  I had found a couple similar
ones but found this one to be the best, it really works great.  Thanks
again for the link.

-Dave

P.S. I would think that GWT ought to have this as a core feature.


On Mon, Feb 24, 2014 at 12:24 PM, Nicolas Weeger  wrote:

> Hello.
>
>
> I didn't have yet the occasion to play with it and it's one year old, but
> GWT Uploader on http://www.moxiegroup.com/moxieapps/gwt-uploader/ seems
> to do the kind of things you require.
>
>
> Hope this helps
>
>
> Regards
>
>
> Nicolas
>
>
>
> Le 2014-02-21 17:04, dhoffer a écrit :
>
>> I need to have a widget that accepts DnD files from the desktop, how
>> can I do this in a GWT 2.5.1 application? See the link below for the
>> JS code to do this. Does GWT already have a widget for this? If not
>> how could I create my own?
>>
>> From the link below I understand it all starts with a div in the
>> rendered HTML and then wires in support for DnD with the JS code shown
>> in the link. So in my case I'm starting with a GWT layout and need to
>> add this 'widget' to that existing layout. I've never created my own
>> GWT widget before, would I start with an existing GWT widget and then
>> add the JS via JSNI? If so, what would be the best starting widget to
>> build on?
>>
>> http://www.htmlgoodies.com/html5/jav...id=TdDQb7R8c9d [1]
>>
>>  --
>>  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
>> [2].
>>  For more options, visit https://groups.google.com/groups/opt_out [3].
>>
>>
>> Links:
>> --
>> [1]
>> http://www.htmlgoodies.com/html5/javascript/drag-files-
>> into-the-browser-from-the-desktop-HTML5.html#fbid=TdDQb7R8c9d
>> [2] http://groups.google.com/group/google-web-toolkit
>> [3] https://groups.google.com/groups/opt_out
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/google-web-toolkit/DPk4mMgJVFE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/groups/opt_out.
>

-- 
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: GWTBridgeImpl throws com.google.gwt.core.ext.UnableToCompleteException exception

[David Hoffer]

Thanks for the suggestions.  Yes I too find that I have to delete
gwtUnitCache on occasion so
yes I had tried (several times) that thinking it would help but it didn't
in this case.  However I'm not sure about symbolMaps where are those
located?

Regarding the script vs. IDE build issue...I only use the Maven build
because there are some issues building the app with the IDE so I don't even
bother to try...our CI build system uses the Maven build so to be
consistent that is what I use too.  IDE is just to code/debug.

-Dave


On Mon, Jan 13, 2014 at 8:20 AM, jonl  wrote:

> This could be as simple as the gwtUnitCache or the symbolMaps getting
> corrupted.  Happens every now and then and a clean of the gwt-build
> environment is the only way to fix it.  I delete my gwtUnitCache and the
> built war directories every time I build from scropt to prevent this kind
> of thing.  If running a script build and running hosted mode from the same
> base, it also best to make sure that your script builds to a directory that
> your IDE does not.  Otherwise their could be cross contamination of
> compilations creating incompatibilities in the compiled version.
>
>
> On Thursday, January 9, 2014 9:03:40 AM UTC-7, dhoffer wrote:
>>
>> I was finally able to get this working in hosted mode again but I'm not
>> exactly sure why.  All the evidence points to a bug in IntelliJ as the fix
>> involved deleting the IntelliJ project files and rebuilding from the Maven
>> pom files and messing with the JDK version both specified in the Maven pom
>> files and in IntelliJ.
>>
>> I've seen cases before where IntelliJ gets confused by the Maven project
>> and just looses dependencies, but that did not seem to be occurring in this
>> case.  Also IntelliJ does not handle well cases where, in a multi-module
>> build, modules use more than one JDK version.  And that is my case due to
>> GWT not supporting JDK7 yet.
>>
>> That being said...it's possible that I don't have the JDK version
>> specified properly in my Maven pom files.  I'd like to know how best to
>> configure the JDK in the Maven build when using GWT.  Here is my use case:
>>
>> I have a multi-module build where my runtime JDK has to be 7.0.  In
>> addition I have lots of dependencies that were built with JDK7 so I have to
>> use that as my main compiler for my build.  In my maven project I have one
>> child folder that handles all the GWT parts of the build.  That GWT parent
>> folder has the following 3 modules:
>>
>> myapp-gwt-api
>> - Module that contains shared code between myapp-gwt-dev & both the
>> client and server portion of myapp-gwt-war
>> - This module is of type pom but it generates a jar.  I presume this was
>> made a pom type to give full control over what goes in the jar, the build
>> is configured to compile and then include both the classes and the java
>> source in the jar.  However in this build the JDK version is not specified
>> in the maven-compiler-plugin configuration...so I guess it uses some
>> default?  In retrospect it seems the classes could use JDK7 as that is what
>> all the server side code uses but the java source has to be JDK6 compatible
>> else the GWT compiler won't be able to use the source.
>>
>> myapp-gwt-dev
>> - Module that contains GWT rebind code.  Our project makes heavy use of
>> GWT's rebind code generation feature so all the code that is needed to
>> rebind/generate code is in this module.
>> - This module has a dependency on myapp-gwt-api
>> - This module is of type pom but generates a jar.  This module appears to
>> be just like the previous one...it generates a jar with both classes and
>> source files.
>> - Also this module gets the GWT compiler classes from the gwt-dev jar and
>> puts them in this module.  I presume this is so that in the next module GWT
>> has all that it needs to perform the GWT rebind operation without having to
>> add a dependency on gwt-dev in the war module.  Also it would serve as a
>> way to keep the rebind code out of the war...as that is not needed at
>> runtime.
>>
>> myapp-gwt-war
>> - This is the main GWT module and is of type war.
>> - It has a dependency on myapp-gwt-api and on myapp-gwt-dev however in
>> the later case it has provided scope to stop it from going into the wars
>> runtime dependencies.
>> - This module uses gwt-maven-plugin to compile the GWT application,
>> however the JDK version is not specified so I assume that uses a GWT
>> default?
>> - In this module, in the maven-compiler-plugin, we do specify the JDK
>> version, it's set to 1.6 for both source & target.  I'm not clear what this
>> should be.  Ideally we would want the source & target to be 1.7 for the
>> server side code.  However the client side source has to be 1.6 for GWT.
>>  And does this setting affect what compiler is used by the
>> gwt-maven-plugin, or is that completely separate?
>>
>> Now that I get to the end of analysis of the Maven build I see that that
>> the maven-compiler-plugin is configured in the plug

Re: GWT/JavaScript code generation tool

[David Hoffer]

How do you handle that same case when writing the wrapper manually?  Do you
manually inspect the method to see what are allowed types and then define
the java wrapper appropriately?  Or do you just go with Object and let the
user of the wrapper code figure out what is allowed?  Again, this might be
naive as I haven't tried to write a tool but I think I'd be okay with the
tool just using Object to start with then it would be great if the tool
allowed me to customize/tailor the type mapping once it's known what the
allowed types are.  Not sure how that would be accomplished as one probably
can't add comments/annotations to existing library code.  I'd love to see
what the SWIG folks think about this there the experts on this sort of
thing (I did post a message there).

-Dave


On Wed, Dec 11, 2013 at 12:19 PM, Jens  wrote:

> For example take the following JS code
>>
>> function doSomething(o){
>>
>> }
>>
>> How would a tool what the type of o is. Object ? Number ? String ?
>>
>
>
> That's what I thought too and I think thats the reason why such a tool
> does not exist. JavaScript is too dynamic to make such code generation work
> reliably.
>
> -- J.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/GkvZUIs2knY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/groups/opt_out.
>

-- 
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/groups/opt_out.

Re: GWT/JavaScript code generation tool

[David Hoffer]

Okay sounds like you've thought about the GXT option/issues.


On Wed, Dec 11, 2013 at 12:02 PM, Alain Ekambi wrote:

> @David
>
> Good question. I actually get this question all the time.
>
> Ext4j is for people that want to (or are already using) use Ext JS in
> their project.
> Below are a coupe of reasons why I decided to write a wrapper instead of
> using GXT.
> Which by the way  is a great tool but dont quit meet the requirements of
> my customers.
>
>
> 1) Licensing.
> Most of my customers already have an Ext JS license and are not willing to
> pay for another product.
> Since Ext4j wil be Apache nothing will change for existing Ext JS c users.
>
> 2) Develeopement Pace
> Ext JS is always a step ahead of GXT when it comes to features,
> components, themes etc..
>
> 3) Community.
> The Ext JS  community seems a bit more active than the GXT one. There for
> example way more extensions for Ext JS than GXT. One could argue that it s
> easy to create those in GXT but no one does.
>
> 4) Look and feel
> This is a bit subjective but I found that Ext looks a bit better than GXT
>
> 5) Code Reuse.
> People I work  for most of the time also want a mobile client next to
> their  desktop client. Ext4j will play more nicely with some  mobile
> wrappers I wrote. I could nt get GXT to work with  my existing tools.
>
>
> So if you want to build on Top of Ext JS and add structure programming and
> the powerful Java ecosystem Ext4j could help.
>
> Otherwise simply go with GXT.
>
>
> 2013/12/11 Alain Ekambi 
>
>> Unlike C++ JavaScript is a dynamic language.
>> I m just not sure it s possible  for such a tool to generate descent
>> wrapper for JS code.
>>
>> For example take the following JS code
>>
>> function doSomething(o){
>>
>> }
>>
>> How would a tool what the type of o is. Object ? Number ? String ?
>>
>> Commenting the code could be a solution (Like Closure does).
>> But  not all JS libraries have descent comment informations.
>>
>> That s why I m saying I m not sure  how such a tool  would work for every
>> given JS library.
>> But I might be wrong though.
>>
>>
>> 2013/12/11 David Hoffer 
>>
>>> Alain,
>>>
>>> Your in the process of writing a wrapper so you might know if there are
>>> technical hurdles that would prevent this...but I think it would be
>>> possible.  The folks at SWIG manage to auto generate wrapper code starting
>>> with incredibly complex C++ code and manage to generate perfectly fine Java
>>> wrapper code (as well as about a dozen other languages)...so it seems that
>>> it would be possible.
>>>
>>> -Dave
>>>
>>>
>>> On Wed, Dec 11, 2013 at 11:40 AM, Alain Ekambi 
>>> wrote:
>>>
>>>> Would be nice. I m just not sure if that can work for every JS library
>>>> out there.
>>>> I heard that GWT 3 will have a better interop with JS libraries.
>>>> Just not sure how that will work.
>>>>
>>>>
>>>> 2013/12/11 Juan Pablo Gardella 
>>>>
>>>>> It is more easy if we have a tool that writes the wrapper for us, but
>>>>> for now I suppose this tool does not exist, but will be very useful.
>>>>>
>>>>>
>>>>> 2013/12/11 Alain Ekambi 
>>>>>
>>>>>> What about writing a wrapper ?
>>>>>> I m not sure it s even possible to "auto wrap"  everything exisiting
>>>>>>  js library.
>>>>>> I m writing a wrapper for Ext JS and  there are some "places"   that
>>>>>> I m not sure they can be auto generated.
>>>>>>
>>>>>>
>>>>>> 2013/12/11 Juan Pablo Gardella 
>>>>>>
>>>>>>> I like a tool for that. If some tool exists, GWT will be very
>>>>>>> attractive because currently a big problem is that is not very easy 
>>>>>>> reuse
>>>>>>> javascript libs.
>>>>>>>
>>>>>>>
>>>>>>> 2013/12/11 dhoffer 
>>>>>>>
>>>>>>>> Are there any tools out there that can auto generate the GWT
>>>>>>>> wrapper code for native JavaScript code?  I'm looking for a way to 
>>>>>>>> automate
>>>>>>>> using JavaScript in GWT applications, sometimes it's best to start 
>>>>>>>> with an
>>>>&g

Re: GWT/JavaScript code generation tool

[David Hoffer]

Alain,

This is off topic...but you said your writing a GWT wrapper for Ext JS?
 Why not just use GXT (Sencha's pure GWT library)?

-Dave


On Wed, Dec 11, 2013 at 11:42 AM, David Hoffer  wrote:

> Alain,
>
> Your in the process of writing a wrapper so you might know if there are
> technical hurdles that would prevent this...but I think it would be
> possible.  The folks at SWIG manage to auto generate wrapper code starting
> with incredibly complex C++ code and manage to generate perfectly fine Java
> wrapper code (as well as about a dozen other languages)...so it seems that
> it would be possible.
>
> -Dave
>
>
> On Wed, Dec 11, 2013 at 11:40 AM, Alain Ekambi wrote:
>
>> Would be nice. I m just not sure if that can work for every JS library
>> out there.
>> I heard that GWT 3 will have a better interop with JS libraries.
>> Just not sure how that will work.
>>
>>
>> 2013/12/11 Juan Pablo Gardella 
>>
>>> It is more easy if we have a tool that writes the wrapper for us, but
>>> for now I suppose this tool does not exist, but will be very useful.
>>>
>>>
>>> 2013/12/11 Alain Ekambi 
>>>
>>>> What about writing a wrapper ?
>>>> I m not sure it s even possible to "auto wrap"  everything exisiting
>>>>  js library.
>>>> I m writing a wrapper for Ext JS and  there are some "places"   that I
>>>> m not sure they can be auto generated.
>>>>
>>>>
>>>> 2013/12/11 Juan Pablo Gardella 
>>>>
>>>>> I like a tool for that. If some tool exists, GWT will be very
>>>>> attractive because currently a big problem is that is not very easy reuse
>>>>> javascript libs.
>>>>>
>>>>>
>>>>> 2013/12/11 dhoffer 
>>>>>
>>>>>> Are there any tools out there that can auto generate the GWT wrapper
>>>>>> code for native JavaScript code?  I'm looking for a way to automate using
>>>>>> JavaScript in GWT applications, sometimes it's best to start with an
>>>>>> existing JavaScript client library and wrap for use in GWT.  I have in 
>>>>>> mind
>>>>>> the CometD JS client library for instance.  Ideally I'd like to integrate
>>>>>> this with the maven build.  What I'm looking for is exactly like SWIG for
>>>>>> generating wrapper code from existing C/C++ code.
>>>>>>
>>>>>> -Dave
>>>>>>
>>>>>> --
>>>>>> 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/groups/opt_out.
>>>>>>
>>>>>
>>>>>  --
>>>>> 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/groups/opt_out.
>>>>>
>>>>
>>>>  --
>>>> 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/groups/opt_out.
>>>>
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Go

Re: GWT/JavaScript code generation tool

[David Hoffer]

Alain,

Your in the process of writing a wrapper so you might know if there are
technical hurdles that would prevent this...but I think it would be
possible.  The folks at SWIG manage to auto generate wrapper code starting
with incredibly complex C++ code and manage to generate perfectly fine Java
wrapper code (as well as about a dozen other languages)...so it seems that
it would be possible.

-Dave


On Wed, Dec 11, 2013 at 11:40 AM, Alain Ekambi wrote:

> Would be nice. I m just not sure if that can work for every JS library out
> there.
> I heard that GWT 3 will have a better interop with JS libraries.
> Just not sure how that will work.
>
>
> 2013/12/11 Juan Pablo Gardella 
>
>> It is more easy if we have a tool that writes the wrapper for us, but for
>> now I suppose this tool does not exist, but will be very useful.
>>
>>
>> 2013/12/11 Alain Ekambi 
>>
>>> What about writing a wrapper ?
>>> I m not sure it s even possible to "auto wrap"  everything exisiting  js
>>> library.
>>> I m writing a wrapper for Ext JS and  there are some "places"   that I m
>>> not sure they can be auto generated.
>>>
>>>
>>> 2013/12/11 Juan Pablo Gardella 
>>>
 I like a tool for that. If some tool exists, GWT will be very
 attractive because currently a big problem is that is not very easy reuse
 javascript libs.


 2013/12/11 dhoffer 

> Are there any tools out there that can auto generate the GWT wrapper
> code for native JavaScript code?  I'm looking for a way to automate using
> JavaScript in GWT applications, sometimes it's best to start with an
> existing JavaScript client library and wrap for use in GWT.  I have in 
> mind
> the CometD JS client library for instance.  Ideally I'd like to integrate
> this with the maven build.  What I'm looking for is exactly like SWIG for
> generating wrapper code from existing C/C++ code.
>
> -Dave
>
> --
> 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/groups/opt_out.
>

  --
 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/groups/opt_out.

>>>
>>>  --
>>> 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/groups/opt_out.
>>>
>>
>>  --
>> 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/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/GkvZUIs2knY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/groups/opt_out.
>

-- 
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/groups/opt_out.

Re: GWT/JavaScript code generation tool

[David Hoffer]

Right, seems it would have a wide range of uses and could jump-start the
usage of GWT.  I wonder if the SWIG folks have looked at this, it seems
perfect and an easy use case for them...except that the source is JS
instead of C/C++.

-Dave


On Wed, Dec 11, 2013 at 11:20 AM, Juan Pablo Gardella <
gardellajuanpa...@gmail.com> wrote:

> I like a tool for that. If some tool exists, GWT will be very attractive
> because currently a big problem is that is not very easy reuse javascript
> libs.
>
>
> 2013/12/11 dhoffer 
>
>> Are there any tools out there that can auto generate the GWT wrapper code
>> for native JavaScript code?  I'm looking for a way to automate using
>> JavaScript in GWT applications, sometimes it's best to start with an
>> existing JavaScript client library and wrap for use in GWT.  I have in mind
>> the CometD JS client library for instance.  Ideally I'd like to integrate
>> this with the maven build.  What I'm looking for is exactly like SWIG for
>> generating wrapper code from existing C/C++ code.
>>
>> -Dave
>>
>> --
>> 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/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/GkvZUIs2knY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/groups/opt_out.
>

-- 
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/groups/opt_out.

Re: GWT and Web Security

[David Hoffer]

That's good information.  I had no idea Guice supported AOP, I've been
using Guice for IoC and Spring Security for security functionality.  (I too
have an aversion to Spring for IoC but I don't have a preference yet for
security).

However I'd have to see an example to really understand the details of what
your doing.  I think I 'get' the method level security via AOP but what
about all the other things Spring Security brings to the table,
multiple/duplicate logins, session timeouts, etc.

In my case we control the full deployed stack so I don't have to leave
anything custom for the user.  My requirements are OpenId and Tomcat.  I'd
prefer to have security manged inside the war I deploy...as although we
control the full stack including the container...I don't personally control
the container so some solution that gets deployed with the war is
preferable if possible/practical (although if there's a Tomcat
OpenId container authentication module that sounds like a good solution
too).




On Fri, Jul 26, 2013 at 12:30 PM, Thomas Broyer  wrote:

>
>
> On Friday, July 26, 2013 7:38:39 PM UTC+2, dhoffer wrote:
>>
>> Thanks Thomas that's good information.  I too have found that best
>> practices for securing GWT applications difficult to come by.  There are
>> just bits and pieces on the web...and if you get the Spring Security book,
>> for example as I did, they don't even mention GWT.  What's needed are some
>> comprehensive examples showing some best practices around security in the
>> context of GWT.
>>
>> As you say...it would be great if you could make
>> your ServiceLayerDecorator **public too that would really help.
>>
>
> Will do. Don't hesitate to bug me about it if I forget.
>
>
>> You recommend AOP and possibly Guice, what do you use to implement the
>> actual security, Spring/Acegi?
>>
>
> Manual checks.
> I have kind of an aversion for everything Spring, and haven't had the need
> for anything more complex than checking user roles at the method level.
> See https://code.google.com/p/google-guice/wiki/AOP; in the
> WeekendBlocker example, replace the date-based check with looking at
> annotations on the invoked method or its enclosing class and checking
> against the current user and/or his roles (which you can get from the
> HttpRequest, that Guice can inject into your interceptor), and throw a
> SecurityException. I like to use javax.annotation.security annotations on
> my methods to declare the required access rights.
>
> What about OpenID support/etc?
>>
>
> This is a different issue.
> I haven't had to deal with that case, but I like to simply defer to the
> servlet container (JavaEE defines JASPI and similar APIs for portable login
> modules, but each servlet container has its own pluggable API) and use
> getRemoteUser, getUserPrincipal and isUserInRole only in the webapp.
> This approach gives you flexibility in the deployment: some customers will
> use LDAP or ActiveDirectory, others will use a SQL DB, or flat files; or
> defer to a front server (Apache or NGinx); some will use a web SSO (JASIG
> CAS, Atlassian Crowd, etc.) or Windows auth (NTLM, Kerberos, SPNEGO), or
> SSL client certificates; some will want 2factor auth on their web forms,
> etc. That's for authentication alone; authorizations (mapping users to
> roles) will come from LDAP/AD, SQL DBs or flat files.
> We rely on JAAS and provide modules to "authenticate from flat file", "get
> roles from flat files" and LDAP/AD (authn with possibly authz) that you can
> mix and match to your needs (covers 95% use cases), and leave it to the
> customer to configure their own JAAS modules for other cases: using
> standard APIs makes it more likely that such a module already exists for
> their auth solution. That's for form-based auth mostly, we rely on Jetty's
> own Authenticator API to replace the auth mechanism, but there are means to
> use JASPI in Jetty if the customer has such a module already.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/IopVSRRqt1s/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/groups/opt_out.
>
>
>

-- 
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/groups/opt_out.

Re: gwt-maven-plugin JVM failures

[David Hoffer]

Found the bug.  The plugin requires that tag to be all on one line in the
XML file...reading like a text file instead of XML.  Our IDE formatted the
XML so it looks good and that caused the problem with the plugin.

-Dave


On Thu, Mar 14, 2013 at 10:34 AM, dhoffer  wrote:

> And if I remove the -XX:MaxPermSize=256m option...then it fails on
> the -Xmx1024m parameter.
>
> -Dave
>
>
> On Thursday, March 14, 2013 10:28:54 AM UTC-6, dhoffer wrote:
>>
>> All of a sudden, we are getting the following build errors with our GWT
>> 2.5.0 builds.  Any idea what would cause this?  This was working fine.
>>
>> Our extraJvmArgs are.
>>
>> -Xms1024m -Xmx1024m -XX:MaxPermSize=256m -Dgwt.jjs.**
>> permutationWorkerFactory=com.**google.gwt.dev.**
>> ThreadedPermutationWorkerFacto**ry
>> 
>> *
>> *
>> *[10:10:54]**[com.issinc.chat-dashboard:dashboard-webapp] [INFO] ---
>> gwt-maven-plugin:2.5.0:compile (gwt-compile) @ dashboard-webapp ---*
>> *[10:10:56]**[com.issinc.chat-dashboard:dashboard-webapp] [ERROR] Error:
>> Could not create the Java Virtual Machine.*
>> *[10:10:56]**[com.issinc.chat-dashboard:dashboard-webapp] [ERROR] Error:
>> A fatal exception has occurred. Program will exit.*
>> *[10:10:56]**[com.issinc.chat-dashboard:dashboard-webapp] [ERROR]
>> Unrecognized VM option 'MaxPermSize=256m*
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/bi3hfEdC-n4/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GWT 2.5 compiler is running out of memory

[David Hoffer]

Yes
using 
-Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ThreadedPermutationWorkerFactory
fixed the problem!  Everything compiles fine now.

With that set I was able to remove ...but just wondering
what 
means when using threads.  Does that control the number of threads, have no
effect?

Thanks!
-Dave


On Fri, Feb 1, 2013 at 9:18 AM, Thomas Broyer  wrote:

> By default, GWT spawns new processes for the "workers", you can switch to
> using threads by
> passing 
> -Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ThreadedPermutationWorkerFactory
> in .
> Either that or try an even smaller value for localWorkers (or use a
> smaller memory opts)
>
>
> On Friday, February 1, 2013 5:10:52 PM UTC+1, dhoffer wrote:
>
>> I've got 8 cores so I set  to 4...that makes a big
>> difference in how much RAM is uses, with that set it never spikes up near
>> 8GB.  However it still fails...with this error message:
>>
>> [INFO]Compiling 12 permutations
>> [INFO]   Compiling permutation 1...
>> [INFO]   Process output
>> [INFO]  Error occurred during initialization of VM
>> [INFO]   Process output
>> [INFO]  Error occurred during initialization of VM
>> [INFO]  Could not reserve enough space for object heap
>> [INFO]  Could not reserve enough space for object heap
>> [INFO]   Process output
>> [INFO]  Error occurred during initialization of VM
>> [INFO]  Could not reserve enough space for object heap
>> [INFO]   Compiling permutation 4...
>>
>>
>> I do have some local changes...it's possible the local changes have some
>> errors in thembut I need the compiler to tell me what they are if
>> that's the case.  Instead it fails to compile, not sure what to do to
>> resolve this.  Note that if I didn't kill the build at this point...it
>> would continue on with the next permutation...and not report this error at
>> the end.
>>
>> -Dave
>>
>>
>>
>> On Fri, Feb 1, 2013 at 6:17 AM, David Hoffer  wrote:
>>
>>> The last error was this:
>>>
>>> [INFO]  #
>>> [INFO]  # There is insufficient memory for the Java Runtime
>>> Environment to continue.
>>> [INFO]  # Native memory allocation (malloc) failed to allocate
>>> 32744 bytes for ChunkPool::allocate
>>> [INFO]  #
>>> [INFO]  # There is insufficient memory for the Java Runtime
>>> Environment to continue.
>>> [INFO]  # Native memory allocation (malloc) failed to allocate
>>> 450768 bytes for Chunk::new
>>>
>>> Not sure if it matters but we did recently upgrade to Java 1.7 build 11
>>> (the previous builds had a major security flaw and we had to upgrade
>>> everything) but that happened a couple days before I started seeing this I
>>> believe.
>>>
>>> I'll try the  suggestion...
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Feb 1, 2013 at 3:03 AM, Thomas Broyer  wrote:
>>>
>>>> Which kind of OutOfMemory are you seeing?
>>>> Also, try to set  to some value lower than the number of
>>>> cores/cpus of your system: if you don't set localWorkers, the
>>>> gwt-maven-plugin will use the number of cores/cpus by default, and
>>>> obviously parallelizing work increases the memory needs.
>>>>
>>>>
>>>> On Thursday, January 31, 2013 11:32:10 PM UTC+1, dhoffer wrote:
>>>>>
>>>>> I've got a rather large GWT build using Maven and the gwt-maven-plugin
>>>>> and I'm getting out of memory errors building now.  I'm not sure what's
>>>>> changed, it used to take considerable memory but now its taking so much I
>>>>> can't build.  I'm running Windows 7 64 bit with 8GB RAM and using Java 7 
>>>>> 64
>>>>> bit to compile, here are some of my settings:
>>>>>
>>>>> MAVEN_OPTS=-Xms128m -Xmx1024m -XX:MaxPermSize=256m
>>>>>
>>>>> Then in the gwt-maven-plugin configuration I
>>>>> have -Xmx2048m -Xmx2048m -XX:MaxPermSize=512m>>>> extraJvm**Args>
>>>>>
>>>>> I've tried several combinations of values here with no luck...with
>>>>> these values...
>>>>> - When I start the maven command line build the system has about 3GB
>>>>> of memory used
>>>>> - When it it starts the GWT part of the build its at abou

Re: GWT 2.5 compiler is running out of memory

[David Hoffer]

I've got 8 cores so I set  to 4...that makes a big difference
in how much RAM is uses, with that set it never spikes up near 8GB.
 However it still fails...with this error message:

[INFO]Compiling 12 permutations
[INFO]   Compiling permutation 1...
[INFO]   Process output
[INFO]  Error occurred during initialization of VM
[INFO]   Process output
[INFO]  Error occurred during initialization of VM
[INFO]  Could not reserve enough space for object heap
[INFO]  Could not reserve enough space for object heap
[INFO]   Process output
[INFO]  Error occurred during initialization of VM
[INFO]  Could not reserve enough space for object heap
[INFO]   Compiling permutation 4...


I do have some local changes...it's possible the local changes have some
errors in thembut I need the compiler to tell me what they are if
that's the case.  Instead it fails to compile, not sure what to do to
resolve this.  Note that if I didn't kill the build at this point...it
would continue on with the next permutation...and not report this error at
the end.

-Dave



On Fri, Feb 1, 2013 at 6:17 AM, David Hoffer  wrote:

> The last error was this:
>
> [INFO]  #
> [INFO]  # There is insufficient memory for the Java Runtime
> Environment to continue.
> [INFO]  # Native memory allocation (malloc) failed to allocate
> 32744 bytes for ChunkPool::allocate
> [INFO]  #
> [INFO]  # There is insufficient memory for the Java Runtime
> Environment to continue.
> [INFO]  # Native memory allocation (malloc) failed to allocate
> 450768 bytes for Chunk::new
>
> Not sure if it matters but we did recently upgrade to Java 1.7 build 11
> (the previous builds had a major security flaw and we had to upgrade
> everything) but that happened a couple days before I started seeing this I
> believe.
>
> I'll try the  suggestion...
>
>
>
>
>
> On Fri, Feb 1, 2013 at 3:03 AM, Thomas Broyer  wrote:
>
>> Which kind of OutOfMemory are you seeing?
>> Also, try to set  to some value lower than the number of
>> cores/cpus of your system: if you don't set localWorkers, the
>> gwt-maven-plugin will use the number of cores/cpus by default, and
>> obviously parallelizing work increases the memory needs.
>>
>>
>> On Thursday, January 31, 2013 11:32:10 PM UTC+1, dhoffer wrote:
>>>
>>> I've got a rather large GWT build using Maven and the gwt-maven-plugin
>>> and I'm getting out of memory errors building now.  I'm not sure what's
>>> changed, it used to take considerable memory but now its taking so much I
>>> can't build.  I'm running Windows 7 64 bit with 8GB RAM and using Java 7 64
>>> bit to compile, here are some of my settings:
>>>
>>> MAVEN_OPTS=-Xms128m -Xmx1024m -XX:MaxPermSize=256m
>>>
>>> Then in the gwt-maven-plugin configuration I
>>> have -Xmx2048m -Xmx2048m -XX:MaxPermSize=512m>> extraJvmArgs>
>>>
>>> I've tried several combinations of values here with no luck...with these
>>> values...
>>> - When I start the maven command line build the system has about 3GB of
>>> memory used
>>> - When it it starts the GWT part of the build its at about 4GB used.
>>> - The I have lots of rebind operations going on generating code...during
>>> this time it goes to about 5GB used.
>>> - Then when it hits the permutations step this is where it breaks
>>> down...it very quickly goes to about 7.5 GB used.  Then I get out of memory
>>> errors and the build fails.
>>>
>>> So there seems to be a couple of issues, first the GWT compiler doesn't
>>> seem to work within the -Xmx2048m value, I used to use -Xmx1024m and it
>>> does about the same thing...it uses a lot more memory than that...and then
>>> fails.  In this case it used 3.5 GB before it failed.  And secondly, I
>>> can't give GWT more memory because my system doesn't have more to give
>>> it...this was with almost all other programs closed...and it still failed.
>>>
>>> Does anyone have an idea why my build might be using so much memory and
>>> how to limit this?
>>>
>>> Btw, at the start of the permutation compile step sometimes it reports 6
>>> permutations and sometimes 12...seems to have the same problem in both
>>> cases but I'm not sure why it sometimes has 12 and other times 6.
>>>
>>> -Dave
>>>
>>>
>>>
>>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Go

Re: GWT 2.5 compiler is running out of memory

[David Hoffer]

The last error was this:

[INFO]  #
[INFO]  # There is insufficient memory for the Java Runtime
Environment to continue.
[INFO]  # Native memory allocation (malloc) failed to allocate
32744 bytes for ChunkPool::allocate
[INFO]  #
[INFO]  # There is insufficient memory for the Java Runtime
Environment to continue.
[INFO]  # Native memory allocation (malloc) failed to allocate
450768 bytes for Chunk::new

Not sure if it matters but we did recently upgrade to Java 1.7 build 11
(the previous builds had a major security flaw and we had to upgrade
everything) but that happened a couple days before I started seeing this I
believe.

I'll try the  suggestion...





On Fri, Feb 1, 2013 at 3:03 AM, Thomas Broyer  wrote:

> Which kind of OutOfMemory are you seeing?
> Also, try to set  to some value lower than the number of
> cores/cpus of your system: if you don't set localWorkers, the
> gwt-maven-plugin will use the number of cores/cpus by default, and
> obviously parallelizing work increases the memory needs.
>
>
> On Thursday, January 31, 2013 11:32:10 PM UTC+1, dhoffer wrote:
>>
>> I've got a rather large GWT build using Maven and the gwt-maven-plugin
>> and I'm getting out of memory errors building now.  I'm not sure what's
>> changed, it used to take considerable memory but now its taking so much I
>> can't build.  I'm running Windows 7 64 bit with 8GB RAM and using Java 7 64
>> bit to compile, here are some of my settings:
>>
>> MAVEN_OPTS=-Xms128m -Xmx1024m -XX:MaxPermSize=256m
>>
>> Then in the gwt-maven-plugin configuration I have -Xmx2048m
>> -Xmx2048m -XX:MaxPermSize=512m
>>
>> I've tried several combinations of values here with no luck...with these
>> values...
>> - When I start the maven command line build the system has about 3GB of
>> memory used
>> - When it it starts the GWT part of the build its at about 4GB used.
>> - The I have lots of rebind operations going on generating code...during
>> this time it goes to about 5GB used.
>> - Then when it hits the permutations step this is where it breaks
>> down...it very quickly goes to about 7.5 GB used.  Then I get out of memory
>> errors and the build fails.
>>
>> So there seems to be a couple of issues, first the GWT compiler doesn't
>> seem to work within the -Xmx2048m value, I used to use -Xmx1024m and it
>> does about the same thing...it uses a lot more memory than that...and then
>> fails.  In this case it used 3.5 GB before it failed.  And secondly, I
>> can't give GWT more memory because my system doesn't have more to give
>> it...this was with almost all other programs closed...and it still failed.
>>
>> Does anyone have an idea why my build might be using so much memory and
>> how to limit this?
>>
>> Btw, at the start of the permutation compile step sometimes it reports 6
>> permutations and sometimes 12...seems to have the same problem in both
>> cases but I'm not sure why it sometimes has 12 and other times 6.
>>
>> -Dave
>>
>>
>>
>>  --
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Errors passing javascript variables to GWT

[David Hoffer]

Yup your right, I had made what seemed like minor changes to the JS
literal code that was causing this problem.  Odd as the errors didn't
seem to indicate a JS source error but my bad...it's working now.
Thanks.

-Dave

On Sat, Dec 15, 2012 at 2:54 AM, Thomas Broyer  wrote:
> Have you tried swapping the order of the s? Also, are you sure you
> don't have a parse error? (can you read the 'info' global var in your
> browser's dev tools? particularly, double-check that
> getCurrentUser().getEmail() doesn't contain a newline; you might want to use
> a JSON API to generate your JS object literal, such as AutoBeans,
> javax.json, Jackson, org.json, etc.)
>
>
> On Saturday, December 15, 2012 5:27:49 AM UTC+1, dhoffer wrote:
>>
>> I'm following the example given here
>> https://developers.google.com/web-toolkit/articles/dynamic_host_page of
>> passing a global info javascript variable back to the GWT app when it loads.
>> E.g.
>>
>> // In GwtHostingServlet's doGet() method...
>> writer.append("");
>> writer.append("