Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] WMS, WFS, WMS-C fail in uDig 1.2-M6

I did not really fix it - I found something that was obviously wrong;
but it was not really a fix. You can try applying the same approach to
the other ServiceExtensions ....

But really we kind of have two strange bits of work happening?
1) make a map of params from a URL; if non null then we may understand
this service
2) make a URL from a map of params; if non null then we may understand
this service

Jody

On Mon, Jul 27, 2009 at 5:44 PM, Jesse
Eichar<jesse.eichar@xxxxxxxxxxxxxx> wrote:
> I guess jody managed to fix this?  Is there any thing else I need to do
> before making a new export?
>
> Jesse
>
> On Mon, Jul 27, 2009 at 9:10 AM, Jesse Eichar <jesse.eichar@xxxxxxxxxxxxxx>
> wrote:
>>
>> taking a look
>>
>> On Sat, Jul 25, 2009 at 5:15 PM, Jody Garnett <jody.garnett@xxxxxxxxx>
>> wrote:
>>>
>>> Okay a bit of progress on this one ... but the work flow involved is a
>>> bit crazy. WMSServiceExtension turns a URL into a map of parameters; from
>>> which a URL is etracted and passsed on to WMSConnectionFactory ....
>>> WMSConnectionFactory is handed a URL and was returning null ... looking
>>> at the file handling code and correcting it to the following works:
>>> public URL createConnectionURL(Object context) {
>>>     if( context instanceof URL ){
>>>         return (URL) context;
>>>     }
>>>     return null;
>>> }
>>> I can no longer display NASA JPL - I am getting a service returned to the
>>> effect:
>>> <!ELEMENT ServiceExceptionReport (ServiceException*)>
>>> <!ATTLIST ServiceExceptionReport version CDATA #FIXED "1.1.1">
>>> <!ELEMENT ServiceException (#PCDATA)>
>>> <!ATTLIST ServiceException code CDATA #IMPLIED>
>>> The stack trace indicates we are making a WMS 1.0 GetMap request - and it
>>> looks like from the result above that a 1.1.1 GetMap is expected
>>> at
>>> org.geotools.data.ows.ServiceExceptionParser.parse(ServiceExceptionParser.java:51)
>>> at org.geotools.data.ows.Response.parseException(Response.java:76)
>>> at org.geotools.data.ows.Response.<init>(Response.java:51)
>>> at
>>> org.geotools.data.wms.response.GetMapResponse.<init>(GetMapResponse.java:42)
>>> at
>>> org.geotools.data.wms.WMS1_0_0$GetMapRequest.createResponse(WMS1_0_0.java:288)
>>> at
>>> org.geotools.data.ows.AbstractOpenWebService.internalIssueRequest(AbstractOpenWebService.java:425)
>>> at org.geotools.data.wms.WebMapServer.issueRequest(WebMapServer.java:408)
>>> at
>>> net.refractions.udig.catalog.internal.wms.WMSServiceImpl$CustomWMS.issueRequest(WMSServiceImpl.java:376)
>>> at
>>> net.refractions.udig.render.internal.wms.basic.BasicWMSRenderer2$3.run(BasicWMSRenderer2.java:464)
>>> This seems like pretty crazy changes; does anyone have more details on
>>> what was done last week?
>>> Jody
>>> On 25/07/2009, at 1:48 AM, Jody Garnett wrote:
>>>
>>> I am going to assume this is an ID change from last week? I cannot get
>>> any of the same WMS / WFS or WMS-C servers to work on the "Web" view.
>>>
>>> Moovida tried on linux; I tried on mac.
>>>
>>> Jody
>>>
>>>
>>> _______________________________________________
>>> User-friendly Desktop Internet GIS (uDig)
>>> http://udig.refractions.net
>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>
>>
>
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>


Back to the top