RE: translator plugin classloader issues

[Ashok Hariharan]

Luca,

I am having a strange problem with the translator ... the problem
seems to be related to the way Xerces has been used in the translator
...

I noticed that it is not invoked using JAXP but rather Xerces has been
used directly ... and since Xerces is also used by the editor ... this
leads to all kinds of classloader related exceptions as the JVM tries
to instantiate a second Xerces while one has already been loaded by
the editor class-loader ... This means i have to use a threadcontext
class loader ... or use a special classloader to run the translator in
its own classloader space (with its own classpath etc...)

There are 2 possible solutions ... either downgrade to Xerces 2.6 or
switch to using JAXP as the interface for accessing the Xml parser ...

Do you have any other ideas / suggestions ?

Ashok

[Luca Cervone]

Dear Ashok, 

Actually I didn't have a problem like this before. 

The problem is that I have to use the XERCES processor because of the validation that SAXON do not support in the free version. 

So I think that you have to implement the better solution for the editor. Only you can know what it is. 

Another issue. I tried to use the file given to the extractor (that one containing the section and the ids) as a parameter of the translate method.

I think that it is not a good solution. That's because the translator class is linked to an interface shared also with the AKNtoHMTL translator (that do not require a sections file). 

So, the better way to use that is to ask produce the sections file at run time (i think that the validation class can do it) but I need to have the extractor library as a simple java library instead of a runnable application. 

Can you give it to me? 

Thanks 

Luca 

Luca Cervone

Web and XML solutions designer

e-mail:     cervo...@gmail.com

  luca.c...@unibo.it

lcer...@cs.unibo.it

mobile phone:    0039 348 26 27 545

home   phone:  0039 051 199 82 854

skype:   cervoneluca

[Ashok Hariharan]

On Tue, May 12, 2009 at 11:44 AM, Luca Cervone <cervo...@gmail.com> wrote:
> Dear Ashok,
> Actually I didn't have a problem like this before.
> The problem is that I have to use the XERCES processor because of the
> validation that SAXON do not support in the free version.
> So I think that you have to implement the better solution for the editor.
> Only you can know what it is.

You wouldnt have this problem because the unit-tests for the
translator are run in isolation independent of an external calling
application.

I am testing a custom post-operative url-classloader for integratiung
the translator now ... so it loads the translator in a different
classpath space than the editor ....

this will most probably work ... at least according to the simple test
cases i have done... it just means we have to package the translator
with its own libraries -- and load them independently of the main
application (the editor). the only limitation could be we cannot be
able to share complex objects between the editor and the translator
(which we are not doing at the moment anyway)

> So, the better way to use that is to ask produce the sections file at run
> time (i think that the validation class can do it) but I need to have the
> extractor library as a simple java library instead of a runnable
> application.

Sure i can ... let me just repackage it slightly and upload it into svn.

Ashok