You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Dobri Kitipov <kd...@googlemail.com> on 2008/10/01 14:13:00 UTC

Proposal for a fix in Axis2 1.4.X related to import location and schemaLocation set in a WSDL. Patch available

Hi guys,
we have a patch done for org.apache.axis2.description.AxisService related to
the JIRA https://issues.apache.org/jira/browse/AXIS2-1790. With this patch
Axis2 can be configured to set all location and schemaLocation paths to
absolute URI paths if they are relative. As we know this URI may has
relative or absolute path (
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-import),
so the relative path is absolutely legal. Anyway, using absolute paths
solves some interoperability issues. I realize that in fact there is no
problem with Axis2 itself, but we can think of this patch as an enhancement.
The question is if you think we can include this into the official Axis2?

Additionally, I want to mention two things related to the code of
org.apache.axis2.description.AxisService:

1) The first one is the vague role of the "wsdlImportLocationAdjusted"
field. IMHO the use of this parameter is error-prone. If you have a look at
the printDefinitionObject() method you can see that this field is set to
"true" when WSDL is requested for the very first time. Before that
changeImportAndIncludeLocations(definition) method is invoked. The problem
here is that at every successive invocation this method is no more called
and as a result WSDL returned may differ. Can you give some more information
why this field is needed, since if  it is no needed then it is better to be
removed?

2) The second thing is with the method: public String[] getEPRs() throws
AxisFault. It throws AxisFault which exception is a checked one that is
never thrown. So the user is forced to catch this exception when he wants to
use this public class.


I am expecting your comments.

Thank you in advance,
Dobri

Re: Proposal for a fix in Axis2 1.4.X related to import location and schemaLocation set in a WSDL. Patch available

Posted by Amila Suriarachchi <am...@gmail.com>.
applied you patch. please attach this patch to jira granting licence to
Apache.

thanks,
Amila.

On Fri, Oct 3, 2008 at 7:06 PM, Dobri Kitipov
<kd...@googlemail.com>wrote:

> Hi Amila,
> It seems that the fix into the trunk is ok. I did some tests and found out
> that the fix is not complete when you request xsd with "...?xsd".
> The problem was that if GENERATE_ABSOLUTE_LOCATION_URIS is set to true and
> you import an xsd that in turn imports another external xsd then the letter
> has relative path again.
>
> You can test this with the AAR attached to the mail. Rrequest http://<YOUR_HOST>/axis2/services/MultiDimentionalArrayInteropTestService?xsd=xsd0.xsd
> and you will see the following:
>
> <xs:import namespace="http://jaxb.dev.java.net/array"
> schemaLocation="MultiDimentionalArrayInteropTestService?xsd=xsd1.xsd"/>
>
> instead of
>
> <xs:import namespace="http://jaxb.dev.java.net/array"
> schemaLocation="http://
> <YOUR_HOST>/axis2/services/MultiDimentionalArrayInteropTestService?xsd=xsd1.xsd"/>
>
> The problem was caused by the AxisService private void
> adjustSchemaLocation(...) method.
>
> I am applying a patch for this, but the patch removes and all not thrown
> AxisFault exceptions sience this caused me throubles. See the patch applied
> to the mail it is really simple.
>
> Thank you,
> Dobri
>
>
>
> On Thu, Oct 2, 2008 at 10:08 AM, Amila Suriarachchi <
> amilasuriarachchi@gmail.com> wrote:
>
>>
>>
>> On Wed, Oct 1, 2008 at 5:43 PM, Dobri Kitipov <
>> kdobrik.axis2@googlemail.com> wrote:
>>
>>> Hi guys,
>>> we have a patch done for org.apache.axis2.description.AxisService related
>>> to the JIRA https://issues.apache.org/jira/browse/AXIS2-1790. With this
>>> patch Axis2 can be configured to set all location and schemaLocation paths
>>> to absolute URI paths if they are relative. As we know this URI may has
>>> relative or absolute path (
>>> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-import),
>>> so the relative path is absolutely legal. Anyway, using absolute paths
>>> solves some interoperability issues. I realize that in fact there is no
>>> problem with Axis2 itself, but we can think of this patch as an enhancement.
>>> The question is if you think we can include this into the official Axis2?
>>>
>>
>> Did you have a time to have a look at with the trunk. I have fixed this
>> already.  you have to set the parameter
>> generateAbsoluteLocationURIs to make this work.
>>
>> Please have a look at this method.
>>
>> private String getServiceEPR() throws AxisFault {
>>         String serviceEPR = null;
>>         Parameter parameter =
>> this.getParameter(Constants.Configuration.GENERATE_ABSOLUTE_LOCATION_URIS);
>>         if ((parameter != null) &&
>> JavaUtils.isTrueExplicitly(parameter.getValue())) {
>>             String[] eprs = this.getEPRs();
>>             for (int i = 0; i < eprs.length; i++) {
>>                 if ((eprs[i] != null) && (eprs[i].startsWith("http:"))){
>>                     serviceEPR = eprs[i];
>>                     break;
>>                 }
>>             }
>>             if (serviceEPR == null){
>>                 serviceEPR = eprs[0];
>>             }
>>         } else {
>>             serviceEPR = this.name;
>>         }
>>         if (serviceEPR.endsWith("/")){
>>             serviceEPR = serviceEPR.substring(0,
>> serviceEPR.lastIndexOf("/"));
>>         }
>>         return serviceEPR;
>>     }
>>
>>
>>
>>>
>>> Additionally, I want to mention two things related to the code of
>>> org.apache.axis2.description.AxisService:
>>>
>>> 1) The first one is the vague role of the "wsdlImportLocationAdjusted"
>>> field. IMHO the use of this parameter is error-prone. If you have a look at
>>> the printDefinitionObject() method you can see that this field is set to
>>> "true" when WSDL is requested for the very first time. Before that
>>> changeImportAndIncludeLocations(definition) method is invoked. The problem
>>> here is that at every successive invocation this method is no more called
>>> and as a result WSDL returned may differ. Can you give some more information
>>> why this field is needed, since if  it is no needed then it is better to be
>>> removed?
>>>
>>
>> I think I removed those unwanted usages and now it only uses here.
>>
>> if (!wsdlImportLocationAdjusted) {
>>             changeImportAndIncludeLocations(definition);
>>             wsdlImportLocationAdjusted = true;
>>         }
>>
>> this keeps whether we have already change the import and include
>> locations.
>>
>>>
>>>
>>> 2) The second thing is with the method: public String[] getEPRs() throws
>>> AxisFault. It throws AxisFault which exception is a checked one that is
>>> never thrown. So the user is forced to catch this exception when he wants to
>>> use this public class.
>>>
>>
>> yes. I agree with you that  this exception is not  needed. But I wonder
>> whether we are in a possision to change
>> those APIs now.
>>
>> thanks,
>> Amila.
>>
>>>
>>>
>>>
>>> I am expecting your comments.
>>>
>>> Thank you in advance,
>>> Dobri
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Proposal for a fix in Axis2 1.4.X related to import location and schemaLocation set in a WSDL. Patch available

