Sorry Mirko, but I think it's not a problem of me making bad paths. I mean,
this is the code I have that DOES load the .properties from a relative path:
*URL entry = bc.getBundle().getEntry(".");
if (entry != null)
{
URLConnection connection = entry.openConnection();
if (connection instanceof BundleURLConnection)
{
URL fileURL = ((BundleURLConnection) connection).getFileURL();
URI uri = new URI(fileURL.toString());
path = new File(uri).getAbsolutePath();
System.out.printf("This is the path: %s\n", path);
}
}* //then make the load(), ...
It works on Eclipse, but not outside it. The code you passed me just writes
the path eclipse is working on, but what I need is to pass a .jar to another
client and load the .properties WITHOUT knowing in what path he will put the
.properties file. The only thing he needs is to put the .properties and the
.jar in the same folder, don't know if I explain.
Anyway, thanks for all,
Asier
On 1 February 2010 14:36, Mirko Jahn <[email protected]> wrote:
> For what it's worth, if it seems to work within Eclipse but not
> outside of it and you're using relative paths... Most likely you're
> path is just wrong. Just print out the path you're in:
>
> System.out.println("Dir: "+new File(".").getAbsolutePath());
> or
> System.out.println("Dir: "+System.getProperty("user.dir"));
>
> This should be different in the two scenarios you described. Fix your
> path I ensure you, it'll work.
>
> Cheers,
> Mirko
>
> On Mon, Feb 1, 2010 at 11:28 AM, Neil Bartlett <[email protected]>
> wrote:
> > Asier,
> >
> > What you asked for was a way to read a file that is external to the
> > classpath. FileInputStream gives you that. Of course the file must
> > exist on the filesystem of the machine on which the bundle ends up
> > running. Ensuring it exists is something you must handle -- since I
> > have no idea of your environment, build system, deployment
> > methodology, etc.
> >
> > For what it's worth, your use-case (user-modifiable, external
> > configuration data) is exactly what the OSGi Configuration Admin
> > service is intended for, and furthermore Apache FileInstall gives you
> > a nice front-end for Config Admin. But you insist that you don't want
> > to deploy any other bundles, so...
> >
> > Regards,
> > Neil
> >
> > On Mon, Feb 1, 2010 at 10:11 AM, Asier Aranbarri Beldarrain
> > <[email protected]> wrote:
> >> Hi Neil:
> >>
> >> I can load any file with FileInputStream but it certainly doesn't work
> when
> >> I export the bundle (except if I declare an static path). What I need is
> to
> >> export the .jar, put the .properties in the same folder as the .jar, and
> >> load from there. And I cannot get it with FileInputStream , really. I
> may be
> >> doing something wrong but I tested (almost) everyway with that method.
> >>
> >> Thanks,
> >>
> >> Asier
> >>
> >> On 1 February 2010 10:58, Neil Bartlett <[email protected]> wrote:
> >>>
> >>> Asier,
> >>>
> >>> FileInputStream certainly does work for loading files outside the
> >>> classpath. It can be used to read any file in the filesystem (subject
> >>> to the O/S security policy, of course). I recommend reading JavaDocs.
> >>>
> >>> Neil
> >>>
> >>> On Mon, Feb 1, 2010 at 9:51 AM, Asier Aranbarri Beldarrain
> >>> <[email protected]> wrote:
> >>> > Hi Miguel:
> >>> >
> >>> > I have an issue with that solution; I need to send just two things,
> the
> >>> > bundle (bundleX.jar) and a config.properties file, just that. With
> the
> >>> > file
> >>> > install, wouldn't I need another .jar?
> >>> >
> >>> > Hi Jean:
> >>> >
> >>> > I don't understand that solution(sorry, newby here). Should I
> implement
> >>> > that
> >>> > code in the META-INF? How could I load it from the .java classes?
> >>> >
> >>> > Hi Neil:
> >>> >
> >>> > NewFileInputStream, getResourceasStream, ... don't work to load files
> >>> > from
> >>> > outside the classpath. They do work inside Eclipse-Equinox, but not
> when
> >>> > you
> >>> > export the .jar. I tested them all, I think:
> >>> >
> >>> > - propertiesFile.load(new
> >>> > FileInputStream("/config/BD.properties"));
> >>> > - InputStream is =
> >>> > ConfigIni.class.getResourceAsStream("/config/BD.properties");
> >>> > - InputStream is=
> >>> > this.getClass().getResourceAsStream("/BD.properties");
> >>> >
> >>> > But they just load dinamically inside Eclipse.
> >>> >
> >>> > Thanks,
> >>> >
> >>> > Asier
> >>> >
> >>> > On 1 February 2010 10:41, Jean-Baptiste Onofré <[email protected]>
> wrote:
> >>> >>
> >>> >> Hi Neil,
> >>> >>
> >>> >> The FileInputStream() usage is correct too. I simply focus on
> another
> >>> >> way
> >>> >> to do it using blueprint :)
> >>> >>
> >>> >> Regards
> >>> >> JB
> >>> >>
> >>> >> Neil Bartlett wrote:
> >>> >>>
> >>> >>> Sorry if I am missing something obvious, but what is wrong with
> "new
> >>> >>> FileInputStream(...)" ?
> >>> >>>
> >>> >>> Neil
> >>> >>>
> >>> >>> On Mon, Feb 1, 2010 at 9:12 AM, Asier Aranbarri Beldarrain
> >>> >>> <[email protected]> wrote:
> >>> >>>>
> >>> >>>> Hi everyone:
> >>> >>>>
> >>> >>>> I need to load a config.properties file from outside an osgi
> bundle
> >>> >>>> and
> >>> >>>> I'm
> >>> >>>> having real issues getting it. The .properties MUST be outisde the
> >>> >>>> classpath, since it must be modified by the user( put user and
> >>> >>>> password
> >>> >>>> from
> >>> >>>> mysql) and then read from the bundle (bundle.jar).
> >>> >>>>
> >>> >>>> I have no problem loading from outside with an static path or a
> >>> >>>> dynamic
> >>> >>>> path
> >>> >>>> INSIDE eclipse. But when I try to load it dinamycally from the
> >>> >>>> eclipse-independent osgi, I cannot read the file.
> >>> >>>>
> >>> >>>> Is there any way to load a file outside the classpath with a .jar?
> I
> >>> >>>> repeat
> >>> >>>> that the .properties MUST be outside the classpath. Static paths
> >>> >>>> don't
> >>> >>>> do
> >>> >>>> the work for me since I am forcing the user to put in an specific
> >>> >>>> location
> >>> >>>> and that's not acceptable(also, he's on linux and I on windows, so
> >>> >>>> the
> >>> >>>> path
> >>> >>>> C:\ ... doesnt work).
> >>> >>>>
> >>> >>>> Thank you very much,
> >>> >>>>
> >>> >>>> Asier
> >>> >>>>
> >>> >>>> _______________________________________________
> >>> >>>> OSGi Developer Mail List
> >>> >>>> [email protected]
> >>> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >>> >>>>
> >>> >>> _______________________________________________
> >>> >>> OSGi Developer Mail List
> >>> >>> [email protected]
> >>> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >>> >>
> >>> >> _______________________________________________
> >>> >> OSGi Developer Mail List
> >>> >> [email protected]
> >>> >> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > OSGi Developer Mail List
> >>> > [email protected]
> >>> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> >>> >
> >>>
> >>> _______________________________________________
> >>> OSGi Developer Mail List
> >>> [email protected]
> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >>
> >>
> >> _______________________________________________
> >> OSGi Developer Mail List
> >> [email protected]
> >> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >>
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > [email protected]
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> >
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
