Re: JAXB accesors: ClassLoader.defineClass

Jeroen Frijters <[email protected]>
Newsgroups gmane.comp.java.ikvm.devel
Message-ID <[email protected]>
Hi Gerardo,

To keep the assembly file sizes down, the original .class files are not included as resources.

In 7.4 I included the ability to include individual .class files as resources, so if you're willing to invest the time you could try that out.

Here's an example from the ikvm build itself (where OpenJDK 7u40 uses the same trick to load a .class resource as a template for another class):

  -resource:sun/reflect/misc/Trampoline.class=/openjdk-7u40-b34/jdk/src/share/classes/sun/reflect/misc/Trampoline.class

Regards,
Jeroen

> -----Original Message-----
> From: Gerardo Lastra [mailto:[email protected]]
> Sent: Tuesday, March 25, 2014 9:39
> To: Jeroen Frijters
> Cc: [email protected]
> Subject: Re: [Ikvm-developers] JAXB accesors: ClassLoader.defineClass
> 
> Hi Jeroen,
> 
> Thank you for the quick reply. You're right. JAXB is loading the .class
> file as a resource previous to the defineClass call. More specifically,
> in the AccessorInjector#tailor method:
> 
>     private static byte[] tailor( String templateClassName, String
> newClassName, String... replacements ) {
>         InputStream resource;
>         if(CLASS_LOADER!=null)
>             resource =
> CLASS_LOADER.getResourceAsStream(templateClassName+".class");
>         else
>             resource =
> ClassLoader.getSystemResourceAsStream(templateClassName+".class");
>         if(resource==null)
>             return null;
> 
>         return
> ClassTailor.tailor(resource,templateClassName,newClassName,replacements)
> ;
>     }
> 
> But doesn't IKVM redirect resources to the JAR file? For example, when
> loading a WSDL I've seen things like:
> INFO: Creating Service {http://blah/blah}Blah_v1 from WSDL:
> jar:file:/C:/.virtual-ikvm-home/assembly/my-assembly/resources/my-
> assembly.jar!/some.wsdl
> 
> Kind regards,
> Gerardo
> 
> 
> On Mon, Mar 24, 2014 at 7:07 PM, Jeroen Frijters <[email protected]
> <mailto:[email protected]> > wrote:
> 
> 
> 	Hi Gerardo,
> 
> 	I think that JAXB is trying to load a .class file from an ikvmc
> compiled assembly and that doesn't really work, because the .class file
> generated by the IKVM runtime is a stub, not the real class.
> 
> 	I'm not sure how to solve this. If the code assumes that .class
> files can always be loaded as a resource, then it isn't really
> compatible with ikvmc (at least, without any manual tweaking).
> 
> 	Regards,
> 	Jeroen
> 
> 
> 	> -----Original Message-----
> 	> From: Gerardo Lastra [mailto:[email protected]
> <mailto:[email protected]> ]
> 	> Sent: Monday, March 24, 2014 17:38
> 	> To: [email protected] <mailto:Ikvm-
> [email protected]>
> 	> Subject: [Ikvm-developers] JAXB accesors: ClassLoader.defineClass
> 	>
> 	> Hi all,
> 	>
> 	> I'm doing some research on the possibility of running a Java SOAP
> WS
> 	> client (using Apache CXF and JAXB) on .NET through ikvmc. I've
> managed
> 	> to create the .dll so far, but when I'm starting the application
> (when
> 	> the JAXB content is starting), I get the following error (names
> 	> replaced):
> 	>
> 	> Mar 24, 2014 5:20:55 PM
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector
> 	> inject
> 	> WARNING: duplicate class definition bug occured? Please report
> this :
> 	> a/b/c/ThisIsAJaxbType$JaxbAccessorF_someField
> 	> java.lang.NoClassDefFoundError:
> 	> a/b/c/ThisIsAJaxbType$JaxbAccessorF_someField (type not found in
> my-
> 	> assembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null)
> 	>         at
> IKVM.NativeCode.java.lang.ClassLoader.defineClass1(Unknown
> 	> Source)
> 	>         at java.lang.ClassLoader.defineClass1(Native Method)
> 	>         at
> java.lang.ClassLoader.defineClass(ClassLoader.java:814)
> 	>         at
> java.lang.ClassLoader.defineClass(ClassLoader.java:656)
> 	>         at java.lang.reflect.Method.invoke(Method.java:597)
> 	>         at
> 	>
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java
> 	> :205)
> 	>         at
> 	>
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java
> 	> :85)
> 	>         at
> 	>
> com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(Acce
> 	> ssorInjector.java:89)
> 	>         at
> 	>
> com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(
> 	> OptimizedAccessorFactory.java:167)
> 	>         at
> 	>
> com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize
> 	> (Accessor.java:279)
> 	>         at
> 	>
> com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.<init>
> 	> (SingleElementLeafProperty.java:82)
> 	>         at
> 	> java.lang.reflect.Constructor.newInstance(Constructor.java:522)
> 	>         at
> 	>
> com.sun.xml.bind.v2.runtime.property.PropertyFactory.create(PropertyF
> 	> actory.java:124)
> 	>         at
> 	>
> com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImp
> 	> l.java:179)
> 	>         at
> 	>
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextIm
> 	> pl.java:515)
> 	>
> 	>  ... stacktrace continues.
> 	>
> 	> I think the problem is either JAXB is using the wrong ClassLoader
> when
> 	> defining the injected classes, or there's a problem in IKVM
> itself. Any
> 	> ideas?
> 	>
> 	> Thank you!
> 	> Gerardo
> 
> 


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.