Re: Services and packaging dependencies

Hi Patrick,

Patrick Wright wrote:

> 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.

That is too rigorous but very safe, I would say never throw an exception
over the wire for which you don't know what its content can be. For
example JNDI naming exceptions sometimes contain references to a naming
context which can't be serialized.

Likely you will find out about these cases when it is too late, so it
often better to transform internal exception into one that is part of
the service API and log the internal exception and throw your own type.
Depending on your knowledge of the internal exception you might include
it as the cause as it might be convenient to have that one at the client.

>
> 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.

Besides the fact that this will increase the download JAR file in a
massive way, it ain't a guarantee that you will be able to serialize the
  exception itself due to the exception containing context information
that is not serializable in the first place.

> 3) Be dilligent about tracking down dependencies.

Something you should always do :-) What you can do to ease dependency
tracking is adding constructors to your exceptions that take a cause
that has the exact type of the exception, but this can become tedious
and you still must be aware about certain libraries subclassing
particular exceptions for whatever reason.

> 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.

My rule of thumb is to only throw those exceptions that are part of the
Platform, i.e. certain Jini specifications and J2SE 1.4 and those that
are defined as part of my service API and to leave out those that can be
problematic such as javax.naming.NamingException. Internal exceptions
are not propagated by default but in most cases transformed into an API
exception and logged at the service level. Note that in most cases a
client can't do anything meaningful with the cause.

I realize it is sometimes handy when a client reports a stacktrace to
you and you have the cause at hand, but what you can do is to generate a
ticket (Uuid) for each exception transformed and include that ticket
number in the message for the transformed exception and log the ticket
number also as part of the logging for your service, that way you can
easily correlate a thrown exception with the cause.

Hope this helps,
--
Mark

--------------------------------------------------------------------------
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]