You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jaxme-dev@ws.apache.org by Dean Hiller <de...@xsoftware.biz> on 2005/09/14 15:11:24 UTC
Re: classloader problems & coming solution
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 <de...@xsoftware.biz> 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: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: SAX Exceptions fix
Posted by de...@xsoftware.biz.
if I remember correctly, the xml parser catches all RuntimeExceptions and
hides them. I will verify tonight hopefully. Thus catching a
RuntimeException around the parse method is code that will never be
executed. I will verify and send a fix in for my particular case where I
got a useless exception, and the real exception was lost(ie. not chained)
thanks,
dean
> dean@xsoftware.biz wrote:
>
>> } 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;
>> }
>
> I understand the rationale, but I really do believe that catching
> RuntimeExceptions can be done by the XML parser at a single place (in
> XMLReader.parse(...)) and thus should be done there. In other words, my
> opinion is not to add such exception handlers.
>
> However, note the following: The JaxMe generated sources should *not*
> throw RuntimeExceptions, but generate parse events. In other words, if
> your RuntimeException comes out of generated code, then that code ought
> to be changed.
>
>
> Jochen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: SAX Exceptions fix
Posted by Jochen Wiedmann <jo...@gmail.com>.
dean@xsoftware.biz wrote:
> } 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;
> }
I understand the rationale, but I really do believe that catching
RuntimeExceptions can be done by the XML parser at a single place (in
XMLReader.parse(...)) and thus should be done there. In other words, my
opinion is not to add such exception handlers.
However, note the following: The JaxMe generated sources should *not*
throw RuntimeExceptions, but generate parse events. In other words, if
your RuntimeException comes out of generated code, then that code ought
to be changed.
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
SAX Exceptions fix
Posted by de...@xsoftware.biz.
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 <de...@xsoftware.biz> 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: jaxme-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: jaxme-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org