[STS 2.8.0.RELEASE] Error occured processing XML 'null'.

[blizzard]

Hi,

We have a project that has always worked under STS 2.7.x. However, today Eclipse prompted me to update my STS. I agreed. And now I'm FULL of problems. All of my Maven projects complain of things like:

Plugin execution not covered by lifecycle configuration: com.springsource.bundlor:com.springsource.bundlor.maven:1.0.0.RELEASE:bundlor (execution: bundlor, phase: compile)

I have to manually modify ALL POMs to add stuff as described here: http://wiki.eclipse.org/M2E_plugin_e..._plugin_go al.

My bigger problem, however, is that one project reports the following error:

Error occured processing XML 'null'. See Error Log for more details	bundle-context.xml

I checked in the log. The error is:

!MESSAGE Error occured processing '/XXXXXXXXX/src/main/webapp/WEB-INF/spring/bundle-context.xml'
!STACK 0
java.lang.IllegalArgumentException
	at java.net.URI.create(URI.java:842)
	at org.springframework.ide.eclipse.beans.core.internal.model.namespaces.XmlCatalogDelegatingEntityResolver.resolveEntity(XmlCatalogDelegatingEntityResolver.java:89)
	at org.apache.xerces.util.EntityResolverWrapper.resolveEntity(Unknown Source)
	at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
	at org.springframework.ide.eclipse.core.io.xml.XercesDocumentLoader.loadDocument(XercesDocumentLoader.java:48)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:388)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
	at org.springframework.ide.eclipse.beans.core.internal.model.BeansConfig$2.loadBeanDefinitions(BeansConfig.java:386)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)
	at org.springframework.ide.eclipse.beans.core.internal.model.BeansConfig$3.call(BeansConfig.java:443)
	at org.springframework.ide.eclipse.beans.core.internal.model.BeansConfig$3.call(BeansConfig.java:1)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.URISyntaxException: Illegal character in path at index 10: file:///D:\XXX\XXX\.metadata\.plugins\org.eclipse.wst.internet.cache/-551705775.cache
	at java.net.URI$Parser.fail(URI.java:2809)
	at java.net.URI$Parser.checkChars(URI.java:2982)
	at java.net.URI$Parser.parseHierarchical(URI.java:3066)
	at java.net.URI$Parser.parse(URI.java:3014)
	at java.net.URI.<init>(URI.java:578)
	at java.net.URI.create(URI.java:840)
	... 30 more

The path is constructed with backslashes instead of forward slashes. So, we get an URISyntaxException. What now? If I disable the caching, it works. If I enable the caching again, it starts to fail with the error above. How can I tell STS to use forward slashes? Is it even an STS problem? Or an Eclipse problem? Any ideas?

[Martin Lippert]

Hey!

The exception looks like a bug somewhere. I will investigate this. Created an issue in JIRA to track this:
https://issuetracker.springsource.com/browse/STS-2180

-Martin

[Martin Lippert]

So you have "load namespace handlers and XSD from classpath" enabled and it works again when you activate "disable caching for namespace resolving and loading"? Or do you mean a different caching?

[blizzard]

Sorry, I should have expressed myself more clearly.

Since the problem comes when Eclipse is trying to use a cached XSD, I disabled the Eclipse caching. I did it through Window -> Preferences -> General -> Network Connections -> Cache -> Disable caching. When Eclipse doesn't use the cache, there's no problem. The project is in error-free state. However, if I enable the caching (which, of course, is the default), then Eclipse tries to load the XSD http://www.springframework.org/schema/beans from the cache, but uses backslashes in the URL, so it gets a URISyntaxException. Spring, in turn, reports the rather confusing "Error occured processing XML 'null'. See Error Log for more details" when it tries to parse bundle-context.xml. And the project has a red (error) state in the Package Explorer.

It should be noted that it doesn't crash all the time. Other projects have bundle-context.xml too, but they don't get this error. The project that fails is super-small. It's just for plumbing purposes. Here's an overview:

project_screenshot.png

And here's the error:

markers_screenshot.jpg

There are tons of Maven errors that appeared as a result of upgrading to STS 2.8.0 -- "Plugin execution not covered by lifecycle configuration...". This is a major inconvenience for me because I have to add some junk to all pom.xml files to fix the problems but I cannot commit that junk into our version control system because many people don't use STS 2.8.0 and won't use it any time soon.

In fact, I will have to revert back to STS 2.7.x by re-installing and reconfiguring it anew because the automatic reversal of the update didn't work (as usual).

------

EDIT:

Enabling or disabling "Load NamespaceHandlers and XSDs from project's classpath" doesn't solve the problem.
Enabling or disabling "Disable caching for namespace resolving and loading" doesn't solve the problem.
Disabling "Network Connections -> Cache" solves the problem, as I described above but, quite understandably, this is not really a solution to the problem as it introduces other problems.

[Martin Lippert]

Ah, okay, thanks for the clarification, I was already wondering why the classpath-based namespace caching would affected this... ;-)
In the meantime I identified the underlying problem in WTP, it is just producing the wrong path on Windows, as far as I understand the code behind this feature. I filed a bug against WTP at Eclipse, lets see how quickly they can come up with a fix.

Thanks again for reporting and especially for the workaround!
-Martin

[blizzard]

I need to revert back to STS 2.7.2 but I have the following problem:

1. I download and run STS 2.7.2
2. I go to Help -> Install New Software... and I enter: http://download.eclipse.org/virgo/snapshot/IDE (this is the Virgo Tooling update site)
3. After the Virgo tooling is installed, it tells me it wants to restart Eclipse and I agree.

And, lo and behold, STS 2.7.2 is now upgraded to STS 2.8.0 even though I haven't activated such an upgrade!!!!! The version I have immediately after installing the Virgo tooling is: Version: 2.8.0.RELEASE, Build Id: 201110171000

This is terrible! How can I switch back to STS 2.7.2 and have the Virgo server runtime? I have been fighting with STS 2.8.0 for the past two days and this cannot go on any more. I have deadlines. Please, help! I must somehow manage to stay with STS 2.7.x.

[Martin Lippert]

I am not sure why this happened while installing the Virgo tooling, but you can try to uncheck (or delete) the general STS update site from the list of available update sites. This should avoid any update messages or so for STS.

[Martin Lippert]

I checked this again and there is an "automatic download updates" setting in the preferences that tries to download the updates automatically. You should deselect that and also remove the general STS update site from the list of available update sites. Then the Virgo tooling installs without STS 2.8.0 (so the problem wasn't really related to Virgo tooling). Just tried it myself a minute ago. Seems to be fine.

BTW: The Virgo tooling isn't compatible with STS 2.8.0 anyway, so please don't upgrade to STS 2.8.0 if you wanna use the Virgo tooling.

HTH,
Martin

[blizzard]

This worked. Thank you! You've been extremely helpful all along.

[Martin Lippert]

Thanks! Glad to hear I could help!