STS not respecting META-INF/spring.schemas for validation? particular, version, example, getting, spring

amy

hi,

i've been struggling with getting schema validation to work correctly within STS.

my workspace is set for resolving schemas from classpath and resolving latest version of schema. the schema in particular that i'm working with is spring integration from.

there are some attributes in the 2.0 version that aren't in the 1.0 version.

i've been using the versionless syntax which seems to work fine at runtime, but the editor seems to be resolving to version 1.0.

here's an example of the syntax i've been using:Code:
lt;beans xmlns=quot;schema/beansquot; xmlns:xsi=quot;2001/XMLSchema-instancequot;  xmlns:from=quot;schema/integration/fromquot; xsi:schemaLocation=quot;   schema/integration/from   schema/integration/from/spring-integration-from.xsd    quot;gt;
and i thought this worked because META-INF/spring.schemas specifies the version to use when encountering a versionless dot-xsd specifier:Code:
from\--the only way i can get the editor to validate against the correct version is to explicitly specify the version like so:Code:
lt;beans xmlns=quot;schema/beansquot; xmlns:xsi=quot;2001/XMLSchema-instancequot;  xmlns:from=quot;schema/integration/fromquot; xsi:schemaLocation=quot;   schema/integration/from   schema/integration/from/spring-integration-from-2.0.xsd    quot;gt;
i like the idea of leaving out the version and allowing it to be resolved externally because it eases upgrade churn.

should STS be honoring META-INF/spring.schemas as resolved from the classpath?

thanks,
tony.

Hi tony,

yes, this should definitely work. What version of STS are you using? Would it be possible for you to create a JIRA and attach a simple project that shows the error you're seeing?

Thanks for raising.

Christian

thanks christian:

browse/STS-1467

i'm sorry, this turned out to be a false alarm.

i added quot;spring project naturequot; and the validation behaved as expected.

this is probably worth a separate thread, but i went through making all projects that had validation related red x's quot;spring naturedquot;, and i came across one project with maybe 30 spring beans xml files that when i made it spring natured, it consistently hung while building the workspace, when loading one of the spring xml files from this project.

i would have to use the windows task manager to shoot the process to get it to restart.

the odd thing is that it wasn't consistent as to which file it hung on, but it was always one from this same quot;poisonquot; project.

when i turned off quot;spring project naturequot;, it doesn't hang when loading.

i tried several times and in order to get it to not hang again, i would have to flip off spring project nature immediately when the workspace was initializing (if i wasn't quick enough, it would hang again).

i did spot that note on the dashboard about the race condition issue with helios, but it doesn't seem like this is the same thing.

any ideas as to how to attempt to troubleshoot this?

my work around is to not use spring project nature, but that's no good in the long haul...

Hi tony_k,

best to trouble shoot hanging builds is to take series of thread dumps. You can do that by using 'jps' and 'jstack' from a command line assuming you have Java 6 installed. Use 'jps -v' to figure out the process id and 'jstack lt;pidgt;' to generate a thread dump.

It would be ideal if you could take about 5-10 of those dumps in a series and attach it to a new JIRA.

I'll take a look then.

Thanks, Christian

hi christian,

thanks for the info on troubleshooting hanging builds.

i actually got past this with some more basic analysis.

it turned out to be related to some subversion mischief.

i actually had a .springBeans file in svn, and it must have been
stale or corrupt in some way because when i deleted it,
i was able to add spring nature without getting the hangs.

however, this particular project still exhibits the quirky validation behavior of defaulting to version 1 of spring integration schemas when i don't specify the version number, but correctly resolves to version 2 when i explicitly specify as described in my intial post on this thread.

but a brand new maven2 (m2) project does the right thing with validating against the default schema.

as usual, things are never simple, so i should also state that this troubled project is an m2 project that i have in svn, but in practice i don't check in .settings, .classpath, or .project files into svn, and i just let eclipse/m2eclipse recreate them when i import the project back into a workspace from svn.

i should also further state that this troubled project is a maven quot;childquot; module project under a maven quot;parentquot; pom project. when i import the parent project into sts using the quot;import svn projectquot; the child modules don't show up as sts projects, so i need to subsequently use the quot;import existing maven projectsquot; option to instantiate the module projects as sts projects.

another odd thing is that if i use the sts/eclipse quot;copy projectquot; function, the copy of this project does the right thing with validation. very strange and elusive to me.

even if i create a brand new spring bean config file in this troubled project, it exhibits the quirky validation behavior.

so i suspect the quirkiness may have something to do with me not checking in one of the project files (.project perhaps), and allowing m2 to recreate it on the fly. in fact, i tried checking the .project file into svn and then pulling the project back into sts, and m2eclipse actually overwrote the .project file from svn to remove the spring project nature.

sts, svn, subclipse, maven, m2eclipse, eclipse, spring, all technology gems in their own right, but when you put them all together sometimes madness ensues ..

one of the reasons i stopped putting those project related files into svn is that m2eclipse would try to overwrite some of them when pulling into a workspace, and sometimes it would depend on preferences set in individual workspaces such as compiler level defaults, so i found that omitting them from svn eliminated a certain amount of heartache.

do you have any best practice suggestions for what portions of a project to put into svn when working with m2eclipse projects specifically?

back to the original topic, i'll try to isolate a small project that exhibits the quirky validation behavior and send it over. my specific project is too unwieldy to send...