cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CXF-5532) jax-ws-catalog.xml / @SchemaValidation / xsd-includes
Date Tue, 04 Feb 2014 18:22:11 GMT

     [ https://issues.apache.org/jira/browse/CXF-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Daniel Kulp updated CXF-5532:
-----------------------------

    Description: 
When using catalog resolving (jax-ws-catalog.xml) in combination with @SchemaValidation and
a set of xsd files (that include each other) the wrong file is coupled with the wrong stream
in org.apache.cxf.wsdl.EndpointReferenceUtils. It concerns method SchemaLSResourceResolver#resolveResource.

Observation:
1) The resolver is constructed with a correct set of entries (Schemas).
2) The resolver then tries to match on (ending of) systemId:targetNameSpace (that fails)
3) The resolver then tries to match on (ending of) targetNamespace only. All entries on the
same namespace match, so the first one (arbitrary) is resolved. 

I've prepared a patch on this class that fixes the issue. Test projects are available.
{code:java}
@Line210 I've included the following code:
            // Sjaak PATCH
            // there can be multiple includes on the same namespace. This scenario is not
envisioned yet.
            // hence the filename part is included as well. 
            if (systemId != null) {
                String systemIdFileName = systemId.substring(systemId.lastIndexOf('/') + 1);
                for (Map.Entry<String, byte[]> ent : schemas.entrySet()) {
                    System.out.println("matching: " + ent.getKey() + " endswith: " + systemIdFileName
+ ":" + namespaceURI);
                    if (ent.getKey().endsWith(systemIdFileName + ":" + namespaceURI)) {
                        schemas.remove(ent.getKey());
                        impl = new LSInputImpl();
                        impl.setSystemId(newId);
                        impl.setBaseURI(newId);
                        impl.setCharacterStream(
                                new InputStreamReader(
                                        new ByteArrayInputStream(ent.getValue())));
                        done.add(newId + ":" + namespaceURI);
                        System.out.println("match!, adding to done: " + ent.getKey() + "returning:
" + impl.getSystemId());
                        return impl;
                    }
                }
            }
            // sjaak END PATCH.
{code}

The patch introduces a step 2a to the steps above:

2a) The resolver then tries to match on (ending of) systemIdFileName:targetNameSpace (that
fails)

Best regards,
Sjaak 




  was:
When using catalog resolving (jax-ws-catalog.xml) in combination with @SchemaValidation and
a set of xsd files (that include each other) the wrong file is coupled with the wrong stream
in org.apache.cxf.wsdl.EndpointReferenceUtils. It concerns method SchemaLSResourceResolver#resolveResource.

Observation:
1) The resolver is constructed with a correct set of entries (Schemas).
2) The resolver then tries to match on (ending of) systemId:targetNameSpace (that fails)
3) The resolver then tries to match on (ending of) targetNamespace only. All entries on the
same namespace match, so the first one (arbitrary) is resolved. 

I've prepared a patch on this class that fixes the issue. Test projects are available.

@Line210 I've included the following code:
            // Sjaak PATCH
            // there can be multiple includes on the same namespace. This scenario is not
envisioned yet.
            // hence the filename part is included as well. 
            if (systemId != null) {
                String systemIdFileName = systemId.substring(systemId.lastIndexOf('/') + 1);
                for (Map.Entry<String, byte[]> ent : schemas.entrySet()) {
                    System.out.println("matching: " + ent.getKey() + " endswith: " + systemIdFileName
+ ":" + namespaceURI);
                    if (ent.getKey().endsWith(systemIdFileName + ":" + namespaceURI)) {
                        schemas.remove(ent.getKey());
                        impl = new LSInputImpl();
                        impl.setSystemId(newId);
                        impl.setBaseURI(newId);
                        impl.setCharacterStream(
                                new InputStreamReader(
                                        new ByteArrayInputStream(ent.getValue())));
                        done.add(newId + ":" + namespaceURI);
                        System.out.println("match!, adding to done: " + ent.getKey() + "returning:
" + impl.getSystemId());
                        return impl;
                    }
                }
            }
            // sjaak END PATCH.

The patch introduces a step 2a to the steps above:

2a) The resolver then tries to match on (ending of) systemIdFileName:targetNameSpace (that
fails)

Best regards,
Sjaak 





> jax-ws-catalog.xml / @SchemaValidation /  xsd-includes 
> -------------------------------------------------------
>
>                 Key: CXF-5532
>                 URL: https://issues.apache.org/jira/browse/CXF-5532
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-WS Runtime
>    Affects Versions: 2.7.7
>         Environment: JBOSS EAP 6.1.1
>            Reporter: sjaak derksen
>
> When using catalog resolving (jax-ws-catalog.xml) in combination with @SchemaValidation
and a set of xsd files (that include each other) the wrong file is coupled with the wrong
stream in org.apache.cxf.wsdl.EndpointReferenceUtils. It concerns method SchemaLSResourceResolver#resolveResource.
> Observation:
> 1) The resolver is constructed with a correct set of entries (Schemas).
> 2) The resolver then tries to match on (ending of) systemId:targetNameSpace (that fails)
> 3) The resolver then tries to match on (ending of) targetNamespace only. All entries
on the same namespace match, so the first one (arbitrary) is resolved. 
> I've prepared a patch on this class that fixes the issue. Test projects are available.
> {code:java}
> @Line210 I've included the following code:
>             // Sjaak PATCH
>             // there can be multiple includes on the same namespace. This scenario is
not envisioned yet.
>             // hence the filename part is included as well. 
>             if (systemId != null) {
>                 String systemIdFileName = systemId.substring(systemId.lastIndexOf('/')
+ 1);
>                 for (Map.Entry<String, byte[]> ent : schemas.entrySet()) {
>                     System.out.println("matching: " + ent.getKey() + " endswith: " +
systemIdFileName + ":" + namespaceURI);
>                     if (ent.getKey().endsWith(systemIdFileName + ":" + namespaceURI))
{
>                         schemas.remove(ent.getKey());
>                         impl = new LSInputImpl();
>                         impl.setSystemId(newId);
>                         impl.setBaseURI(newId);
>                         impl.setCharacterStream(
>                                 new InputStreamReader(
>                                         new ByteArrayInputStream(ent.getValue())));
>                         done.add(newId + ":" + namespaceURI);
>                         System.out.println("match!, adding to done: " + ent.getKey()
+ "returning: " + impl.getSystemId());
>                         return impl;
>                     }
>                 }
>             }
>             // sjaak END PATCH.
> {code}
> The patch introduces a step 2a to the steps above:
> 2a) The resolver then tries to match on (ending of) systemIdFileName:targetNameSpace
(that fails)
> Best regards,
> Sjaak 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message