Jetty 9

[jay]

We have some requirements which have forced us to run our own Jetty server. This means we're debugging with the --noserver flag. The problem with this is the amount of time it takes to do a command line build (and deploy) and then run the debugger. And, of course, if your command line compile doesn't include the right permutation, you get to do it all over again.

My question is if someone can point us at how we can use our Jetty process, but hook up the GWT dev mode "magic" so we can just fire up the debugger and go.

Thanks,

jay

[gslender]

I'm unsure why you need to do a gwtc compile? Why is that?

G

[Thomas Broyer]

You only need to "gwt compile" once, then just run DevMode.

Ideally, you'd point DevMode's -war at the location Jetty loads your webapp (so, deploy an exploded WAR, or point -war to the location Jetty exploded the WAR in the temp folder) so that all the static files it generates (ExternalTextResource; other resources when not inlined for whichever reason, ImageBundle if you still use them; and GWT-RPC serialization policies) can be found by Jetty / your webapp.

In many situations, when working on client-only code (UI code, mostly), I just run DevMode in -noserver mode with -startupUrl pointing at our test server (where our CI server deploys the app).

Otherwise, we use a local Jetty server and configure it to load the webapp right from our Maven's target/ folders; that way redeploying is just a matter of re-compiling the Java classes (done automatically by Eclipse anyway, but otherwise "mvn package -Dgwt.compiler.skip" does the job without recompiling the GWT client-side code), and with DevMode you never need to redeploy the client-side code.

[jay]

What you're describing is pretty much what we're doing.

The issue comes up when we change a piece of shared code, like a DTO. What we've found is that if we don't stop, recompile from the command line (including gwt compile) the updated DTO can't be sent/received...the GWT-RPC stuff doesn't match up any more and we get failures.

Maybe what you're suggesting is that we're doing something wrong? I'd *love* to just do one gwt compile *ever* and have the right "bootstrap" files in place. How do we handle the GWT-RPC serialization policies?

thanks,

jay

[Jens]

The issue comes up when we change a piece of shared code, like a DTO. What we've found is that if we don't stop, recompile from the command line (including gwt compile) the updated DTO can't be sent/received...the GWT-RPC stuff doesn't match up any more and we get failures.

You just have to reload the browser first so that the DevMode regenerates *.rpc files for your changed shared DTO classes. After that you redeploy the updated *.rpc files along with the rest of the server code to jetty.

I also use external servers (Glassfish / Jetty 9) and never do a GWT compile while developing / debugging. If the external server is not on my local host I use an ant build script to gather all the classes that the IDE already has compiled (basically copying the bin or WEB-INF/classes folder) along with any important GWT files (*.rpc, hosted.html, app.nocache.js). From these files I build a war and then deploy it remotely.

If the external server is installed on my local host, for example Jetty, I let it deploy the project's war folder directly as it is already an explored war. Should work well with Eclipse as the hosted.html / app.nocache.js / *.rpc files are all generated into that war folder because of the Eclipse plugin (unless you have configured it different).

If you use IntelliJ you can let IntelliJ do all the work by defining a server artifact and configure a Jetty server in IntelliJ to deploy that server artifact. Then you have to modify your GWT DevMode run configuration and add -war <path/to/intellij/server/artifact> so that hosted.html / app.nocache.js / *.rpc files are placed inside IntelliJ's artifact folder. Then you only have to hit "update" in IntelliJ to redeploy things in Jetty. I would guess Eclipse WTP lets you do something very similar.

In all those cases I often use an additional local web server with HTTP proxy capabilities. That way I can redirect server requests to any external server so for example I could swap between a local Jetty instance of a remote one or between Jetty and a Glassfish installation on different ports, etc. while accessing my app always on http://localhost?gwt.codesrv=...

-- J.

[Brian Slesinsky]

For GWT 2.6, Super Dev Mode, and the RemoteServiceServlet, you could set the gwt.codeserver.port Java property.

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

[Julien Dramaix]

Firstly, you have to use  https://groups.google.com/d/forum/google-web-toolkit  to ask support. Secondly, at first sight, your problem doesn't seem to be related to GWT.

Julien

On Thu, May 22, 2014 at 8:40 AM, shreshth wadhwa <shre...@gmail.com> wrote:

Hi All,

We have a web application running on Jetty 8. Now we upgraded the Jetty to Jetty 9.0.7. We are facing an issue now that we are unable to send emails through our application.

If we move our application back to Jetty 8 the problem is solved.

The JDK version we are using is jdk1.7.0_51

We are getting the following error in the logs.

com.accenture.ams.adaptiveAnalytics.core.execution.ProcessorException: com.accenture.ams.adaptiveAnalytics.core.execution.ProcessorException: an error occured processing the command GenericExtractCommand

at com.accenture.ams.adaptiveAnalytics.core.execution.BrokerBase.dispatch(BrokerBase.java:257)

at com.accenture.ams.adaptiveAnalytics.core.execution.ConcurrentExecutionController$2.run(ConcurrentExecutionController.java:162)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

at com.accenture.ams.adaptiveAnalytics.core.concurrency.ExecutorConcurrencyManager$1.call(ExecutorConcurrencyManager.java:263)

at java.util.concurrent.FutureTask.run(FutureTask.java:262)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:744)

Caused by: com.accenture.ams.adaptiveAnalytics.core.execution.ProcessorException: an error occured processing the command GenericExtractCommand

at com.accenture.ams.adaptiveAnalytics.core.execution.SimpleBroker.dispatchInternal(SimpleBroker.java:65)

at com.accenture.ams.adaptiveAnalytics.core.execution.BrokerBase.dispatch(BrokerBase.java:233)

... 7 more

Caused by: java.lang.NoSuchMethodError: javax.mail.Session.getInstance(Ljava/util/Properties;)Ljavax/mail/Session;

at org.springframework.mail.javamail.JavaMailSenderImpl.getSession(JavaMailSenderImpl.java:155)

at org.springframework.mail.javamail.JavaMailSenderImpl.createMimeMessage(JavaMailSenderImpl.java:325)

at com.accenture.ams.adaptiveAnalytics.mailManager.ExtractMail.sendMail(ExtractMail.java:74)

at com.accenture.ams.adaptiveAnalytics.mailManager.ExtractMail.sendMail(ExtractMail.java:48)

at com.accenture.ams.adaptiveAnalytics.effectiveness.evaluation.extracts.CommonExtractProcessor.process(CommonExtractProcessor.java:51)

at com.accenture.ams.adaptiveAnalytics.effectiveness.evaluation.extracts.CommonExtractProcessor.process(CommonExtractProcessor.java:1)

at com.accenture.ams.adaptiveAnalytics.core.execution.SimpleBroker.dispatchInternal(SimpleBroker.java:58)

Please help me in this regard.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/c23387db-9713-4747-815f-fc8f8020811d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.