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

[Paul Gearon]

Actually, that's what they're already doing.

The problem is code like this:

    try {
      FullTextStringIndex stringIndex =
getFullTextStringIndex(((LocalNode)modelElement).getValue());
      return new FullTextStringIndexTuples(stringIndex,
(LuceneConstraint)constraint, resolverSession);
    } catch (IOException ioe) {
      throw new QueryException("Failed to open string index", ioe);
    } catch (FullTextStringIndexException ef) {
      throw new QueryException("Query failed against string index: ", ef);
    } catch (TuplesException te) {
      throw new QueryException("Failed to query string index", te);
    }

Now it's perfectly fine to throw a QueryException (we handle that at
the client end), but notice how it chains the exception that caused
it? This gets serialized, but at the client end there is no way to
deserialize it.

The way I'm going to deal with it now is to just convert the initial
exception to a string, and add it to the message.

Paul

On Wed, Aug 19, 2009 at 3:53 PM, Dragisa Krsmanovic<dkrsmanovic at plos.org> wrote:
> 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
>
> _______________________________________________
> Mulgara-dev mailing list
> Mulgara-dev at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-dev
>