[Mulgara-dev] ClassNotFoundException on client for org.mulgara.resolver.lucene.FullTextStringIndexException

Dragisa Krsmanovic dkrsmanovic at plos.org
Wed Aug 19 20:53:17 UTC 2009


If resolvers would throw ResolverException(s) instead of defining their
own, would that solve the problem ?


On Wed, 2009-08-19 at 15:41 -0500, Paul Gearon wrote:
> I've just been looking in the code, and it's not throwing
> FullTextStringIndexException. The issue is that the exception being
> thrown is chained to a FullTextStringIndexException.
> 
> I can't think of any way to prevent that, except to only allow
> exceptions that can't chain to be thrown. That's not such a great
> idea, in that there are a number of useful things that are also being
> chained, and these are all available in the classpath (e.g.
> IOException and TuplesException).
> 
> So I'll have to get into the documentation for resolvers (it's about
> time this made it into the wiki anyway) and post a warning about
> making sure that chained exceptions can be deserialized by a client.
> 
> Paul
> 
> On Wed, Aug 19, 2009 at 1:54 PM, Dragisa Krsmanovic<dkrsmanovic at plos.org> wrote:
> > On Wed, 2009-08-19 at 13:03 -0500, Paul Gearon wrote:
> > ...
> >> > So, either we have to include lucene resolver
> >> > classes in driver.jar or lucene resolver should throw more generic
> >> > exceptions.
> >>
> >> I think that it should use more generic exceptions. We could enforce
> >> this by creating a "final" ResolverException, and specifying that all
> >> the resolver methods can only throw that.
> >
> > Yes, creating a generic ResolverException exception is better solution
> > than having to include all resolver classes.
> >
> > --
> > Dragisa Krsmanovic
> > Java Developer
> > Public Library of Science
> > http://www.plos.org
> >
> >
> > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > This email is confidential to the intended recipient. If you have received it in error, please notify the sender and delete it from your system. Any unauthorized use, disclosure or copying is not permitted. The views or opinions presented are solely those of the sender and do not necessarily represent those of Public Library of Science unless otherwise specifically stated. Please note that neither Public Library of Science nor any of its agents accept any responsibility for any viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any).
> >
> > _______________________________________________
> > Mulgara-dev mailing list
> > Mulgara-dev at mulgara.org
> > http://mulgara.org/mailman/listinfo/mulgara-dev
> >
> _______________________________________________
> Mulgara-dev mailing list
> Mulgara-dev at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-dev
-- 
Dragisa Krsmanovic
Java Developer
Public Library of Science 
http://www.plos.org




More information about the Mulgara-dev mailing list