[Ikvm-developers] Where to place a .properties file for an ikvm dll to read it?

[Watkins, Mark R.]

Hello IKVM Developers,



We're using ikvmc to use a Java library we've been given in an ASP.Net
2.0 web application. It works a treat! Well done and thanks for the
great tool.



Our only unknown at this stage is how to use a .properties file that
came with the library. We were given a jar file in a folder with a
config and lib folder, like this (some names have been changed):



MagicInterface\

config\

magic.properties

lib\

log4j-1.2.8.jar

MagicLibrary1.jar

MagicLibrary2.jar

MagicInterface.jar



Presumably if using the MagicInterface.jar file in a normal Java
environment it would read settings from config\magic.properties. We have
tried placing this magic.properties file in our ASP.NET solution in a
number of different places (~/, ~/config/, ~/bin/, ~/bin/config/), and
it isn't being read when we run our code.



Is there a standard way for us to deploy the .properties file in our
.Net solution so it will be read, or is there a way of using our
web.config file to set these settings?



Thanks for all the help,

Mark.

[Jeroen Frijters]

Hi Mark,

It's impossible to say. The mechanism to locate the properties file is specific to "MagicLibrary". You'd really have to ask them how they go about locating it.

If had to make a guess as to the location, I would have guessed ~/bin/config (assuming that MagicLibrary.dll is in ~/bin). However if MagicLibrary is also in the GAC that won't work, because then the GAC copy will be used.

You might also want to try using Process Monitor (from Sysinternals) to see where/if it is trying to load the properties file.

Regards,
Jeroen

-----Original Message-----
Sent: Friday, August 03, 2007 18:46
To: IKVM Developers
Subject: [Ikvm-developers] Where to place a .properties file for an
ikvm dll to read it?
Hello IKVM Developers,
We're using ikvmc to use a Java library we've been given in an ASP.Net
2.0 web application. It works a treat! Well done and thanks for the
great tool.
Our only unknown at this stage is how to use a .properties file that
came with the library. We were given a jar file in a folder with a
MagicInterface\
config\
magic.properties
lib\
log4j-1.2.8.jar
MagicLibrary1.jar
MagicLibrary2.jar
MagicInterface.jar
Presumably if using the MagicInterface.jar file in a normal Java
environment it would read settings from config\magic.properties. We
have tried placing this magic.properties file in our ASP.NET solution
in a number of different places (~/, ~/config/, ~/bin/, ~/bin/config/),
and it isn't being read when we run our code.
Is there a standard way for us to deploy the .properties file in our
.Net solution so it will be read, or is there a way of using our
web.config file to set these settings?
Thanks for all the help,
Mark.

...

[Michael Kay]

Post by Jeroen Frijters
It's impossible to say. The mechanism to locate the
properties file is specific to "MagicLibrary". You'd really
have to ask them how they go about locating it.

Isn't it likely that they search the classpath? What would be your advice if
that is the case?

Michael Kay
http://www.saxonica.com/

[Jeroen Frijters]

Post by Michael Kay

Post by Jeroen Frijters
It's impossible to say. The mechanism to locate the properties file

is

Post by Jeroen Frijters
specific to "MagicLibrary". You'd really have to ask them how they go
about locating it.

Isn't it likely that they search the classpath? What would be your
advice if that is the case?

I may be missing something, but I don't think it is likely they use the classpath, because that would either mean that the directory that contains the magic library jars is in there or that they parse the classpath themselves and try each directory in there.

Also, I would really consider it a bug if they use the classpath, there are many environments where code gets loaded in some other way.

If they do use the classpath, I suppose you could use System.setProperty("java.class.path", "...") to set a particular classpath to make it work. As long as you use the System.setProperty() API (instead of the IKVM specific app.config mechanism) it won't affect IKVM class loading (because the system class loader has already been constructed at that point).

Regards,
Jeroen

[b***@blumenfeld-maso.com]

Am I missing something, or are you suggesting that ClassLoader.getResource() is not functional in the IKVM runtime environment as a way to locate non-.class resource files? Its pretty common in many Java libs to search the classpath using this API.

Brian Maso

Sent via BlackBerry by AT&T

-----Original Message-----
From: Jeroen Frijters <***@sumatra.nl>

Date: Sat, 4 Aug 2007 13:15:38
To:Michael Kay <***@saxonica.com>,"'Watkins, Mark R.'" <***@snapon.com>,'IKVM Developers' <ikvm-***@lists.sourceforge.net>
Subject: Re: [Ikvm-developers] Where to place a .properties file for an ikvm
dll to read it?

Post by Michael Kay

Post by Jeroen Frijters
It's impossible to say. The mechanism to locate the properties file

is

Post by Jeroen Frijters
specific to "MagicLibrary". You'd really have to ask them how they go
about locating it.

Isn't it likely that they search the classpath? What would be your
advice if that is the case?

I may be missing something, but I don't think it is likely they use the classpath, because that would either mean that the directory that contains the magic library jars is in there or that they parse the classpath themselves and try each directory in there.

Also, I would really consider it a bug if they use the classpath, there are many environments where code gets loaded in some other way.

If they do use the classpath, I suppose you could use System.setProperty("java.class.path", "...") to set a particular classpath to make it work. As long as you use the System.setProperty() API (instead of the IKVM specific app.config mechanism) it won't affect IKVM class loading (because the system class loader has already been constructed at that point).

Regards,
Jeroen


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ikvm-developers mailing list
Ikvm-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ikvm

[Jeroen Frijters]

