Re: [Ikvm-developers] Problem with VSTO Excel Project loading Java XMLparsing libraries

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Thanks Jeroen for the prompt reply. 

I will do like you suggested and will let you know if it worked.

Thanks Again.
Shailesh 

-----Original Message-----
From: Jeroen Frijters [mailto:je...@su...] 
Sent: Thursday, October 07, 2010 12:32 AM
To: Londhe, Shailesh; ikv...@li...
Subject: RE: [Ikvm-developers] Problem with VSTO Excel Project loading Java XMLparsing libraries

Hi,

This looks like the standard class loader problem. When running inside Excel there is no meaningful system class loader (and there can't be, as you could be sharing Excel with several other IKVM based plug-ins).

If the Java code doesn't explicitly use the system class loader, you should be able to get it working by using the -sharedclassloader ikvmc option and compile all jars at once:

ikvmc -sharedclassloader { a.jar } { b.jar } { c.jar } ...

Now of b.jar tries to load a resource or class using its own class loader, it will be able to find any class in either a, b or c.

However, it is also possible that the Java code uses the system class loader or the thread class loader. Both of these can also be set (using the standard Java mechanisms).

Regards,
Jeroen

> -----Original Message-----
> From: Londhe, Shailesh [mailto:sha...@ba...]
> Sent: Wednesday, October 06, 2010 9:20 PM
> To: ikv...@li...
> Subject: [Ikvm-developers] Problem with VSTO Excel Project loading 
> Java XML parsing libraries
> 
> Hi,
> 
> 
> 
> I have been using IKVM build 0.40.0.1 to convert a proprietary Java 
> based messaging framework library into a .NET assembly (a dll). Let's 
> call it "productA.dll". Everything goes fine; I can see all required 
> java types from that framework. This framework now internally uses 
> Java Spring xml files for their configuration. The DLL is actually 
> built from a bunch of huge jar files which have lot of spring xml 
> files embedded in them. I can successfully connect to this framework's 
> Java services and do my work, but only from a .NET Application like a 
> console app or a Winforms App. I use VS2008 with 3.5 .NET framework using C#.
> 
> 
> 
> My goal is to be able to do the same thing within an Excel worksheet. 
> So I tried creating an Excel 2007 Workbook project using "Visual 
> Studio tools for Office".  I want to be able to use the same code that 
> I wrote in my working Winforms application to connect to that 
> messaging framework. But it always fails while parsing XML config 
> files. This is during the time when the ThisWorkbook_Startup() 
> function is being executed. Following is the exception I get 
> (stacktrace is quite big I have just posted a part of it):
> 
> 
> 
> org.xml.sax.SAXParseException: schema_reference.4: Failed to read 
> schema document 
> 'http://www.springframework.org/schema/beans/spring-beans-
> 2.0.xsd', because 1) could not find the document; 2) the document 
> could not be read; 3) the root element of the document is not <xsd:schema>.
> 
>                  at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXP
> ar
> seException(ErrorHandlerWrapper.java:198)
> 
>                  at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.warning(Er
> ro
> rHandlerWrapper.java:99)
> 
>                  at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(X
> ML
> ErrorReporter.java:384)
> 
>                  at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(X
> ML
> ErrorReporter.java:322)
> 
>                  at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.repor
> tS
> chemaErr(XSDHandler.java:2547)
> 
>                  at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.repor
> tS
> chemaWarning(XSDHandler.java:2536)
> 
>                  at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getSc
> he
> maDocument(XSDHandler.java:1844)
> 
>                  at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parse
> Sc
> hema(XSDHandler.java:534)
> 
>                  at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(
> XM
> LSchemaLoader.java:555)
> 
>                  at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.findSche
> ma
> Grammar(XMLSchemaValidator.java:2411)
> 
>                  at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleSt
> ar
> tElement(XMLSchemaValidator.java:1756)
> 
>                  at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startEle
> me
> nt(XMLSchemaValidator.java:688)
> 
> 
> 
> 
> 
> I also noted that Excel VSTO project always loads all IKVM dlls and my 
> "productA.dll" from another location, which is it does due to the 
> "shadowcopy" which is inbuilt in all VSTO projects. And there is no 
> way to turn it off (as per MSDN). The differences I found between an 
> Excel project and a regular .NET winforms/console project is that, the 
> winforms project always loads the Apache's Xerces XML parser. While 
> the excel project somehow doesn't do that and loads the Sun's internal 
> XML parser. This was seen in the log file which my framework logs when 
> it does the startup before it connects.
> 
> 
> 
> So from Winforms app: the loading of parser is àUsing JAXP provider 
> [org.apache.xerces.jaxp.DocumentBuilderFactoryImpl]
> 
> 
> 
> And from Excel VSTO: the loading of the parser is à Using JAXP 
> provider 
> [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl]
> 
> 
> 
> Other than that there are no differences in the log files in both 
> scenarios. The excel project immediately throws the above exception 
> after it starts using the DocumentBuilderFactoryImpl class to parse 
> the spring config files. I am still not able to figure out why this 
> happens and why does the default Parser gets overridden when I use 
> EXCEL VSTO to load my dll and other IKVM dll's.
> 
> 
> 
> I have tried using CustomClassLoaders instead of using IKVM.runtime 
> classloaders in C# to break into the callback functions like 
> findResource(), getResource() which Java uses to load classes, I 
> haven't found any clue there.
> 
> 
> 
> Can anyone throw any light on this? Has anyone encountered a similar 
> problem before? I could not find anything related in mail archives 
> hence the question posted here.
> 
> 
> 
> Thanks in Advance.
> 
> 
> 
> Shailesh
> 
> ________________________________
> 
> This message w/attachments (message) is intended solely for the use of 
> the intended recipient(s) and may contain information that is 
> privileged, confidential or proprietary. If you are not an intended 
> recipient, please notify the sender, and then please delete and 
> destroy all copies and attachments, and be advised that any review or 
> dissemination of, or the taking of any action in reliance on, the 
> information contained in or attached to this message is prohibited.
> Unless specifically indicated, this message is not an offer to sell or 
> a solicitation of any investment products or other financial product 
> or service, an official confirmation of any transaction, or an 
> official statement of Sender. Subject to applicable law, Sender may 
> intercept, monitor, review and retain e-communications (EC) traveling 
> through its networks/systems and may produce any such EC to 
> regulators, law enforcement, in litigation and as required by law.
> The laws of the country of each sender/recipient may impact the 
> handling of EC, and EC may be archived, supervised and produced in 
> countries other than the country in which you are located. This 
> message cannot be guaranteed to be secure or free of errors or viruses.
> 
> References to "Sender" are references to any subsidiary of Bank of 
> America Corporation. Securities and Insurance Products: * Are Not FDIC 
> Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank 
> Deposit * Are Not a Condition to Any Banking Service or Activity * Are 
> Not Insured by Any Federal Government Agency. Attachments that are 
> part of this EC may have additional important disclosures and 
> disclaimers, which you should read. This message is subject to terms 
> available at the following link:
> http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender 
> you consent to the foregoing.

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.