[jcifs] RE: Lots of jCIFS stuff

Michael B Allen mba2000 at ioplex.com
Sat May 24 08:41:15 EST 2003


On Fri, 23 May 2003 eglass1 at attbi.com wrote:

> The attached fix manually parses the response code (rather than relying on
> getResponseCode()), which should hopefully fix the issue you are seeing.  I'm
> not sure which exact revision you're running, but "java -version" should tell
> you.

I'll merge this code into 0.7.7 with the deadlock fix and the other
little tidbits that came up in the past few weeks.

> Also, in some older revisions keep-alives were broken as well (disconnecting
> on 400+, rather than when the server explicitly indicated such).  I have tested
> against 1.3.1_03, and it appears to work properly.  This wouldn't be an issue
> connecting to the jCIFS servers (since we don't require a persistent
> connection), but would be when connecting to IIS (since they do).  There isn't
> too much we could do about this without actually implementing a full-blown
> HttpURLConnection implementation.

Can you put together a simple html page that describes this functionality
and it's limitations like those you mention here? Don't make anything
fancy. Just concise and to the point. A few paragraphs. Something like
the very plain pages I have about pipes, exception handling, and so
on. I know it's a pain but minimal documentation is really really helpful
and it annoys me when I try to use an something that's under-documented
(like GNU mailmain).

> > Do those 5 classes need to be in the jcifs.smb package? I can publicise the
> > get*NtlmResponse() methods. Perhaps we should create a jcifs.ntlmssp package?
> 
> They are only in the jcifs.smb package because they require the
> get*NtlmResponse() stuff.  I would concur with this recommendation; they don't
> really belong in jcifs.smb.

Do you have a preference for the package name? Does it seem reasonable
that a JGSS provider might eventually go in this package? If so I think
jcifs.ntlmssp is still reasonable.

> Also (on a completely unrelated note) NtlmHttpServletRequest should probably
> override getAuthType() to return "NTLM" -- don't know why I didn't notice
> that previously.

I don't feel comfortable adding anything that hasn't been tested a
little. Can you try it and post the code?

Thanks,
Mike

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived. 




More information about the jcifs mailing list