You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jason Pell <jp...@apache.org> on 2013/09/24 06:49:55 UTC
2.7.7 possible issue with loading security schema
Hi,
I upgraded our environment to use 2.7.7 and immediately upon deployment I
started getting the following error:
org.xml.sax.SAXParseException; systemId:
http://www.w3.org/2007/02/ws-policy.xsd; lineNumber: 30; columnNumber: 69;
schema_reference.4: Failed to read schema document
'oasis-200401-wss-wssecurity-secext-1.0.xsd', because 1) could not find the
document; 2) the document could not be read; 3) the root element of the
document is not <xsd:schema>.
this looks like perhaps there is a spring schemas mapping missing?
I have lowered the logging for now so that I don't see the WARN, but
wondered if anyone was aware why I would be seeing this now.
I am behind a firewall, but I was behind a firewall in 2.7.6 and did not
see this message in the logs.
Thanks for any info you might have
Re: 2.7.7 possible issue with loading security schema
Posted by Daniel Kulp <dk...@apache.org>.
On Sep 24, 2013, at 3:10 PM, Aki Yoshida <el...@gmail.com> wrote:
> maybe this is just a guess, but shouldn't adding those referenced
> schemas to the relevant BP namespace handlers's schema lookup code
> would solve this look up problem? I think those schemas were not
> included there because we don't directly use those namespaces in
> blueprint.xml.
If you look at the commit, I did try that and it didn't completely fix the problem. Not really sure why as I didn't have time to completely dig into blueprint yet. I know initially blueprint will only gather up the schemas for all the namespaces it finds (which the imported namespaces aren't part of those) and thus goes down a different path for the imports. Would need to recheck to figure out what was happening.
Dan
> the relative path problem in spring is strange. I didn't observe this
> problem in 2.7.7 when I ran those spring based unit tests without the
> network. And we were using a relative path in some schemas (e.g.,
> wsrm-manager.xsd) for a long time.
>
> regards, aki
>
>
>
>
>
> 2013/9/24 Daniel Kulp <dk...@apache.org>:
>>
>> Erg…. copy paste apparently cut off the locations.
>>
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
>>
>>
>> Dan
>>
>> On Sep 24, 2013, at 12:28 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>>>
>>> Ran into this yesterday while trying to diagnose a similar issue with Colm.
>>>
>>> It's a result of: https://issues.apache.org/jira/browse/CXF-5181
>>>
>>> Apparently there is a complete miss match between Spring and Blueprint in this regards. If we use full absolute paths, blueprint goes off to the internet. If we don't, Spring does (by default). It's really a bug in Spring. When Spring resolves a resource (such as an xsd), it doesn't set the SystemID on the InputSource. Thus, the xml parser cannot resolve the relative paths correctly.
>>>
>>> With spring, if you update the schemaLocation in your beans.xml to add:
>>>
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd http://docs.oasis-open.or
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd http://docs.oasis-open.o
>>> http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
>>>
>>> that will likely fix it.
>>>
>>> I'm going to try and dig into Aries blueprint to see if we can fix the problem with absolute paths there and if so, revert the schemas back. But for now, we have a workaround for Spring, but not for blueprint so we're using the relative paths that then work with blueprint.
>>>
>>> Dan
>>>
>>>
>>> On Sep 24, 2013, at 2:50 AM, Jason Pell <ja...@pellcorp.com> wrote:
>>>
>>>> I think this issue is causing hanging of startup of my application. I am
>>>> reverting to 2.7.6.
>>>>
>>>> I will debug and try to figure out what is wrong and raise a jira + fix if
>>>> possible.
>>>>
>>>> Any info anyone of the devs may have though would be appreciated.
>>>>
>>>> I am running with spring 3.1 and embedded jetty with WS policy username
>>>> password with with java first
>>>>
>>>> Sent from my Android phone
>>>> On 24/09/2013 2:49 PM, "Jason Pell" <jp...@apache.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I upgraded our environment to use 2.7.7 and immediately upon deployment I
>>>>> started getting the following error:
>>>>>
>>>>> org.xml.sax.SAXParseException; systemId:
>>>>> http://www.w3.org/2007/02/ws-policy.xsd; lineNumber: 30; columnNumber:
>>>>> 69; schema_reference.4: Failed to read schema document
>>>>> 'oasis-200401-wss-wssecurity-secext-1.0.xsd', because 1) could not find the
>>>>> document; 2) the document could not be read; 3) the root element of the
>>>>> document is not <xsd:schema>.
>>>>>
>>>>> this looks like perhaps there is a spring schemas mapping missing?
>>>>>
>>>>> I have lowered the logging for now so that I don't see the WARN, but
>>>>> wondered if anyone was aware why I would be seeing this now.
>>>>>
>>>>> I am behind a firewall, but I was behind a firewall in 2.7.6 and did not
>>>>> see this message in the logs.
>>>>>
>>>>> Thanks for any info you might have
>>>>>
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: 2.7.7 possible issue with loading security schema
Posted by Jason Pell <ja...@pellcorp.com>.
Silly me Dan provided the reason in original reply.
I will chase up in our code
Thanks
Jason
Sent from my Android phone
On 25/09/2013 6:55 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
> No internet is better than a corporate proxy situation that causes
> internet requests to take a lonnnnnggggggg time to timeout. I had been
> using the spring mappings but perhaps I missed some.
>
> Any idea why this shows itself in 2.7.7 and not 2.7.6
>
> Sent from my Android phone
> On 25/09/2013 5:11 AM, "Aki Yoshida" <el...@gmail.com> wrote:
>
>> maybe this is just a guess, but shouldn't adding those referenced
>> schemas to the relevant BP namespace handlers's schema lookup code
>> would solve this look up problem? I think those schemas were not
>> included there because we don't directly use those namespaces in
>> blueprint.xml.
>>
>> the relative path problem in spring is strange. I didn't observe this
>> problem in 2.7.7 when I ran those spring based unit tests without the
>> network. And we were using a relative path in some schemas (e.g.,
>> wsrm-manager.xsd) for a long time.
>>
>> regards, aki
>>
>>
>>
>>
>>
>> 2013/9/24 Daniel Kulp <dk...@apache.org>:
>> >
>> > Erg…. copy paste apparently cut off the locations.
>> >
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> > http://www.w3.org/2000/09/xmldsig#
>> http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
>> >
>> >
>> > Dan
>> >
>> > On Sep 24, 2013, at 12:28 PM, Daniel Kulp <dk...@apache.org> wrote:
>> >
>> >>
>> >> Ran into this yesterday while trying to diagnose a similar issue with
>> Colm.
>> >>
>> >> It's a result of: https://issues.apache.org/jira/browse/CXF-5181
>> >>
>> >> Apparently there is a complete miss match between Spring and Blueprint
>> in this regards. If we use full absolute paths, blueprint goes off to the
>> internet. If we don't, Spring does (by default). It's really a bug in
>> Spring. When Spring resolves a resource (such as an xsd), it doesn't set
>> the SystemID on the InputSource. Thus, the xml parser cannot resolve the
>> relative paths correctly.
>> >>
>> >> With spring, if you update the schemaLocation in your beans.xml to add:
>> >>
>> >>
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> http://docs.oasis-open.or
>> >>
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> http://docs.oasis-open.o
>> >> http://www.w3.org/2000/09/xmldsig#
>> http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
>> >>
>> >> that will likely fix it.
>> >>
>> >> I'm going to try and dig into Aries blueprint to see if we can fix the
>> problem with absolute paths there and if so, revert the schemas back. But
>> for now, we have a workaround for Spring, but not for blueprint so we're
>> using the relative paths that then work with blueprint.
>> >>
>> >> Dan
>> >>
>> >>
>> >> On Sep 24, 2013, at 2:50 AM, Jason Pell <ja...@pellcorp.com> wrote:
>> >>
>> >>> I think this issue is causing hanging of startup of my application. I
>> am
>> >>> reverting to 2.7.6.
>> >>>
>> >>> I will debug and try to figure out what is wrong and raise a jira +
>> fix if
>> >>> possible.
>> >>>
>> >>> Any info anyone of the devs may have though would be appreciated.
>> >>>
>> >>> I am running with spring 3.1 and embedded jetty with WS policy
>> username
>> >>> password with with java first
>> >>>
>> >>> Sent from my Android phone
>> >>> On 24/09/2013 2:49 PM, "Jason Pell" <jp...@apache.org> wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> I upgraded our environment to use 2.7.7 and immediately upon
>> deployment I
>> >>>> started getting the following error:
>> >>>>
>> >>>> org.xml.sax.SAXParseException; systemId:
>> >>>> http://www.w3.org/2007/02/ws-policy.xsd; lineNumber: 30;
>> columnNumber:
>> >>>> 69; schema_reference.4: Failed to read schema document
>> >>>> 'oasis-200401-wss-wssecurity-secext-1.0.xsd', because 1) could not
>> find the
>> >>>> document; 2) the document could not be read; 3) the root element of
>> the
>> >>>> document is not <xsd:schema>.
>> >>>>
>> >>>> this looks like perhaps there is a spring schemas mapping missing?
>> >>>>
>> >>>> I have lowered the logging for now so that I don't see the WARN, but
>> >>>> wondered if anyone was aware why I would be seeing this now.
>> >>>>
>> >>>> I am behind a firewall, but I was behind a firewall in 2.7.6 and did
>> not
>> >>>> see this message in the logs.
>> >>>>
>> >>>> Thanks for any info you might have
>> >>>>
>> >>
>> >> --
>> >> Daniel Kulp
>> >> dkulp@apache.org - http://dankulp.com/blog
>> >> Talend Community Coder - http://coders.talend.com
>> >>
>> >
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org - http://dankulp.com/blog
>> > Talend Community Coder - http://coders.talend.com
>> >
>>
>
Re: 2.7.7 possible issue with loading security schema
Posted by Jason Pell <ja...@pellcorp.com>.
No internet is better than a corporate proxy situation that causes internet
requests to take a lonnnnnggggggg time to timeout. I had been using the
spring mappings but perhaps I missed some.
Any idea why this shows itself in 2.7.7 and not 2.7.6
Sent from my Android phone
On 25/09/2013 5:11 AM, "Aki Yoshida" <el...@gmail.com> wrote:
> maybe this is just a guess, but shouldn't adding those referenced
> schemas to the relevant BP namespace handlers's schema lookup code
> would solve this look up problem? I think those schemas were not
> included there because we don't directly use those namespaces in
> blueprint.xml.
>
> the relative path problem in spring is strange. I didn't observe this
> problem in 2.7.7 when I ran those spring based unit tests without the
> network. And we were using a relative path in some schemas (e.g.,
> wsrm-manager.xsd) for a long time.
>
> regards, aki
>
>
>
>
>
> 2013/9/24 Daniel Kulp <dk...@apache.org>:
> >
> > Erg…. copy paste apparently cut off the locations.
> >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> > http://www.w3.org/2000/09/xmldsig#
> http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
> >
> >
> > Dan
> >
> > On Sep 24, 2013, at 12:28 PM, Daniel Kulp <dk...@apache.org> wrote:
> >
> >>
> >> Ran into this yesterday while trying to diagnose a similar issue with
> Colm.
> >>
> >> It's a result of: https://issues.apache.org/jira/browse/CXF-5181
> >>
> >> Apparently there is a complete miss match between Spring and Blueprint
> in this regards. If we use full absolute paths, blueprint goes off to the
> internet. If we don't, Spring does (by default). It's really a bug in
> Spring. When Spring resolves a resource (such as an xsd), it doesn't set
> the SystemID on the InputSource. Thus, the xml parser cannot resolve the
> relative paths correctly.
> >>
> >> With spring, if you update the schemaLocation in your beans.xml to add:
> >>
> >>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> http://docs.oasis-open.or
> >>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> http://docs.oasis-open.o
> >> http://www.w3.org/2000/09/xmldsig#
> http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
> >>
> >> that will likely fix it.
> >>
> >> I'm going to try and dig into Aries blueprint to see if we can fix the
> problem with absolute paths there and if so, revert the schemas back. But
> for now, we have a workaround for Spring, but not for blueprint so we're
> using the relative paths that then work with blueprint.
> >>
> >> Dan
> >>
> >>
> >> On Sep 24, 2013, at 2:50 AM, Jason Pell <ja...@pellcorp.com> wrote:
> >>
> >>> I think this issue is causing hanging of startup of my application. I
> am
> >>> reverting to 2.7.6.
> >>>
> >>> I will debug and try to figure out what is wrong and raise a jira +
> fix if
> >>> possible.
> >>>
> >>> Any info anyone of the devs may have though would be appreciated.
> >>>
> >>> I am running with spring 3.1 and embedded jetty with WS policy username
> >>> password with with java first
> >>>
> >>> Sent from my Android phone
> >>> On 24/09/2013 2:49 PM, "Jason Pell" <jp...@apache.org> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I upgraded our environment to use 2.7.7 and immediately upon
> deployment I
> >>>> started getting the following error:
> >>>>
> >>>> org.xml.sax.SAXParseException; systemId:
> >>>> http://www.w3.org/2007/02/ws-policy.xsd; lineNumber: 30;
> columnNumber:
> >>>> 69; schema_reference.4: Failed to read schema document
> >>>> 'oasis-200401-wss-wssecurity-secext-1.0.xsd', because 1) could not
> find the
> >>>> document; 2) the document could not be read; 3) the root element of
> the
> >>>> document is not <xsd:schema>.
> >>>>
> >>>> this looks like perhaps there is a spring schemas mapping missing?
> >>>>
> >>>> I have lowered the logging for now so that I don't see the WARN, but
> >>>> wondered if anyone was aware why I would be seeing this now.
> >>>>
> >>>> I am behind a firewall, but I was behind a firewall in 2.7.6 and did
> not
> >>>> see this message in the logs.
> >>>>
> >>>> Thanks for any info you might have
> >>>>
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
Re: 2.7.7 possible issue with loading security schema
Posted by Aki Yoshida <el...@gmail.com>.
maybe this is just a guess, but shouldn't adding those referenced
schemas to the relevant BP namespace handlers's schema lookup code
would solve this look up problem? I think those schemas were not
included there because we don't directly use those namespaces in
blueprint.xml.
the relative path problem in spring is strange. I didn't observe this
problem in 2.7.7 when I ran those spring based unit tests without the
network. And we were using a relative path in some schemas (e.g.,
wsrm-manager.xsd) for a long time.
regards, aki
2013/9/24 Daniel Kulp <dk...@apache.org>:
>
> Erg…. copy paste apparently cut off the locations.
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
>
>
> Dan
>
> On Sep 24, 2013, at 12:28 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> Ran into this yesterday while trying to diagnose a similar issue with Colm.
>>
>> It's a result of: https://issues.apache.org/jira/browse/CXF-5181
>>
>> Apparently there is a complete miss match between Spring and Blueprint in this regards. If we use full absolute paths, blueprint goes off to the internet. If we don't, Spring does (by default). It's really a bug in Spring. When Spring resolves a resource (such as an xsd), it doesn't set the SystemID on the InputSource. Thus, the xml parser cannot resolve the relative paths correctly.
>>
>> With spring, if you update the schemaLocation in your beans.xml to add:
>>
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd http://docs.oasis-open.or
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd http://docs.oasis-open.o
>> http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
>>
>> that will likely fix it.
>>
>> I'm going to try and dig into Aries blueprint to see if we can fix the problem with absolute paths there and if so, revert the schemas back. But for now, we have a workaround for Spring, but not for blueprint so we're using the relative paths that then work with blueprint.
>>
>> Dan
>>
>>
>> On Sep 24, 2013, at 2:50 AM, Jason Pell <ja...@pellcorp.com> wrote:
>>
>>> I think this issue is causing hanging of startup of my application. I am
>>> reverting to 2.7.6.
>>>
>>> I will debug and try to figure out what is wrong and raise a jira + fix if
>>> possible.
>>>
>>> Any info anyone of the devs may have though would be appreciated.
>>>
>>> I am running with spring 3.1 and embedded jetty with WS policy username
>>> password with with java first
>>>
>>> Sent from my Android phone
>>> On 24/09/2013 2:49 PM, "Jason Pell" <jp...@apache.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> I upgraded our environment to use 2.7.7 and immediately upon deployment I
>>>> started getting the following error:
>>>>
>>>> org.xml.sax.SAXParseException; systemId:
>>>> http://www.w3.org/2007/02/ws-policy.xsd; lineNumber: 30; columnNumber:
>>>> 69; schema_reference.4: Failed to read schema document
>>>> 'oasis-200401-wss-wssecurity-secext-1.0.xsd', because 1) could not find the
>>>> document; 2) the document could not be read; 3) the root element of the
>>>> document is not <xsd:schema>.
>>>>
>>>> this looks like perhaps there is a spring schemas mapping missing?
>>>>
>>>> I have lowered the logging for now so that I don't see the WARN, but
>>>> wondered if anyone was aware why I would be seeing this now.
>>>>
>>>> I am behind a firewall, but I was behind a firewall in 2.7.6 and did not
>>>> see this message in the logs.
>>>>
>>>> Thanks for any info you might have
>>>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: 2.7.7 possible issue with loading security schema
Posted by Daniel Kulp <dk...@apache.org>.
Erg…. copy paste apparently cut off the locations.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
Dan
On Sep 24, 2013, at 12:28 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> Ran into this yesterday while trying to diagnose a similar issue with Colm.
>
> It's a result of: https://issues.apache.org/jira/browse/CXF-5181
>
> Apparently there is a complete miss match between Spring and Blueprint in this regards. If we use full absolute paths, blueprint goes off to the internet. If we don't, Spring does (by default). It's really a bug in Spring. When Spring resolves a resource (such as an xsd), it doesn't set the SystemID on the InputSource. Thus, the xml parser cannot resolve the relative paths correctly.
>
> With spring, if you update the schemaLocation in your beans.xml to add:
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd http://docs.oasis-open.or
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd http://docs.oasis-open.o
> http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
>
> that will likely fix it.
>
> I'm going to try and dig into Aries blueprint to see if we can fix the problem with absolute paths there and if so, revert the schemas back. But for now, we have a workaround for Spring, but not for blueprint so we're using the relative paths that then work with blueprint.
>
> Dan
>
>
> On Sep 24, 2013, at 2:50 AM, Jason Pell <ja...@pellcorp.com> wrote:
>
>> I think this issue is causing hanging of startup of my application. I am
>> reverting to 2.7.6.
>>
>> I will debug and try to figure out what is wrong and raise a jira + fix if
>> possible.
>>
>> Any info anyone of the devs may have though would be appreciated.
>>
>> I am running with spring 3.1 and embedded jetty with WS policy username
>> password with with java first
>>
>> Sent from my Android phone
>> On 24/09/2013 2:49 PM, "Jason Pell" <jp...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> I upgraded our environment to use 2.7.7 and immediately upon deployment I
>>> started getting the following error:
>>>
>>> org.xml.sax.SAXParseException; systemId:
>>> http://www.w3.org/2007/02/ws-policy.xsd; lineNumber: 30; columnNumber:
>>> 69; schema_reference.4: Failed to read schema document
>>> 'oasis-200401-wss-wssecurity-secext-1.0.xsd', because 1) could not find the
>>> document; 2) the document could not be read; 3) the root element of the
>>> document is not <xsd:schema>.
>>>
>>> this looks like perhaps there is a spring schemas mapping missing?
>>>
>>> I have lowered the logging for now so that I don't see the WARN, but
>>> wondered if anyone was aware why I would be seeing this now.
>>>
>>> I am behind a firewall, but I was behind a firewall in 2.7.6 and did not
>>> see this message in the logs.
>>>
>>> Thanks for any info you might have
>>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: 2.7.7 possible issue with loading security schema
Posted by Daniel Kulp <dk...@apache.org>.
Ran into this yesterday while trying to diagnose a similar issue with Colm.
It's a result of: https://issues.apache.org/jira/browse/CXF-5181
Apparently there is a complete miss match between Spring and Blueprint in this regards. If we use full absolute paths, blueprint goes off to the internet. If we don't, Spring does (by default). It's really a bug in Spring. When Spring resolves a resource (such as an xsd), it doesn't set the SystemID on the InputSource. Thus, the xml parser cannot resolve the relative paths correctly.
With spring, if you update the schemaLocation in your beans.xml to add:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd http://docs.oasis-open.or
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd http://docs.oasis-open.o
http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
that will likely fix it.
I'm going to try and dig into Aries blueprint to see if we can fix the problem with absolute paths there and if so, revert the schemas back. But for now, we have a workaround for Spring, but not for blueprint so we're using the relative paths that then work with blueprint.
Dan
On Sep 24, 2013, at 2:50 AM, Jason Pell <ja...@pellcorp.com> wrote:
> I think this issue is causing hanging of startup of my application. I am
> reverting to 2.7.6.
>
> I will debug and try to figure out what is wrong and raise a jira + fix if
> possible.
>
> Any info anyone of the devs may have though would be appreciated.
>
> I am running with spring 3.1 and embedded jetty with WS policy username
> password with with java first
>
> Sent from my Android phone
> On 24/09/2013 2:49 PM, "Jason Pell" <jp...@apache.org> wrote:
>
>> Hi,
>>
>> I upgraded our environment to use 2.7.7 and immediately upon deployment I
>> started getting the following error:
>>
>> org.xml.sax.SAXParseException; systemId:
>> http://www.w3.org/2007/02/ws-policy.xsd; lineNumber: 30; columnNumber:
>> 69; schema_reference.4: Failed to read schema document
>> 'oasis-200401-wss-wssecurity-secext-1.0.xsd', because 1) could not find the
>> document; 2) the document could not be read; 3) the root element of the
>> document is not <xsd:schema>.
>>
>> this looks like perhaps there is a spring schemas mapping missing?
>>
>> I have lowered the logging for now so that I don't see the WARN, but
>> wondered if anyone was aware why I would be seeing this now.
>>
>> I am behind a firewall, but I was behind a firewall in 2.7.6 and did not
>> see this message in the logs.
>>
>> Thanks for any info you might have
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: 2.7.7 possible issue with loading security schema
Posted by Aki Yoshida <el...@gmail.com>.
I am aware of the change that we needed to make in the schema lookup
entries for trunk after its api+core packages were refactored.
But I don't know if there was any change in 2.7.x line that can affect
the schema lookup.
regards, aki
2013/9/24 Jason Pell <ja...@pellcorp.com>:
> I think this issue is causing hanging of startup of my application. I am
> reverting to 2.7.6.
>
> I will debug and try to figure out what is wrong and raise a jira + fix if
> possible.
>
> Any info anyone of the devs may have though would be appreciated.
>
> I am running with spring 3.1 and embedded jetty with WS policy username
> password with with java first
>
> Sent from my Android phone
> On 24/09/2013 2:49 PM, "Jason Pell" <jp...@apache.org> wrote:
>
>> Hi,
>>
>> I upgraded our environment to use 2.7.7 and immediately upon deployment I
>> started getting the following error:
>>
>> org.xml.sax.SAXParseException; systemId:
>> http://www.w3.org/2007/02/ws-policy.xsd; lineNumber: 30; columnNumber:
>> 69; schema_reference.4: Failed to read schema document
>> 'oasis-200401-wss-wssecurity-secext-1.0.xsd', because 1) could not find the
>> document; 2) the document could not be read; 3) the root element of the
>> document is not <xsd:schema>.
>>
>> this looks like perhaps there is a spring schemas mapping missing?
>>
>> I have lowered the logging for now so that I don't see the WARN, but
>> wondered if anyone was aware why I would be seeing this now.
>>
>> I am behind a firewall, but I was behind a firewall in 2.7.6 and did not
>> see this message in the logs.
>>
>> Thanks for any info you might have
>>
Re: 2.7.7 possible issue with loading security schema
Posted by Jason Pell <ja...@pellcorp.com>.
I think this issue is causing hanging of startup of my application. I am
reverting to 2.7.6.
I will debug and try to figure out what is wrong and raise a jira + fix if
possible.
Any info anyone of the devs may have though would be appreciated.
I am running with spring 3.1 and embedded jetty with WS policy username
password with with java first
Sent from my Android phone
On 24/09/2013 2:49 PM, "Jason Pell" <jp...@apache.org> wrote:
> Hi,
>
> I upgraded our environment to use 2.7.7 and immediately upon deployment I
> started getting the following error:
>
> org.xml.sax.SAXParseException; systemId:
> http://www.w3.org/2007/02/ws-policy.xsd; lineNumber: 30; columnNumber:
> 69; schema_reference.4: Failed to read schema document
> 'oasis-200401-wss-wssecurity-secext-1.0.xsd', because 1) could not find the
> document; 2) the document could not be read; 3) the root element of the
> document is not <xsd:schema>.
>
> this looks like perhaps there is a spring schemas mapping missing?
>
> I have lowered the logging for now so that I don't see the WARN, but
> wondered if anyone was aware why I would be seeing this now.
>
> I am behind a firewall, but I was behind a firewall in 2.7.6 and did not
> see this message in the logs.
>
> Thanks for any info you might have
>