[pjaffe]

Hi,

I’m having trouble running a newly created GWT-based simple Scaffolding app under the Development Mode server so that I can debug the client side. When I do a GWT Compile and run it as a MyEclipse Server App in Tomcat it works fine, but I don’t believe that provides a sufficiently productive development environment.

I’m running MyEclipse for Spring 10 and the Google Plugin for Eclipse (all installed in the last couple days), and I have created a GWT 2.4 simple scaffolding app following http://www.myeclipseide.com/documentation/quickstarts/ME4STutorialScaffoldingGWT/scaffoldinggwtarticle.html as a guide and only selecting the Customer entity to keep it as simple as possible. I then followed the clear steps laid out in http://www.myeclipseide.com/PNphpBB2-viewtopic-t-28267-highlight-gwt.html to address the GWT validation issue.

I’m now left with the following error during startup which appears at first glance to be an issue with getting Spring to run under the Hosted Mode Jetty app server and maybe just due to classpath issues that I’m not immediately seeing a path through. Before I sink more hours into figuring this out, I figured I would start with this forum post just because I’m hoping I’m missing something obvious.

This was just a clean tooling install, a sample app created based on the wizard following a clear set of steps and the GWT 2.4 workaround, and since the GWT 2.4 workaround posting implies that this should just work at this point, I feel like I must be missing something.

Searching on similar issues with Spring and Jetty led me to a few postings that suggested adding things like a META-INF/spring.handlers file, but my quick attempts at that didn’t prove fruitful either.

Here is the top of the first clear failure in my console (this follows a lot of WARN messages related to classpath issues finding Spring jars). I attached the full console output as “FullStartupConsoleOutput.txt”. Additionally, my project is attached as SimpleGWTScaffolding-gwtUnitCacheAndDeployCleared.zip in which I had to delete the gwt-servlet.jar file and a few GWT generated .cache. files in order to fit within the 4.8MB upload limit:

[WARN] Failed startup of context com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload@1912c1a{/,C:\Users\Peter Jaffe\Workspaces\MyEclipse for Spring 10 – JEE6GWT24\SimpleGWTScaffolding\WebRoot}
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions from URL location [classpath:SimpleGWTScaffolding-service-context.xml]
Offending resource: ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/tx]
Offending resource: class path resource [SimpleGWTScaffolding-service-context.xml]

Any help would be deeply appreciated.

Regards,
Pete

Attachments:

You must be logged in to view attached files.

[pjaffe]

I figured I would try a few more things regarding the classpath, and I figured I would post my current findings. I’ve only managed to shift the exception but not get through it…

I probably wasn’t clear earlier, but I was just accepting ALL the defaults of the Scaffolding wizard, including the default option to “Use Eclipse classpath containers instead of copying libraries into the project.” I figured that maybe the Jetty engine wasn’t being provided all these libraries, so I opted to deselect that. That put all the default selected libraries into the libs folder of the project which didn’t seem to change my failure mode. But then when I copied all those jar files into the WEB-INF\lib folder, the startup failure mode changed, which is reinforcing my thought that I just don’t have the right classpath. However, I guess I’m still struggling with understanding what steps to follow to get this working.

After copying in all those jar’s, my startup exception becomes an issue with Spring instantiating the Customer DAO object with the message “Unable to get the default Bean Validation factory.” I’ll include the exception below, and then also include the contents of my WEB-INFO\lib directory (which has the hibernate-validator-4.1.0.Final.jar and validation-api-1.0.0.GA.jar libraries which seem to potentially be related):

SEVERE: Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘CustomerService’: Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.nevo.dao.CustomerDAO com.nevo.service.CustomerServiceImpl.customerDAO; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘CustomerDAO’: Injection of persistence dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘MyEclipse_Derby’ defined in class path resource [Try2-dao-context.xml]: Invocation of init method failed; nested exception is org.hibernate.HibernateException: Unable to get the default Bean Validation factory