Posted by Dobri Kitipov <kd...@googlemail.com>.
Hi Amila,
It seems that the fix into the trunk is ok. I did some tests and found out
that the fix is not complete when you request xsd with "...?xsd".
The problem was that if GENERATE_ABSOLUTE_LOCATION_URIS is set to true and
you import an xsd that in turn imports another external xsd then the letter
has relative path again.

You can test this with the AAR attached to the mail. Rrequest
http://<YOUR_HOST>/axis2/services/MultiDimentionalArrayInteropTestService?xsd=xsd0.xsd
and you will see the following:

<xs:import namespace="http://jaxb.dev.java.net/array"
schemaLocation="MultiDimentionalArrayInteropTestService?xsd=xsd1.xsd"/>

instead of

<xs:import namespace="http://jaxb.dev.java.net/array"
schemaLocation="http://
<YOUR_HOST>/axis2/services/MultiDimentionalArrayInteropTestService?xsd=xsd1.xsd"/>

The problem was caused by the AxisService private void
adjustSchemaLocation(...) method.

I am applying a patch for this, but the patch removes and all not thrown
AxisFault exceptions sience this caused me throubles. See the patch applied
to the mail it is really simple.

Thank you,
Dobri


On Thu, Oct 2, 2008 at 10:08 AM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:

