[jcifs] no chance to run jcifs_0.7.0b7
Michael B. Allen
miallen at eskimo.com
Tue Nov 12 06:47:36 EST 2002
On Mon, 11 Nov 2002 12:56:04 +0100
andrea.lanza at frameweb.it wrote:
> then I followed debugging the source of jcifs.smb.Handler.: I reached again
> the last line
> setURL( u, "smb://", u.getHost(), getDefaultPort(),
> u.getAuthority(), u.getUserInfo(),
> u.getPath(), u.getQuery(), u.getRef() );
> So I discovered that my NoSuchMethodError depends on u.getAuthority()
> method that does not exists.
> But also other elements do not exist ( u.getAuthority(), u.getUserInfo(),
> u.getPath(), u.getQuery()) !
> Besides, setURL method is not implemented, so I think it comes from
> URLStreamHandler. But the method from the lattest class accept only 6
> argouments, not 9 !
Oooooohhhhhhhhh. You're using Java 1.1. The reason why I didn't use
java.net.URL from the beginning was because Java 1.1 was missing critical
URL parsing functionality. So I wrote my own parsing funcitons. Prior
to jcifs-0.7.0b4 we supported Java 1.1. This is no longer true. There
was a very small debate about this and no one seemed to be concerned so
we made the leap to the Java 2 java.net.URL. After checking CHANGES.txt
it does not appear that I meantioned this anywhere. There were so many
other changes it just slipped my mind. We don't see a lot of Java 1
Sorry, but there's nothing you can do about this. You'll have to use
jcifs-0.7.0b3 or less. I believe you said you're just trying to write a
"browser servlet"? 0.6.7 should work just fine for that. There are a
few URL bugs (hence the changes and Java 2 requirement) but nothing you
couldn't work around I think. See the Sept 26 news bullet for details.
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