WEB-INFO\lib: antlr-2.7.6.jar, aopalliance-1.0.jar, aspectjrt-1.5.4.jar, aspectjweaver-1.5.4.jar, cglib-nodep-2.1_3.jar, commons-beanutils-1.8.3.jar, commons-codec-1.5.jar, commons-collections-3.1.jar, commons-dbcp-1.3.jar, commons-fileupload-1.2.2.jar, commons-io-1.4.jar, commons-lang-2.2.jar, commons-lang-2.5.jar, commons-logging-1.1.1.jar, commons-pool-1.5.4.jar, core-ldap-1.3.0.RELEASE.jar, cxf-2.1.9.jar, derbyclient.jar, dom4j-1.6.1.jar, dwr-2.0.5.jar, FastInfoset-1.2.7.jar, geronimo-activation_1.1_spec-1.0.2.jar, geronimo-stax-api_1.0_spec-1.0.1.jar, geronimo-ws-metadata_2.0_spec-1.1.2.jar, gin-1.5.0.jar, guice-3.0-rc3.jar, guice-assistedinject-3.0-rc3.jar, guice-multibindings-3.0-rc3.jar, guice-persist-3.0-rc3.jar, guice-servlet-3.0-rc3.jar, gwt-servlet.jar, hibernate-annotations-3.5.5.Final.jar, hibernate-commons-annotations-3.2.0.Final.jar, hibernate-core-3.5.5.Final.jar, hibernate-entitymanager-3.5.5.Final.jar, hibernate-jpa-2.0-api-1.0.0.Final.jar, hibernate-validator-4.1.0.Final.jar, javassist.jar, javax.inject-1.jar, jaxb-api-2.1.jar, jaxb-impl-2.1.9.jar, jaxb-xjc-2.1.9.jar, jaxen-1.1.jar, jcl-over-slf4j-1.5.10.jar, jdom-1.0.jar, jettison-1.1.jar, jra-1.0-alpha-4.jar, json-20090211.jar, jstl-1.2.jar, jta-1.1.jar, junit-4.7.jar, log4j-1.2.15.jar, neethi-2.0.4.jar, ognl-2.6.9.jar, postgresql-8.3-603.jdbc3.jar, saaj-api-1.3.jar, saaj-impl-1.3.2.jar, security-config-3.0.5.RELEASE.jar, security-core-3.0.5.RELEASE.jar, security-ldap-3.0.5.RELEASE.jar, security-taglibs-3.0.5.RELEASE.jar, security-web-3.0.5.RELEASE.jar, serializer-2.7.1.jar, sitemesh-2.4.2.jar, skyway-spring-utils-7.1.3.jar, slf4j-api-1.5.10.jar, slf4j-log4j12-1.5.10.jar, spring-aop-3.0.5.RELEASE.jar, spring-asm-3.0.5.RELEASE.jar, spring-beans-3.0.5.RELEASE.jar, spring-binding-2.0.7.RELEASE.jar, spring-context-3.0.5.RELEASE.jar, spring-context-support-3.0.5.RELEASE.jar, spring-core-3.0.5.RELEASE.jar, spring-expression-3.0.5.RELEASE.jar, spring-jdbc-3.0.5.RELEASE.jar, spring-js-2.0.7.RELEASE.jar, spring-orm-3.0.5.RELEASE.jar, spring-test-3.0.5.RELEASE.jar, spring-transaction-3.0.5.RELEASE.jar, spring-web-3.0.5.RELEASE.jar, spring-webflow-2.0.7.RELEASE.jar, spring-webmvc-3.0.5.RELEASE.jar, transactions-essentials-all.jar, urlrewritefilter-3.1.0.jar, validation-api-1.0.0.GA-sources.jar, validation-api-1.0.0.GA.jar, velocity-1.6.2.jar, wsdl4j-1.6.2.jar, wss4j-1.5.8.jar, wstx-asl-3.2.9.jar, xalan-2.7.1.jar, xercesImpl-2.9.0.jar, xml-apis-2.9.0.jar, xml-resolver-1.2.jar, xmlbeans-2.4.0.jar, XmlSchema-1.4.5.jar, xmlsec-1.4.3.jar

[pjaffe]

Just to carry on my one-sided conversation 🙂