Post by b***@blumenfeld-maso.com
Am I missing something, or are you suggesting that
ClassLoader.getResource() is not functional in the IKVM runtime
environment as a way to locate non-.class resource files? Its pretty
common in many Java libs to search the classpath using this API.

I think you are missing something, we're talking about jars here. Having a jar on the classpath does *not* imply that ClassLoader.getResource() will load anything from the directory where the jar happens to live on the filesystem. Only from the jar itself.

In the same way, when you ikvmc compile something, resources will only be loaded from the assembly.

BTW, I did find out something, the "preferred" way of loading something from the location of a jar is broken in the OpenJDK Hybrid snapshots (but it works on the 0.34 release).

For those who are curious, here is what I think is the preferred way:

import java.io.*;
import java.net.*;

public class test {
public static void main(String[] args) throws Exception {
URL url = new URL(test.class.getProtectionDomain().getCodeSource().getLocation(), "test.properties"));
InputStream in = url.openStream();
...
}
}

This will work for individual class file on the classpath, for jars and for ikvmc compiled assemblies (as long as they aren't in the GAC).

Regards,
Jeroen

[Brian Maso]

Thanks Jeroen,

Follow-up question to the whole group then: in IKVMC-generated dlls
and exes, has anyone figured out a "good" way to handle properties
files that are supposed to be deployment-time editable, such as
log4j.properties, or similar config files used to affect the runtime
behavior of an app? These are files that:
1. Should be easily editable after deployment
2. Are generally located on the Java classpath

For example, let's say I use IKVMC to generate an EXE from a simple
HelloWorld.jar (which defines its main class):

ikvmc HelloWorld.jar

IKVMC will generate HelloWorld.exe for me. OK, so now let's say
HelloWorld.jar uses log4j. When using the Sun VM I would startup the
HelloWorld app with system properties and/or classpath settings and
include log4j.properties on the classpath somewhere.

I don't see how to set either system properties or add things to the
effective classpath for the IKVMC-generated HelloWorld.exe. Anyone
have any pointers?

Best Regards,
Brian Maso

Post by Jeroen Frijters

Post by b***@blumenfeld-maso.com
Am I missing something, or are you suggesting that
ClassLoader.getResource() is not functional in the IKVM runtime
environment as a way to locate non-.class resource files? Its pretty
common in many Java libs to search the classpath using this API.

I think you are missing something, we're talking about jars here.
Having a jar on the classpath does *not* imply that
ClassLoader.getResource() will load anything from the directory
where the jar happens to live on the filesystem. Only from the jar itself.
In the same way, when you ikvmc compile something, resources will
only be loaded from the assembly.
BTW, I did find out something, the "preferred" way of loading
something from the location of a jar is broken in the OpenJDK Hybrid
snapshots (but it works on the 0.34 release).
import java.io.*;
import java.net.*;
public class test {
public static void main(String[] args) throws Exception {
URL url = new
URL(test.class.getProtectionDomain().getCodeSource().getLocation(),
"test.properties"));
InputStream in = url.openStream();
...
}
}
This will work for individual class file on the classpath, for jars
and for ikvmc compiled assemblies (as long as they aren't in the GAC).
Regards,
Jeroen

...

[Michael Kay]

Post by Brian Maso
Follow-up question to the whole group then: in
IKVMC-generated dlls and exes, has anyone figured out a
"good" way to handle properties files that are supposed to be
deployment-time editable, such as log4j.properties, or
similar config files used to affect the runtime behavior of
an app?

In my case, the answer is "no", and I've always felt I must be missing
something. But it's partly because .NET doesn't seem to have a house-style
that one should be striving to emulate.

Michael Kay
http://www.saxonica.com/

[Jeroen Frijters]

Post by Brian Maso
I don't see how to set either system properties or add things to the
effective classpath for the IKVMC-generated HelloWorld.exe. Anyone have
any pointers?

You can set system properties by adding them to the app.config file:

HelloWorld.exe.config

<?xml version="1.0"?>
<configuration>
<appSettings>
<add key="ikvm:propertyname" value="propertyvalue" />
</appSettings>
</configuration>

Regards,
Jeroen

[Watkins, Mark R.]

Hi Jeroen, and everyone else who replied to this thread,

Thank you for your assistance - we learned a lot about the different
issues involved here from your replies.

We tried a few of the suggestions from a few of the emails (including
the marvelous app.config method), but Sysinternals Process Monitor as
suggested in this first reply answered all our questions: it isn't
loading the properties file at all; it seems content to read the
.properties file from inside the .jar file -
MagicLibrary.jar/config/magic.properties.

We have resigned ourselves to having to rebuild the jar file and ikvm
dll every time a configuration setting changes. We'll be trying to get a
sensible answer from the MagicLibrary developer about whether this
should really be the case.

All the best,
Mark.

-----Original Message-----
Sent: 04 August 2007 07:57
To: Watkins, Mark R.; IKVM Developers
Subject: RE: [Ikvm-developers] Where to place a .properties file for

an

ikvm dll to read it?
Hi Mark,
It's impossible to say. The mechanism to locate the properties file is
specific to "MagicLibrary". You'd really have to ask them how they go
about locating it.
If had to make a guess as to the location, I would have guessed
~/bin/config (assuming that MagicLibrary.dll is in ~/bin). However if
MagicLibrary is also in the GAC that won't work, because then the GAC

copy

will be used.
You might also want to try using Process Monitor (from Sysinternals)

to

see where/if it is trying to load the properties file.
Regards,
Jeroen