Right now, I am getting an exception that is caused by another exception
but the other exception is not chained in the exception.
I don't suppose it would be possible to fix the chaining of exceptions
out of XML Handlers. To fix this, in every startElement/endElement,
there has to be a try catch and the RuntimeExceptions(or checked ones
MUST be put in the initCause of the SAXParseException). The xml
engines don't chain for you and screw this up, but if you chain before
it gets to xml engine, xml engine will just pass it through.
} catch(RuntimeException e) {
//note: passing in cause exception to constructor does not work,
//use initCause instead which works.
SAXParseException ee = new SAXParseException("Error in file
being parsed:"+getCurrentLocation(), loc);
ee.initCause(e);
throw ee;
}
> yes, I know I will be non-JAXB compatible, but I should be very close(I
> don't have much of a choice, I have to be dynamic). Just two lines I
> call are not JAXB compatible. The methods I think I would like to add
> and am in process right now for doing the code and testing are
>
> public int register(String package, Classloader cl);
> public void unregister(int id);
>
> So, basically, the only place I am not JAXB compatible is these two
> methods.
>
> I will let you know when I am done and you can look at the code and give
> me your thoughts.
> thanks,
> dean
>
> Jochen Wiedmann wrote:
>
>>On 9/13/05, Dean Hiller <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>> unfortunately, every package is in a different classloader so I would
>>> need
>>>an array of classloaders as well as packages.
>>>
>>>
>>
>>No, you'd need a custom classloader. :-)
>>
>>
>>
>>
>>>Also, this is a very dynamic
>>>platform and the packages are not known ahead of time.
>>>
>>>
>>
>>That is of course a different matter and, as of yet, unsupported.
>>
>>Please note, that this is particularly unsupported by JAXB: You are
>> definitely
>>loosing portability by going this track.
>>
>>
>>
>>
>>>but JaxME looks like it
>>>was a nice enough design that I can just add a little and be off and
>>>running.
>>>
>>>
>>
>>That's true. The current design is definitely made for supporting
>>these things. However, allow me the following hint: Whenever I find
>>the time, I do plan to change the configuration system, for
>>performance reasons. In other words, it is likely that any work you
>>spend for customization now will at least partially need to be
>>reworked at some time in the next year.
>>
>>
>>Jochen
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
