Announcement Announcement Module
Collapse
No announcement yet.
STS 3.3.0 - Preferences -> Spring -> Beans Support -> Namespaces - No Integration Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • STS 3.3.0 - Preferences -> Spring -> Beans Support -> Namespaces - No Integration

    Missing XSD namespaces for Spring Integration.

    Can these be added?

  • #2
    Exceptions in STS

    Code:
    Description	Resource	Path	Location	Type
    cvc-complex-type.3.2.2: Attribute 'logger-name' is not allowed to appear in element 'int:logging-channel-adapter'.	integration-orderSubmission.xml	/cart/target/cart-1.4.0.BUILD-SNAPSHOT/WEB-INF/classes/com/knoll/services/cart/order	line 55	XML Problem
    cvc-complex-type.3.2.2: Attribute 'logger-name' is not allowed to appear in element 'int:logging-channel-adapter'.	integration-orderSubmission.xml	/cart/src/main/java/com/knoll/services/cart/order	line 55	XML Problem
    cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'int:object-to-json-transformer'.	integration-orderSubmission.xml	/cart/target/cart-1.4.0.BUILD-SNAPSHOT/WEB-INF/classes/com/knoll/services/cart/order	line 41	XML Problem
    cvc-complex-type.3.2.2: Attribute 'logger-name' is not allowed to appear in element 'int:logging-channel-adapter'.	integration-orderSubmission.xml	/cart/target/cart-1.4.0.BUILD-SNAPSHOT/WEB-INF/classes/com/knoll/services/cart/order	line 19	XML Problem
    cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'int:object-to-json-transformer'.	integration-orderSubmission.xml	/cart/src/main/java/com/knoll/services/cart/order	line 41	XML Problem
    cvc-complex-type.3.2.2: Attribute 'logger-name' is not allowed to appear in element 'int:logging-channel-adapter'.	integration-orderSubmission.xml	/cart/src/main/java/com/knoll/services/cart/order	line 19	XML Problem

    Comment


    • #3
      Hey!

      Do you have Spring Integration on the classpath of your project? Usually STS should list those namespaces automatically (without the need for us to add them to the IDE manually for all Spring libs out there). Can you try that? And if that doesn't work, can you attach a sample project that reproduces this?

      With regards to the exceptions/errors: Can you attach a sample project that reproduces the problem? I would like to take a more detailed look into this. That would be great!!!

      Thanks for your help!
      -Martin

      Comment


      • #4
        Martin,

        Thank you for your assistance. I can't publicly share this project with you. That will have to be handled offline.

        From what I can tell, if I switch the XSD for integration to the numbered version (i.e. -2.2.xsd) the messages go away. however my unit tests fail and they are telling me to switch to the non-version xsd schemas in my integration config files. So i switch back to the non-versions xsd schemas and they tests run, the errors in the Problems tab come back. This is really strange. If you want to see my project, please pm me where I can share it with you.

        Thanks,
        Dan

        Comment


        • #5
          Hey Dan!

          I send you a private message with contact details. Would be great if I could take a look at the project in order to find out what is going wrong here.

          Thanks a lot for your help!
          -Martin

          Comment


          • #6
            We observed similar issue with spring integration modules as well as with spring rabbit modules.
            The problem can not be reproduced on all the machines, only on some of them, even though they have very similar hardware / software configurations (macbook pro running latest mac osx with all the updates, jdk 1.6.0_51).
            When it can be reproduced then STS 3.2.0 (Juno), STS 3.3.0 (Kepler) or STS plugins on top of Java or Java EE Eclipse have the same problems (new install, new workspace, single minimalistic maven project with a dependency to latest released version of corresponding spring module, dependency is correctly resolved, visible in Maven Dependencies and includes spring.* files as well as correct versions of xsds).
            Sometimes the url of xsd with highest version can be resolved based on project classpath (it's clear based on the validation message or by looking at Properties -> Spring -> Bean Support -> Namespaces, but instead of taking xsd from the module's jar Eclipse is trying to get it from internet, which in some cases it can not do (as with spring-rabbit-1.2.xsd).
            The problem with validation appears even in cases when referencing versioned xsd url as long as xsd is missing or invalid at that url, as it should be in case when it downloads the schema instead of using one included in project classpath.
            Adding mapping into Preferences -> XML -> XML Catalog for version-less xsd url and versioned xsd url to a local copy of missing or incorrectly published xsd resolves the spring config xml validation issues, as does the disabling XML Validation on build, leaving it only manual.
            Playing with options in Preferences -> Spring -> Bean Support -> Namespaces does not have much of an effect (Project -> Clean, Close / Open Project, exit / restart eclipse).
            And again, on most of others practically identical developer workstations we don't see the same problem, there it all works as intended in regards to spring config xml validation for the same projects.
            Changing perm gen or max memory settings for Eclipse does not have effect either (as it did in some cases with older versions of STS when there were many open projects / a lot of installed plugins).

            Comment


            • #7
              Hey!

              From the example projects that Dan sent me (many many thanks for that again), I can see the errors that Dan described above. The problem is the XSD resolution mechanism that is trying to resolve XSDs from the internet instead of the project classpath (as described in the previous post).

              The classpath-based lookup of XSDs is something that we implemented in STS specifically for Spring projects. That means you need to have the Spring nature enabled for your project in order to get the classpath-based XSD resolution to be used instead of the default one. The example project from Dan didn't have the Spring nature enabled for the project in which I can see the errors described above. As soon as I enable the Spring nature for that project as well and do a full clean build of that project, the errors go away. Sometimes open editors are a bit lazy in removing error markers, so make sure to take a look at the Markers view and maybe re-open the editor in case it still shows those errors.

              Hope this helps!
              -Martin

              Comment


              • #8
                Martin

                Please .. have been using STS as go-to tool for several years ... truly appreciate it ... currently focused on tighter understanding of namespace support ... could you please elaborate a bit on access STS feature you were addressing when above you wrote, "Usually STS should list those namespaces automatically (without the need for us to add them to the IDE manually for all Spring libs out there)"

                Thanks

                Russ

                Comment


                • #9
                  Hey!

                  Sure, let me try to explain the namespace support in the Spring Tool Suite and the Spring IDE in more detail:

                  The most important part of this is: your project has to have the Spring nature enabled and therefore being marked with a little "S" in the project or package explorer. This enables the Spring-specific tooling for the project.

                  The Spring tooling helps you with working with Spring XML config files. It provides content-assists, quick-fixes, and validations for your Spring XML files. For doing all this, it enhances the XML tooling of Eclipse with Spring-specific add-ons. To do this, the tooling provides a project-specific lookup mechanism for the used XSD files that you are referring to in your Spring XML config files. This allows the tooling to lookup exactly the XSD file that you have on the classpath of your project.

                  The individual support for the various namespaces out there varies from namespace to namespace. For basic XML validation rules can be applied for all used XSDs, others are supported in more detail (like the core Spring namespaces).

                  If something in this area is not working for you as you would expect it, please let us know and provide a small sample project that reproduces the problem you experience. That helps a lot to understand and solve those issues.

                  Hope this explains the underlying support in more detail. Let me know if you have further questions and I am happy to provide more details.

                  Cheers,
                  -Martin

                  Comment

                  Working...
                  X