>
>
> On Wed, Oct 1, 2008 at 5:43 PM, Dobri Kitipov <
> kdobrik.axis2@googlemail.com> wrote:
>
>> Hi guys,
>> we have a patch done for org.apache.axis2.description.AxisService related
>> to the JIRA https://issues.apache.org/jira/browse/AXIS2-1790. With this
>> patch Axis2 can be configured to set all location and schemaLocation paths
>> to absolute URI paths if they are relative. As we know this URI may has
>> relative or absolute path (
>> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-import),
>> so the relative path is absolutely legal. Anyway, using absolute paths
>> solves some interoperability issues. I realize that in fact there is no
>> problem with Axis2 itself, but we can think of this patch as an enhancement.
>> The question is if you think we can include this into the official Axis2?
>>
>
> Did you have a time to have a look at with the trunk. I have fixed this
> already.  you have to set the parameter
> generateAbsoluteLocationURIs to make this work.
>
> Please have a look at this method.
>
> private String getServiceEPR() throws AxisFault {
>         String serviceEPR = null;
>         Parameter parameter =
> this.getParameter(Constants.Configuration.GENERATE_ABSOLUTE_LOCATION_URIS);
>         if ((parameter != null) &&
> JavaUtils.isTrueExplicitly(parameter.getValue())) {
>             String[] eprs = this.getEPRs();
>             for (int i = 0; i < eprs.length; i++) {
>                 if ((eprs[i] != null) && (eprs[i].startsWith("http:"))){
>                     serviceEPR = eprs[i];
>                     break;
>                 }
>             }
>             if (serviceEPR == null){
>                 serviceEPR = eprs[0];
>             }
>         } else {
>             serviceEPR = this.name;
>         }
>         if (serviceEPR.endsWith("/")){
>             serviceEPR = serviceEPR.substring(0,
> serviceEPR.lastIndexOf("/"));
>         }
>         return serviceEPR;
>     }
>
>
>
>>
>> Additionally, I want to mention two things related to the code of
>> org.apache.axis2.description.AxisService:
>>
>> 1) The first one is the vague role of the "wsdlImportLocationAdjusted"
>> field. IMHO the use of this parameter is error-prone. If you have a look at
>> the printDefinitionObject() method you can see that this field is set to
>> "true" when WSDL is requested for the very first time. Before that
>> changeImportAndIncludeLocations(definition) method is invoked. The problem
>> here is that at every successive invocation this method is no more called
>> and as a result WSDL returned may differ. Can you give some more information
>> why this field is needed, since if  it is no needed then it is better to be
>> removed?
>>
>
> I think I removed those unwanted usages and now it only uses here.
>
> if (!wsdlImportLocationAdjusted) {
>             changeImportAndIncludeLocations(definition);
>             wsdlImportLocationAdjusted = true;
>         }
>
> this keeps whether we have already change the import and include locations.
>
>
>>
>>
>> 2) The second thing is with the method: public String[] getEPRs() throws
>> AxisFault. It throws AxisFault which exception is a checked one that is
>> never thrown. So the user is forced to catch this exception when he wants to
>> use this public class.
>>
>
> yes. I agree with you that  this exception is not  needed. But I wonder
> whether we are in a possision to change
> those APIs now.
>
> thanks,
> Amila.
>
>>
>>
>>
>> I am expecting your comments.
>>
>> Thank you in advance,
>> Dobri
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>

Re: Proposal for a fix in Axis2 1.4.X related to import location and schemaLocation set in a WSDL. Patch available

Posted by Amila Suriarachchi <am...@gmail.com>.
On Wed, Oct 1, 2008 at 5:43 PM, Dobri Kitipov
<kd...@googlemail.com>wrote:

> Hi guys,
> we have a patch done for org.apache.axis2.description.AxisService related
> to the JIRA https://issues.apache.org/jira/browse/AXIS2-1790. With this
> patch Axis2 can be configured to set all location and schemaLocation paths
> to absolute URI paths if they are relative. As we know this URI may has
> relative or absolute path (
> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-import),
> so the relative path is absolutely legal. Anyway, using absolute paths
> solves some interoperability issues. I realize that in fact there is no
> problem with Axis2 itself, but we can think of this patch as an enhancement.
> The question is if you think we can include this into the official Axis2?
>

Did you have a time to have a look at with the trunk. I have fixed this
already.  you have to set the parameter
generateAbsoluteLocationURIs to make this work.

Please have a look at this method.

private String getServiceEPR() throws AxisFault {
        String serviceEPR = null;
        Parameter parameter =
this.getParameter(Constants.Configuration.GENERATE_ABSOLUTE_LOCATION_URIS);
        if ((parameter != null) &&
JavaUtils.isTrueExplicitly(parameter.getValue())) {
            String[] eprs = this.getEPRs();
            for (int i = 0; i < eprs.length; i++) {
                if ((eprs[i] != null) && (eprs[i].startsWith("http:"))){
                    serviceEPR = eprs[i];
                    break;
                }
            }
            if (serviceEPR == null){
                serviceEPR = eprs[0];
            }
        } else {
            serviceEPR = this.name;
        }
        if (serviceEPR.endsWith("/")){
            serviceEPR = serviceEPR.substring(0,
serviceEPR.lastIndexOf("/"));
        }
        return serviceEPR;
    }



>
> Additionally, I want to mention two things related to the code of
> org.apache.axis2.description.AxisService:
>
> 1) The first one is the vague role of the "wsdlImportLocationAdjusted"
> field. IMHO the use of this parameter is error-prone. If you have a look at
> the printDefinitionObject() method you can see that this field is set to
> "true" when WSDL is requested for the very first time. Before that
> changeImportAndIncludeLocations(definition) method is invoked. The problem
> here is that at every successive invocation this method is no more called
> and as a result WSDL returned may differ. Can you give some more information
> why this field is needed, since if  it is no needed then it is better to be
> removed?
>

I think I removed those unwanted usages and now it only uses here.

if (!wsdlImportLocationAdjusted) {
            changeImportAndIncludeLocations(definition);
            wsdlImportLocationAdjusted = true;
        }

this keeps whether we have already change the import and include locations.

>
>
> 2) The second thing is with the method: public String[] getEPRs() throws
> AxisFault. It throws AxisFault which exception is a checked one that is
> never thrown. So the user is forced to catch this exception when he wants to
> use this public class.
>

yes. I agree with you that  this exception is not  needed. But I wonder
whether we are in a possision to change
those APIs now.

thanks,
Amila.

>
>
>
> I am expecting your comments.
>
> Thank you in advance,
> Dobri
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/