I just want to add a comment on the dl-jar files, for people on the list who might be new to Jini. See comments below:
On Tue, 2008-12-09 at 00:07, Niclas Hedhman wrote: > > 3. I like modularization. Jini is quite good, and hat of to the Sun > team who manage to keep the architectural structure as nice as it is > even though it sits in s single codebase tree. I have started to break > things out into separate modules. Still more to do. > > 4. I have not tackled the -dl.jar issue yet. IMHO, I would have them > as separate Maven modules, as then the dependency for clients become > crystal clear. We need to be very clear here; the clients don't have a dependency on the dl-jar. The download jar file is the file that a service makes available so that proxies and supporting classes can be dynamically loaded when a service is accessed. It is service's codebase, in other words. Remember that mobile code is a key part of Jini; that's how we get the protocol-agnosticism. The client should only know about the interfaces to a service, and possibly data transfer objects (but only when the DTO's are stable enough that they can be widely distributed to clients for development-time use). Under no circumstances should a client have a copy of the dl-jar in its classpath. I usually create a third jar for the client (e.g. some-service-api.jar or some-esrvice-client.jar) that contains only the interfaces and data transfer objects. This jar can go in the client's classpath. The practice of Sun's Jini group has been to use the ClassDepAndJar tool to create a single '-dl.jar' file for an associated set of service instances. My practice in Harvester has been to explicitly add the download jars to the exported service's codebase annotation, generating multiple jars in the codebase. One problem is that the preferred classloader mechanism only looks in the first jar file on the downloaded codebase classpath so it only works with Sun's single-download-jar approach. I've been planning to have Harvester automatically combine the codebase jars, but have so far avoided the need for the preferred classloader mechanism. So to summarize, a Jini service module will usually generate three jar artifacts: (1) the service's actual code (some-service.jar), (2) the codebase (some-service-dl.jar) jar, and (3) the api jar (some-service-api.jar or some-service-client.jar). I would expect the codebase to be a subset of the code, and the api to be a subset of the codebase, but I wouldn't guarantee it. In addition, there might be a file containing suggested configuration entries for either the service, client, or both. Cheers, Greg. -- Greg Trasuk, President StratusCom Manufacturing Systems Inc. - We use information technology to solve business problems on your plant floor. http://stratuscom.com
