[jcifs] no chance to run jcifs_0.7.0b7

[Michael B. Allen]

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
users anymore.

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.