Re: [Ikvm-developers] scanning jars for class files
Brought to you by:
jfrijters
|
From: Jeroen F. <je...@su...> - 2013-02-14 15:48:34
|
Hi Brian,
The resource jar is a real jar (attached as a .NET resource to the assembly). It would be too expensive to synthesize a jar with all the stub classes at runtime, so the classes live in the virtual file system as individual files.
As a workaround you could use the ikvmc -resource: option to manually add all the required classes as resources.
Something like this:
ikvmc -resource:com/nomura/unity/refdata/fingalmapper/Foo.class=<path to foo.class>
You probably want to use a response file (@filename) if you have a lot of classes.
Regards,
Jeroen
> -----Original Message-----
> From: bri...@no... [mailto:bri...@no...]
> Sent: Thursday, February 14, 2013 16:30
> To: Jeroen Frijters; ikv...@li...
> Subject: RE: scanning jars for class files
>
> Hi Jeroen-
>
> Thanks for your quick response!
>
> I believe that this IS what Spring is doing. Stepping through the code,
> I see that Spring is iterating over the entries in a jar located at
> c:/.virtual_ikvm_home/assembly/...
>
> Spring is essentially doing this:
> ((JarURLConnection)resource.getURL().openConnection()).getJarFile()
> .entries().
>
> The URL is:
> {jar:file:/C:/.virtual-ikvm-
> home/assembly/fingalmapper.Lib/resources/fingal-mapper-1.0.0-
> SNAPSHOT.jar!/com/nomura/unity/refdata/fingalmapper/}
>
> The entries I see in the jar contain all the dirs and all the non-class
> files, but not the classes. Is it that the classes are synthesized on
> demand only when requested explicitly by name, meaning that jar scanning
> for classes will always fail in IKVM, or am I doing something wrong?
>
> BTW, sorry about the legal clause. It gets added automatically by the
> mail server and I cannot stop it. :(
>
> Thanks,
> Brian
>
>
>
> -----Original Message-----
> From: Jeroen Frijters [mailto:je...@su...]
> Sent: Thursday, February 14, 2013 1:51 AM
> To: Ross, Brian (IT/US); ikv...@li...
> Subject: RE: scanning jars for class files
>
> Hi Brian,
>
> The classes are not in the "jar", but they are synthesized (on demand)
> when they are requested as resources or when the virtual file system
> directory for that assembly is enumerated.
>
> There is no switch to include the classes in resources jar, but I've
> considered it.
>
> I don't know anything about Spring, but maybe it can be persuaded to
> look at the virtual file system directory instead?
>
> BTW, it's considered very bad etiquette to post to an open source
> mailing list with such a ridiculous confidentiality clause.
>
> Regards,
> Jeroen
>
> > -----Original Message-----
> > From: bri...@no... [mailto:bri...@no...]
> > Sent: Thursday, February 14, 2013 1:42
> > To: ikv...@li...
> > Subject: [Ikvm-developers] scanning jars for class files
> >
> > Hi-
> >
> > I am calling Java code from .Net which creates a Spring
> > AnnotationConfigApplicationContext. What Spring does here, is open up
> > the relevant jar files and iterate over their entries to find all
> > class files (after which it loads those classes to look for relevant
> > annotations). When running through IKVM, Spring fails to find any
> > entries. It appears that the jar files included in the assembly don’t
> > actually include the class files, although they are certainly in the
> > source jar I fed to ikvmc. Is there any way to get ikvmc to include
> > the class files (or at least stubs sufficient to allow their presence
> > to be recognized)?
> >
> > Thanks,
> >
> > Brian
> >
> >
> > PLEASE READ: This message is for the named person's use only. It may
> > contain confidential, proprietary or legally privileged information.
> > No confidentiality or privilege is waived or lost by any
> mistransmission.
> > If you receive this message in error, please delete it and all copies
> > from your system, destroy any hard copies and notify the sender. You
> > must not, directly or indirectly, use, disclose, distribute, print, or
> > copy any part of this message if you are not the intended recipient.
> > Nomura Holding America Inc., Nomura Securities International, Inc, and
> > their respective subsidiaries each reserve the right to monitor all e-
> > mail communications through its networks. Any views expressed in this
> > message are those of the individual sender, except where the message
> > states otherwise and the sender is authorized to state the views of
> > such entity. Unless otherwise stated, any pricing information in this
> > message is indicative only, is subject to change and does not
> > constitute an offer to deal at any price quoted. Any reference to the
> > terms of executed transactions should be treated as preliminary only
> > and subject to our formal written confirmation.
>
>
> PLEASE READ: This message is for the named person's use only. It may
> contain confidential, proprietary or legally privileged information. No
> confidentiality or privilege is waived or lost by any mistransmission.
> If you receive this message in error, please delete it and all copies
> from your system, destroy any hard copies and notify the sender. You
> must not, directly or indirectly, use, disclose, distribute, print, or
> copy any part of this message if you are not the intended recipient.
> Nomura Holding America Inc., Nomura Securities International, Inc, and
> their respective subsidiaries each reserve the right to monitor all e-
> mail communications through its networks. Any views expressed in this
> message are those of the individual sender, except where the message
> states otherwise and the sender is authorized to state the views of such
> entity. Unless otherwise stated, any pricing information in this message
> is indicative only, is subject to change and does not constitute an
> offer to deal at any price quoted. Any reference to the terms of
> executed transactions should be treated as preliminary only and subject
> to our formal written confirmation.
|