hivemind-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Davies (JIRA)" <hivemind-...@jakarta.apache.org>
Subject [jira] Created: (HIVEMIND-203) Location should be Serializable
Date Thu, 22 Mar 2007 16:39:32 GMT
Location should be Serializable
-------------------------------

                 Key: HIVEMIND-203
                 URL: https://issues.apache.org/jira/browse/HIVEMIND-203
             Project: HiveMind
          Issue Type: Improvement
          Components: framework
    Affects Versions: 1.1.1
            Reporter: Chris Davies
            Priority: Minor


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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message