Bug in DataSource

[John Caron]

Ok, thanks for reminding me of the problem.

Im still not sure of the context, in the TDS, i just pass the HttpServletRequest and HttpServletResponse to you:

        ncfile = datasetSource.getNetcdfFile(req, res);

So presumably there's something in the resulting file that is a problem when being served by the TDS through OPeNDAP(??)

If so, can you try to capture that DDS and DAS and send them, or perhaps give me a hole in you firewall, or ???


Roland Schweitzer wrote:
> Hi John,
> 
> Sorry.  I'll use the support address in the future.
> 
> You'll recall that we were having this problem before when accessing my 
> data files via the IOSP layer directly.  James investigated here: 
> http://scm.opendap.org:8090/trac/ticket/841.  This problem was fixed by 
> you as noted in you 3.15 release notes:
> * opendap look for encoded chars in the CE (eg %20)
> 
> I assume this is the same problem, except in the case where the URL gets 
> treated via the DataSource plugin.  Your code peals off the OPeNDAP 
> constraint expression and does something with it and in this case what 
> it does must be different than when the IOSP is called directly.
> 
> Roland
> 
> 
> John Caron wrote:
>> Sorry, Roland, this one slipped through.
>>
>> BTW, if you send email to
>> support-netcdf-java at unidata.ucar.edu
>>
>> it goes into an issue tracker and is less likely (but still possible) 
>> to be ignored.
>>
>>
>> The main problem with answering these quickly is when I cant reproduce 
>> the problem. Then I have to think about it, and thats a limited 
>> resource :^(
>>
>> Anyway:
>>
>> ** unknown netCDF error code: -31
>> XAXLEVITR
>>
>> seems to be coming from the netcdf C library ?? I dont understand how 
>> that could come from the java library.
>>
>>
>>
>> Roland Schweitzer wrote:
>>> John,
>>>
>>> I'm getting ready to go to Seattle next week and meet with Steve and 
>>> the gang.  I mentioned a while back that I think there is a bug in 
>>> the DataSource implementation such that the OPeNDAP constraint 
>>> expressions don't get property decoded as they do for a request that 
>>> flows directly through to the IOSP.  I'd like to be able to report at 
>>> least that I've heard back from you on this topic even if it's to say 
>>> you think I'm all wet and you doubt there is a bug.
>>>
>>> Thanks,
>>> Roland
>>>