RMI og pakker

Undskyld...Exceptionen er følgende:

java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
    java.lang.ClassNotFoundException: server.HelloImpl_Stub (no security manager: RMI class loader disabled)
    at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
    at pakke.HelloClient.main(HelloClient.java:16)
Caused by: java.lang.ClassNotFoundException: server.HelloImpl_Stub (no security manager: RMI class loader disabled)
    at sun.rmi.server.LoaderHandler.loadClass(Unknown Source)
    at sun.rmi.server.LoaderHandler.loadClass(Unknown Source)
    at java.rmi.server.RMIClassLoader$2.loadClass(Unknown Source)
    at java.rmi.server.RMIClassLoader.loadClass(Unknown Source)
    at sun.rmi.server.MarshalInputStream.resolveClass(Unknown Source)
    at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
    at java.io.ObjectInputStream.readClassDesc(Unknown Source)
    at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Unknown Source)
    at java.io.ObjectInputStream.readObject(Unknown Source)

Det er korrekt.

Jeg anbefaler normalt mindst 3 pakker:
  en med de server specifikke klasser
  en med de client specifikke klasser
  en med de delte klasser

Laes evt. http://www.eksperten.dk/artikler/225

Fejlen skyldes at du ikke har nogen security manager i din client og at client
derfor ikke vil downloade klasser fra server.

Du boer overveje en security manager - af sikkerheds hensyn.

Download af klasser fra server anbefales af SUN, men jeg har altid fundet det
nemmere at distribuere faelles klasserne til client.

Ovennaevnte artikel kommer som sagt ind paa en del af disse emner.

ok...det er da en stor ulæmpe hvis man ønsker en ordentlig softwarearkitektur...øv...tak for hjælpen :)
Smid et svar og du får point

Er det korrekt at du mener at det er lettere selv at søge for distributionen af klasse-filerne istedet for at bruge Dynamic Classloading?

tigtly coupled protokoller som RMI, EJB eller .NET remoting kraever nogle
klasser/interfaces som er kendt paa baade client og server

loosely coupled protokoller som f.eks. web services (SOAP over HTTP) behoever det ikke

----

svar

----

Ja. Det er nemmere. Og jeg har aldrig set det store formaal med den dynamiske
loading.

Jeg må indrømme at jeg godt kan se fordelen ved dynamic classloading, hvis man har mange clienter og man f.eks. laver en ændring i den klasse der står for implementeringen af det fælles interface's metoder. Det er jo denne klasse stubben bliver lavet udfra, og dermed ville en ændring i denne klasse jo kræve at man lavede en ny stub, som så skulle overføres manuelt til alle klienterne. Med Dynamic classloading sker denne overførsel jo automatisk.
Men det er selvfølgelig klart at Dynamic classloading ikke løser problemmet hvis interfacet bliver ændret f.eks. ved tilføjelse af nye metoder.

Det er rigtigt.

Men i de fleste tilfaelde bruges RMI paa intranet, hvor man har muligheder for at
distribuere til alle virksomhedens PC'ere.

Og selv over internet er der jo f.eks. Java Web Start.

Men det er kun min mening. SUN bruger dynamisk classloading i alle deres
eksempler. Saa der er absolut ogsaa andre synspunkter.

:) jeg er enig i at RMI er bedst egnet til intranetbrug, hvilket jo selvfølgelig letter distribueringen af de ændrede filer...hvis ellers alle virksomhedens PC'ere er tilstede når dette sker :)
Tak for snakken og hjælpen!