I now have a productive debugging environment under development mode (hosted mode) by spinning up the ME4S Tomcat development server for server-side debugging, and then creating a “custom” Web Application debug configuration that disables the Jetty Internal Server of the Google Plugin for Eclipse and just spins up the Development Mode client with the debugger attached. As long as you are careful to make sure the browser URL you address contains the tomcat port and the codesrv query string parameter to serve the GWT client out of the Code Server, then everything seems to work as expected allowing breakpoints on the client & server and hot recompiling/reloading changes to the GWT code without ever having to do a GWT Compile. This approach was reasonably well documented at: http://www.myeclipseide.com/documentation/quickstarts/ME4STutorialScaffoldingGWT/m4sescaffoldinggwtarticle.html#N10214

I am hesitant to consider this thread Resolved since it seems like it would be very nice to just be able to spin up the Jetty built-in servlet container that is part of the default (Google) Web Application debug configuration and not have to explicitly control launching two separate debug configurations. However, I imagine that is partly a result of the Google Plugin for Eclipse not really being tailored to ME4S which provides Tomcat as an app server that seems to be “pre-configured” to support the library dependencies of a Scaffolded application. As indicated above, I did spend time trying to get the classpath for the built-in server working and followed more suggests on the web about moving the hibernate validator up in the classpath before the J2EE boostrapper, and things like that, and again managed to change the particular startup exception emitted by Jetty. But, at this point I have given up on that and I’m just running with starting the Tomcat server separately from the Development Mode (with the Internal Server disabled).

I’ll just close with the following comments in case this is helpful to anyone else (or in case anyone can provide pointers to other resources about these).

1. The header and footer content of the Scaffolded app appear to be getting repeated (with slightly different formatting and positions) when running under development mode (the code server). At this point, I’m just considering this a visual annoyance of that mode, and I haven’t had a chance to try to track that down.

2. The “Back to Dashboard” button generated by Scaffolding appears to set the Window.Location to an explicit URL in ScaffoldDesktopShell.backButtonPressed(…) and hence doesn’t propagate the ?gwt.codesvr query string parameter causing you to drop out of the client debugging experience which threw me for a loop for a minute. This is something I have tweaked in the generated source to save myself the intermittent confusion by doing something like: Window.Location.assign(GWT.getModuleBaseURL() + “..?gwt.codesvr=” + Window.Location.getParameter(“gwt.codesvr”));

3. Here is what I believe is the actual root exception when running under the Google Plugin for Eclipse’s built-in server (Jetty) after attempting to follow some suggestions on the web about tweaking the classpath beyond what the scaffolding app generates (prior to giving up on trying to push through this):

Caused by: java.lang.NullPointerException
at org.hibernate.validator.xml.ValidationXmlParser.getInputStreamForPath(ValidationXmlParser.java:252)
at org.hibernate.validator.xml.ValidationXmlParser.getValidationConfig(ValidationXmlParser.java:198)
at org.hibernate.validator.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:60)
at org.hibernate.validator.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:252)
at org.hibernate.validator.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:143)
at javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:111)
at org.hibernate.cfg.beanvalidation.TypeSafeActivator.getValidatorFactory(TypeSafeActivator.java:319)
… 77 more
Starting Jetty on port 8888

[cconway]

Hi Pete,

I have been unsuccessfully trying to workaround the problem with the development mode server. I’ve found a few posts on the Google site, but the workarounds aren’t working for me. It sounds like you may have already come across this, but here is the one I’m following:

http://code.google.com/p/google-web-toolkit/issues/detail?id=5728

I’m sorry that your post seems to be a one-sided conversation. I thought I would have a valid workaround by now. The good (or maybe not so good) news is that I am able to reproduce the problems.

Just so you’re aware, typically we run with the Tomcat server, but like you say, that is not the optimal mechanism for GWT debugging.

I am continuing to work this issue, so please post back if you discover the magic necessary to run the GWT plugin’s development mode with Spring.

[pjaffe]

Hi Cindy,

Thanks for your attention to this. Please don’t take any offense to my “one-sided conversation” comment… It was an attempt at humor that apparently flopped, and worse, probably came across as an unintentional jab.

