Had this problems a few days can't seem to figure it out, I keep getting classnotfound or absractmethod errors.
Here's some code snippets and an overview of the problem I keep getting.
My remote marker interface
I get various versions of the following error dependant on what I am casting 2
If anyone could give me any pointers on where I am going wrong would be much appreciated.
Please take a look here. I think it will be helpful!
I was trying to not have references to my Data class in the remote interface and just have a RemoteService and RemoteServiceImpl, that has a book and search method and not a lot of other methods from say the DBAcess interface.
This is where my problems lies on return from the stub injection I cant cast from Services to Data
I could include DBAcess in my remote interface but am sure I can do this without having to do this, just haven't figured it out yet.
Here's a quote from a very old article by Ken Krebs who was also infulenced by the Spring framework: .
Choosing RMI seemed to be a total no-brainer as it is so simple compared to using sockets. My entire networking code compiles to only 5,408 bytes of code. It consists of 2 classes, RemoteServices and RemoteServicesImpl. RemoteServices is an interface that extends Services and Remote. It has no body. This is possible because all the Services methods throw IOException and can therefore also throw a RemoteException. It's a nice trick that keeps things simple. RemoteServicesImpl extends UnicastRemoteObject and implements RemoteServices. It has 2 parts, the implementation of RemoteServices (i.e. the 2 Services methods) and static getServices methods that allow the clients to get a Services instance that is either an RMI server for the Network Server application functionality or its stub for the Network Client application functionality. The Services method implementations simply delegate all work to the ServicesImpl singleton. Since all of the locking occurs in a single method call in the Network Server's JVM, there is no need to worry about the RMI connection dieing in the middle of a locking operation.
I am just trying to do this in A Spring like way, if that makes any sense and it giving me a headache at the moment because of the ClassCast problem
On the server side:
Your RemoteServicesImpl implements the Services interface either directly or through a helper. RMI provides a server side proxy (stub) that also implements the Services interface and delegates to the RemoteServicesImpl instance that you bound to the RMI registry. All communication via RMI from the client side goes through this proxy.
On the client side:
RMI provides a proxy against which you can make your Services method calls. This object is created by RMI is neither a RemoteServicesImpl or a Data object. The proxy object RMI provides can only be cast to Services. All communication via RMI to the server side goes through this proxy.
I leave it to you to figure out the rest. I don't want to spoil your fun.
FYI: You cannot use the following for the cert, but it can be useful afterwards.
Spring provides a nice Remoting technology that is a simple alternative to RMI called HttpInvoker. Essentially it provides Remoting via Java serialization over HTTP. Unlike RMI, it does not need a central registry, it only needs an HTTP port to serve. Another real plus for this is that since runs over HTTP, it is very firewall friendly, unlike RMI. This strategy, of course, only is useful when both the client and server are implemented using Java and Spring. You only need to write your service interface and its implementation as POJO's that have no knowledge whatsoever of any Remoting that is going on and don't have to handle any checked Exceptions.
Spring also maps RemoteExceptions to unchecked RemoteAccessExceptions making your code much easier to write. In fact it does this exception mapping for a number of other Remoting technologies as well as HttpInvoker.
Switching Remoting strategies is often as simple as tweaking 2 simple XML configurations, 1 on the server and 1 on the client.
I have changed things around but am still getting either a classcast or stub error. Here's my latest attempt at trying to solve this problem.
Sorry about showing so much code but hard to explain what I am trying to do without it.
If I cast to Services in Naming.lookup in RemoteServicesImpl then it wants getClient() in Services, yet haveing a cast to RemoteServices and doing getClient() does nothing. Could anyone please tell me if my design has a fatal flaw
Here's what I get from RMI when I dont try to call getClient() and just pass back the services value
Any suggestions on where I am going wrong would be greatly appreciated, thank you.
Thanks for the fast reply :lol:
Although your RemoteServicesImpl cannot be cast to Data, it can certainly delegate to an instance of Data to help it implement the Services interface.
Not really sure how I would delegate to Data from RemoteServicesImpl and do you mean within RemoteServicesImpl when creating the proxy or on return to the Services class.
I think this is the crux of the matter: I can't seem to get Data involved in the proxy, and on return can't call Data methods because of this and hence getting classcast exceptions.
Could you possibly give me a code example of what you mean by the above statement.
Any help would be greatly appreciated.
Server Start up:
Client Start up:
Connection set to database name on initial call but when I go back in from the client field this has been reset to null.
Only way I can see to get the database name is to call the saved configuration file and get the name from there. This doesn’t seem right to me but works when I do this. But I think then maybe I am violating the client/server relationship by accessing saved configuration from the client ?
If I look at the example from Andrew Monkhouse book he uses DVDDatabaseFactoryImpl in a similar way to set database name from server. And then uses the database name from client to set his connection. Have no idea why Andrews database name isn’t reset and mine is.
Anyone have any advice or pointers on this please
Kevin Florish wrote:Here's a quote from a very old article by Ken Krebs who was also infulenced by the Spring framework: .
Ken Krebs wrote: Networking
Choosing RMI seemed to be a total no-brainer as it is so simple compared to using sockets. My entire networking code compiles to only 5,408 bytes of code. It consists of 2 classes, RemoteServices and RemoteServicesImpl. ...
A bit off topic, but I am not sure I agree with the general assumption people make that RMI is so much easier than Sockets. You might be interested in looking at these two topics:
There are many valid reasons for going with RMI instead of Sockets (I really chose it for my assignment because I did not know RMI).
Having said in the 2 topics above that Sockets can be as simple as RMI, I went back and looked at the RMI and the Sockets package used in my book, and the stats don't look so good for my position:
So looking at the raw numbers it appears that my co-author wrote nearly twice as many lines of code for the Sockets solution versus the RMI solution.
It seems to me the that Sockets would be a good alternative if you need maximum performance or there's something you can't live with in RMI but you'll have to embed your own protocol, hence the extra work.
I actually don't use RMI much in my own work, preferring to use Spring's HttpInvoker (Java serialization over Http) as it's firewall friendly. We can't of course use that for the cert.