Details
-
Improvement
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
1.1.1
-
None
-
None
Description
It'd be very useful for org.apache.hivemind.Location to extend java.io.Serializable, since it's used in some HiveMind exceptions. As a result, it's not possible to serialize some of the HiveMind exceptions, which can cause problems.
One major problem that I can see with making this change is that Location holds a Resource and not all Resource implementations are necessarily Serializable (e.g. ClasspathResource, which holds a ClassResolver, which holds a ClassLoader). A work-around may be updating exceptions to store a SerializableLocation, which holds a ResourceDescription, which simply describes a resource, rather than providing access to it. The disadvantage of that is that you lose a lot of the advantages that Resource gives us in terms of accessing the resource... but then, do we really need to access the resource from an Exception handler? Chances are we only need to know information about the resource - i.e. a description. In this case, a ResourceDescription suffices.
Of course, the big advantage is that we can use HiveMind exceptions in fancy/distributed error-reporting systems. In my case, I'm catching exceptions thrown by Tapestry pages and publishing events through JMS to notify "reporter" services (which then report exceptions - one by SMS text message, one by e-mail, etc.). It's very useful for these reporter services to have access to the Throwable that was thrown inside the Tapestry page.
For now, I'll battle on by modifying the object published through JMS to only include Strings (exception class name, exception message, root cause class name, root cause message and full stack trace), but it'd be really useful if this could get changed somehow in the future. 
Cheers.
- Chris