Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0 M6
    • Fix Version/s: None
    • Component/s: TCP/UDP Support
    • Labels:
      None
    • Environment:
      STS 2.3.3 nightly

      Description

      I have 65 of the following problems in my spring-integration-ip project. Gary, are you seeing this as well?

      Description Resource Path Location Type
      cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'int-ip:tcp-connection-factory'. ConnectionToConnectionTests-context.xml /spring-integration-ip/src/test/java/org/springframework/integration/ip/tcp line 16 XML Problem

        Activity

        Hide
        Gary Russell added a comment -

        This is benign; it is a known problem with XSD handling in STS, which is fixed, but didn't make it into 2.3.3.M2

        If you can't live with the red squiggly lines, manually add the following entry to the XML Catalog...

        Entry element: URI
        Location: spring-integration-ip/src/main/resources/org/springframework/integration/ip/config/spring-integration-ip-2.0.xsd
        URI: platform:/resource/spring-integration-ip/src/main/resources/org/springframework/integration/ip/config/spring-integration-ip-2.0.xsd
        Key type: Namespace name
        Key: http://www.springframework.org/schema/integration/ip/spring-integration-ip.xsd

        (Just Add from workspace - browse to the schema and update the key as above).

        And Project | Clean... | Clean All Projects

        (You should also set the experimental option - globally - to load namespace handlers and XSD's from the project classpath - this can be found on Window | Preferences | Spring | Beans Support | Namespaces).

        Quote from email w/ Christian 7/16...

        >>>
        this should be solved now. Unfortunately the fix didn't make it into 2.3.3.M2.

        The version that you are using will load the XSD from the XML catalog always with highest priority and if not found in the catalog delegate to the classpath. This is clearly a bug which is now fixed. Please note this only affected the XSD resolution for schema validation; not loading of namespace handlers.
        <<<

        Show
        Gary Russell added a comment - This is benign; it is a known problem with XSD handling in STS, which is fixed, but didn't make it into 2.3.3.M2 If you can't live with the red squiggly lines, manually add the following entry to the XML Catalog... Entry element: URI Location: spring-integration-ip/src/main/resources/org/springframework/integration/ip/config/spring-integration-ip-2.0.xsd URI: platform:/resource/spring-integration-ip/src/main/resources/org/springframework/integration/ip/config/spring-integration-ip-2.0.xsd Key type: Namespace name Key: http://www.springframework.org/schema/integration/ip/spring-integration-ip.xsd (Just Add from workspace - browse to the schema and update the key as above). And Project | Clean... | Clean All Projects (You should also set the experimental option - globally - to load namespace handlers and XSD's from the project classpath - this can be found on Window | Preferences | Spring | Beans Support | Namespaces). Quote from email w/ Christian 7/16... >>> this should be solved now. Unfortunately the fix didn't make it into 2.3.3.M2. The version that you are using will load the XSD from the XML catalog always with highest priority and if not found in the catalog delegate to the classpath. This is clearly a bug which is now fixed. Please note this only affected the XSD resolution for schema validation; not loading of namespace handlers. <<<
        Hide
        Chris Beams added a comment -

        Great, although I'm surprised I don't have the fix, as I'm running on an STS 2.3.3 nightly from about a week ago. Either way, it's good to have this documented. Thanks.

        Show
        Chris Beams added a comment - Great, although I'm surprised I don't have the fix, as I'm running on an STS 2.3.3 nightly from about a week ago. Either way, it's good to have this documented. Thanks.

          People

          • Assignee:
            Gary Russell
            Reporter:
            Chris Beams
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: