Mailing-List: contact dev-help@hivemind.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hivemind.apache.org
Message-ID: <18634332.1174581572359.JavaMail.jira@brutus>
Date: Thu, 22 Mar 2007 09:39:32 -0700 (PDT)
From: "Chris Davies (JIRA)" <hivemind-dev@jakarta.apache.org>
To: hivemind-dev@jakarta.apache.org
Subject: [jira] Created: (HIVEMIND-203) Location should be Serializable
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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.