Services and packaging dependencies

Hi

I'm pretty new to Jini (< 6 months), am about to deploy our first
service. I ran into a problem during testing last week and would like
feedback on how others approach this problem.

The situation was that the service I'm accessing uses JavaMail. I was
running a test where I failed to pass in a BCC address, and the
service, not expecting a blank BCC, tried creating an InternetAddress
for it, which failed. It failed, in fact, with an AddressException.

Now, the method declared throwing a MessagingException, which is a
superclass to various JavaMail exceptions. That made sense at the
time, because a number of other JM methods in the method body throw
MessagingException itself, not a subclass (or at least don't declare
that they throw a subclass).

To round this out, on calling this method (withing the service) and
catching any MessagingException, I was wrapping it in my own
EmailException (as cause), and re-throwing EmailException from the
service.

The end result, however, was that AddressException had never been
packaged for download, since a dependency scan never picked it up.
MessagingException and EmailException were in the downloadable jars. I
got a serialization failure when executing the method, since the
actual class wrapped inside the EmailException was AddressException,
unknown as a downloadable resource.

We were asking ourselves the best policy/strategy in this case. Three
options came to mind
1) Never pass any class over the wire that isn't your own, or isn't in
the JDK. That includes never wrapping exceptions that aren't your own.

2) If using a third-party library, like JavaMail, include the entire
library JAR as a downloadable resource; you never know when you'll
need it.

3) Be dilligent about tracking down dependencies.

The short-term solution is just to not  wrap the AddressException, but
rather to capture the exception message. We would like, of course, to
avoid this problem entirely, since in the worst case, having to add a
missing class as downloadable at runtime may require a service
restart.

I'm pretty sure that others must have addressed this so far. This
particular case (unexpected subclass) was new to us in the testing
we've done so far.


TIA
Patrick

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]