gwt:run vs jetty:run-war
Jesse Farinacci
I have my own @Annotations which represent Spring controllers which
handle all the incoming GWT-RPC requests. I haven't changed anything
for my working project other than M3 and now gwt-m-p:1.3-SNAPSHOT but
I'm now seeing that my previously automatically located @Controllers
are no longer being found when running from gwt:run. If I mvn
jetty:run-war then everything works just fine..
Anyone else seeing this? Hopefully figured out what the problem is? I
am at wits end,
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
nicolas de loof
--
You received this message because you are subscribed to the Google Groups "Codehaus Mojo gwt-maven-plugin Users" group.
To post to this group, send email to codehaus-mojo-gwt-...@googlegroups.com.
To unsubscribe from this group, send email to codehaus-mojo-gwt-maven-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.
Jesse Farinacci
On Wed, Oct 20, 2010 at 2:39 PM, nicolas de loof
<nicolas...@gmail.com> wrote:
> To run some full spring/javaEE-stack server side, always prefer -noserver
> with a standard servlet container, like jetty:run or tomcat:run or whatever
> you like. Hosted mode jetty is limited and can only be used with stub
> test-only servlets.
I'm not against that on spec, but this used to actually work. I only
recently started having a problem.. I use my own web.xml which defines
my own servlet configuration, which invokes Spring, and it is copied
over to war/WEB-INF/web.xml prior to Jetty getting control. Again,
this used to work without an issue.
The full Spring bootstrap processing stack used to work for me without
a change in configuration. I agree that perhaps I am doing something
outside the intentions of the plugin maintainers, but a lot of people
run this way.. and it used to work. :-)
nicolas de loof
Jesse Farinacci
On Wed, Oct 20, 2010 at 3:17 PM, nicolas de loof
<nicolas...@gmail.com> wrote:
> Contribution is welcome if you find a fix, anyway a sample project is needed
> to reproduce your issue, let make your project as simple as possible and
> send us a zip
I don't think I am able to do that, but I'll investigate it.. this is
because even the smallest replicating example project is going to be
quite involved, and no doubt involves proprietary code from over here.
I have been trying to locate the change which triggered the problem.
With r12270 (which was the last 1.3-SNAPSHOT version) my project
works, and with r12918 (which is current commit level) it doesn't. No
other changes, and using GWT 2.1-RC1.
I am narrowing it down now... but just to keep everyone appraised, and
to confirm that this did work in the not-so-distant past.
Jesse Farinacci
>
> I am narrowing it down now... but just to keep everyone appraised, and
> to confirm that this did work in the not-so-distant past.
>
Ok, the commit which regressed the plugin is r12479; r12281 works as
expected, but r12479 fails. There's an awful lot going on in that
commit, including relocating the archtype, massive site updates, and
more ITs.
Anyhow, the classpath doesn't seem to be set up properly after r12479 ...