My idea to put
LocalSessionFactory in with
RmiSessionFactory didn't work out quite as I'd planned. The classes associated with
RmiSessionFactory were to be found in server-rmi-base-1.1.0.jar, which was really the wrong place to put the local session factory classes. So I made sure that server-local-1.1.0.jar was included everywhere that server-rmi-base-1.1.0.jar was. However, this still didn't prevent the
I tried placing this jar into numerous places without any luck, so in the end I started putting the
LocalSessionFactory classes into different jars. This didn't work either. I spoke to various people who ought to have known, but no ideas were forthcoming. I guess this explains why TJ wants to change the classloader framework!
Finally, I was frustrated enough to jut put it all in server-rmi-base-1.1.0.jar. This eliminated the
ClassNotFoundException, and left me with an exception relating to unknown transaction phases.
At this point I took a step back to re-examine what I was trying to do.
When the original code needed a session factory, it would always get an
RmiSessionFactory, which wrapped a
RemoteSessionFactory, which wrapped a local session factory. The local session factory is configurable, but at this stage it is always a
Database object (
Database meets the
SessionFactory interface). So if I wanted to avoid RMI altogether, all I needed to do was get hold of a
Database object, just like
Database object is a single object created by
EmbeddedKowariServer (well, it's actually created by the
EmbeddedKowariServer creates). The
RmiServer class uses
EmbeddedKowariServer to find this object, and gives it to the
RemoteSessionFactory constructor. So if I wanted to use a local session factory, all I should need to do would be to get it from
I tried this, and again it didn't work. This time the exceptions all said "Unable to commit", and the database files had not even been created on the disk. I discussed this with DM, but we were unable to work out exactly what was happening. All I can guess is that the
RmiServer somehow initialized the database before using it for the first time, but I couldn't see where that happened.
I'd now made it to the end of the day, with very little progress. At this point I realised that about the only thing I was trying to do was to avoid using RMI with descriptors. All other "clients" would occur in another JVM and RMI couldn't be avoided anyway. So it seemed reasonable to use RMI for descriptors as well.
To do this I just needed to change the test in
RMISessionFactory so that it would ignore connections to the current server if the URL for the server was exactly the URL used to find the server. This is safe, as the looping bug only occurs when connecting to a server using a name that the server is not familiar with.
Once this was done I set the tests running, and crossed my fingers that all would be well. I'm guessing that something will go wrong, but hopefully I'm converging on the solution.
Tuesday, November 30, 2004