Read configuration file in the bundle [message #93340] |
Mon, 30 July 2007 17:01  |
Eclipse User |
|
|
|
Hi all,
I've read in Knopflerfish forum that it's possible to read a config file,
that it's compressed in the bundle, with the following code:
FileInputStream is = (FileInputStream)
getClass().getResourceAsStream("/cfg/file.properties");
where the bundle structure is:
/META-INF
MANIFEST.MF
/cfg
file.properties
"CLASSES"
However, I'm using Equinox and the previous sentence always returns null.
Perhaps it's because I'm debugging with Equinox and the .JAR file (of the
bundle) is not generated yet? (I don't think so).
How could I read a file inside my bundle?.
Thanks,
Jaime
|
|
|
|
|
|
|
|
|
|
Re: Read configuration file in the bundle [message #93730 is a reply to message #93656] |
Wed, 01 August 2007 15:44  |
Eclipse User |
|
|
|
> Besides, I disagree with the Bundle.getEntry. I try to develop my code as
> much independent as possible, and Bundle binds that part of the code to
> OSGi. So I prefer the use of ResourceStream.
>
OK, that is a fine reason. I would suggest that you place the
configuration resource in the same source folder as your code. In your
example it seemed like your config file was at the root of your bundle
and your code was in an inner library jar which was included on the
Bundle-ClassPath. Since '.' was not on the classpath your code could
not find the resource.
As a best practice bundles should try not having any inner jars and
place all their code at the root of the bundle so that the default '.'
Bundle-ClassPath can be used. Inner jars have a number of draw backs.
For example, if you deliver your bundle as a jar'ed bundle then the
inner jar must be extracted at runtime to load classes. Currently
PDE/JDT/javac cannot handle inner jars in jar'ed bundles when compiling
clients that use packages exported by your bundle. If your bundle is
always delivered as an "expanded" bundle then this is not such an issue.
Note that "expanded" bundles are not really standard in OSGi but are
supported in Equinox for backwards compatibility reasons and for
self-hosting in a development environment.
Tom
|
|
|
Powered by
FUDForum. Page generated in 0.03897 seconds