The GWT issue 5728 that you referenced in your previous comment does appear closely related, and I looked at one of the workarounds referenced in there (http://code.google.com/p/google-web-toolkit/issues/detail?id=5693) where someone even went as far as to tweak the WebAppClassLoaderExtension() implementation of the JettyContainer.java source and hook that in. I think I’ll leave that kind of fun stuff to you, but it is definitely discouraging that those discussions were from 1 year ago, and apparently still remains an issue.

As I mentioned in my previous post, I am specifically spinning up a debugging session on the Tomcat server, and then adding on a second debugged process using the Google Plugin’s Development Mode code server with its built-in (Jetty) server disabled. This process isn’t too onerous, and in some ways more closely reflects out intended deployment which will be under Tomcat.

At least http://www.myeclipseide.com/documentation/quickstarts/ME4STutorialScaffoldingGWT/m4sescaffoldinggwtarticle.html#N10214 (which I referenced above) provides some clear guidance on how to do this. So, you may at least want to revise your more current quick start guide that is at http://www.myeclipseide.com/documentation/quickstarts/ME4STutorialScaffoldingGWT/scaffoldinggwtarticle.html#N1031B to describe the suggested debugging configuration (you should almost be able to just lift the content from the older quick start guide).

So, I imagine you will internally prioritize how much more time to spend on this and when…

Pete

[cconway]

Thanks for the response Pete. I took no offense to your “one sided conversation” comment, I apologize if it seemed that I did.

I did talk to our main GWT developer and this has been an ongoing issue which is why he came up with the alternate approach outlined in the 8.6 documentation. I also noticed yesterday that the section had been removed from the current documentation and I agree that it needs to be re-added. I will log an issue for the documentation team to address that in their next revision.

Thanks to you, this is all documented here for the time being. Thank you for your patience.

[jckingst]

Will you post a link to the “alternate approach” you refer to?

[pjaffe]

cconway was likely referring to the link I referenced above: http://www.myeclipseide.com/documentation/quickstarts/ME4STutorialScaffoldingGWT/m4sescaffoldinggwtarticle.html#N10214

It doesn’t look like they have updated their newer documentation yet to include that same section.

[jckingst]

Thanks for the link Pete. I tried running my project in development mode like that thread suggests but I ran into two problems.

1. Having to change the port to 8080 every time I run the project is a pain. Is there any way to make the port argument persist? Also, it would be nice be able to run in development mode by clicking on a toolbar icon. Is it possible to set a button to trigger a run configuration?

2. In development mode my project has additional elements that it shouldn’t contain. Like the MyEclipse for Spring logo, and the “Back To Dashboard” Button. When I compile and run the project, I don’t see these unwanted elements. Why do they only appear in development mode? Have you had these same problems?

~Joseph

[pjaffe]

Hi Joseph,

I saw both of those problems as well. I didn’t spend any time looking into them because they weren’t high enough up on my list of productivity obstacles 🙂

Regarding #1, the link I referenced above from the MyEclipse documentation at least hints at this problem, and I believe I managed to get it to stick for the duration of my MyEclipse session and hence I left Tomcat running on 8080 in some workspaces and did the port switch in the Google Plugin launch configuration. However, I believe I found I had to reapply that port switch each time I restarted MyEclipse (but at least survived across multiple debugging sessions, and several days since I mostly just hibernate my Windows machine). Most of my colleagues chose to change Tomcat to run on 8888 which I believe persists across MyEclipse sessions (I don’t have the IDE in front of me at the moment, but I believe it was a pretty clear setting accessible off a right click context menu on the Tomcat line on the Servers view).

Regarding #2, I figured this one might have an interesting technical explanation, but I never found the time to dig into it.

I imagine the MyEclipse support forums would want these two issues tracked under different forum postings since neither are necessarily “unable to run… under Development mode” but instead “quirks of Scaffolding apps under Development Mode”. Without further research, I had been assuming #1 was likely a problem with the Google Plugin and hence might not be addressable by MyEclipse people, while #2 might be rooted in the world of MyEclipse’s Scaffolding code base and hence maybe could be addressed by MyEclipse people.

Anyway, this was a long reply to say “I feel your pain but it wasn’t painful enough for me to focus on it yet.”

Pete

[Author]

Posts