external jars with xml parsers break AVK
Running avk with an ear that references external 3rd party jars would involve placing the said jars in the lib/ext folders and updating the jar's manifest.mf files with the references.
This works fine with libraries that dont have xml parsers within them.
For example, try putting Oracle's XML Parser V2 in the lib/ext folder and watch AVK die a miserable death.
Does anyone have any idea how to circumvent this problem?
Cheers,
Ryan
Has anyone ever encountered this problem ? Is there something grossly wrong with this scenario?
Hi,
It is a difficult scenario. Let me try to understand the exact problem to be able to certainly say whether it would work or not.
> Running avk with an ear that references external 3rd
> party jars would involve placing the said jars in the
> lib/ext folders and updating the jar's manifest.mf
> files with the references.
>
> This works fine with libraries that dont have xml
> parsers within them.
> For example, try putting Oracle's XML Parser V2 in
> the lib/ext folder and watch AVK die a miserable
> death.
>
1) Are you getting this problem during static verification or during dynamic verification?
2) Can you supply the exception stack trace or error message, if any?
3) If you are doing dynamic verification, then placing a parser in lib/ext might not work because JVM's extension class loader may not have access to load all the classes that an XML parser may need. Let me warn you that overriding the XML parser by a thirdparty parser is a tricky issue and may not work very well in all application server.
4) If you are doing static verification, I am not sure why you have to place Oracle's parser in lib/ext? Are you using the APIs of the said parser as opposed to using JAXP interfaces in your code?
Thanks,
Sahoo
> Does anyone have any idea how to circumvent this
> problem?
>
> Cheers,
> Ryan
Here are the answers
1) Are you getting this problem during static verification or during dynamic verification?
. Static
2) Can you supply the exception stack trace or error message, if any?
.. might not be needed (look at the answer to question4)
3) If you are doing dynamic verification, then placing a parser in lib/ext might not work because JVM's extension class loader may not have access to load all the classes that an XML parser may need. Let me warn you that overriding the XML parser by a thirdparty parser is a tricky issue and may not work very well in all application server.
. Not applicable
4) If you are doing static verification, I am not sure why you have to place Oracle's parser in lib/ext? Are you using the APIs of the said parser as opposed to using JAXP interfaces in your code?
. Good catch. It appears that the code does use a hardcoded import.
However, is there any way one can run the avk without having to include jars like classes12.jar ldapxx.jar in the .ear or the lib/ext? Would definitely appreciate some suggestions on this
Thanks for your response Sahoo.
-Ryan
> Here are the answers
> 4) If you are doing static verification, I am not
> sure why you have to place Oracle's parser in
> lib/ext? Are you using the APIs of the said parser as
> opposed to using JAXP interfaces in your code?
> . Good catch. It appears that the code does use a
> hardcoded import.
Static verification in AVK does not look for import statements because imports are not present in .class files. Unless imported class is used in code, that class need not be present when static verification is done.
> However, is there any way one can run the avk
> without having to include jars like classes12.jar
> ldapxx.jar in the .ear or the lib/ext?
Would
> definitely appreciate some suggestions on this
>
Unfortunately, answer is NO. Your understanding is very correct.
You will get failures if a referenced class is not available to AVK. If the referenced class is part of a library, then options are:
1) bundle the library inside the ear file and use class-path manifest entry.
2) place the library in lib/ext.
There is an additional restriction as to what kind of jar files can be placed in lib/ext. If a library depends on classes which are not available in JDK's rt.jar, then all the additional classes referenced by that library must also be made availabe in lib/ext.
> Thanks for your response Sahoo.
You are very welcome. I am very sorry for the late reply.
Cheers,
Sahoo
> -Ryan
