OK, finally got it to work, but had to add the following to my web.xml (so
it was jetty all along), the webdefault didn't work
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.eclipse.jetty.servlet.DefaultServlet</servlet-class>
<init-param>
<param-name>useFileMappedBuffer</param-name>
<param-value>false</param-value>
</init-param>
<load-on-startup>0</load-on-startup>
</servlet>
On Tuesday, 9 May 2017 15:42:00 UTC+2, Thomas Lefort wrote:
>
> Aw thanks Thomas, I feel guilty to take so much of your time.
>
> I did just figure out the -war option but ran into another issue... I am
> running the jetty server from Intellij and the CodeServer with the no
> server and war options as suggested. However when it comes to updating the
> code (which it does ;-)) it gets stuck because the jetty server seems to be
> locking the directory. I am basically getting a [ERROR] Can't update
> launcher dir message. I guess this is something to do with Intellij and I
> need to look into it a bit more. I just mention it in case someone has had
> the issue before and is sympathizing with my problems ;-)
>
>
> On Tuesday, 9 May 2017 15:34:13 UTC+2, Thomas Broyer wrote:
>>
>>
>>
>> On Tuesday, May 9, 2017 at 3:18:38 PM UTC+2, Thomas Lefort wrote:
>>>
>>> Hi Thomas,
>>>
>>> Thanks for the reply. Sure I don't expect anyone to fix it for me, just
>>> to know if it is a problem my end or if I am trying to do too much with the
>>> embedded server indeed.
>>>
>>> I am happy with running an external server, however, it would be nice if
>>> I could get a similar level of debug functionality, ie breakpoint in server
>>> code, all the superdev mode feature, etc... Any good step by step manual? I
>>> tried the noserver flag (in Intellij) and running a server aside (as per
>>> GWT project page instructions) but it doesn't provide the goodies I
>>> mentioned previously, for instance, it doesn't update the client when I
>>> change it and reload it. To be honest, I can't really see how the magic
>>> would happen without some connection between the two. I am probably missing
>>> a key element/step :)
>>>
>>
>> Assuming a server setup that correctly reloads (redeploys the webapp)
>> whenever server-side code (and/or resources) changes (this is outside the
>> scope of GWT; same for debugging).
>> You run CodeServer with launcherDir pointing to a folder served by the
>> server (or DevMode with -noserver, and -war pointing to that same folder),
>> it then generates a *.nocache.js file in the directory (and copies public
>> resources there too).
>> When you load your page in the browser, the *.nocache.js is loaded and
>> triggers a compilation in the CodeServer.
>> Whenever you change client-side code, refresh the page in the browser and
>> it'll trigger a recompilation.
>> Whenever you change server-side code, redeploy the webapp (depending on
>> the setup, this can be entirely automatic, or involve some manual action).
>> To debug client-side code, use the browser's devtools, or your usual
>> SDM/IDE integration (I never used any, so can't really comment)
>>
>> When using my gwt-maven-archetypes for example, "mvn tomcat7:run" will
>> automatically redeploy the webapp whenever resources or classes change in
>> target/classes. Most IDEs will happily compile your code (automatically on
>> save, or triggered by a keyboard shortcut) into target/classes, which would
>> trigger a redeploy. "mvnDebug tomcat7:run" (or running the Maven goal for
>> debug in your IDE; for example, in Eclipse, Debug As… → Maven… →
>> tomcat7:run) allows you to debug your server-side code. And "mvn
>> gwt:codeserver" launches SDM for the client-side code.
>>
>> AFAIK, the GWT Eclipse Plugin has some "one click" way of running both a
>> server runtime (configured in Eclipse WTP) and SDM, and I'd assume that
>> Eclipse is smart enough to make redeploying after changes either completely
>> automatic or only a keyboard shortcut / click away.
>>
>> The "connections" you're talking about are the standard JDWP protocol for
>> connecting to a JVM to debug the server-side code in the server runtime,
>> and SDM with SourceMaps (and possibly a "remote debugging" protocol of your
>> browser if you want IDE integration rather than debugging right in your
>> browser).
>>
>
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
