6

I need to pass the property file's URI to the following method (3rd party jar)

    defaultConfiguration = Factory.createDefaultConfiguration(propertiesUrl.toURI());
PayClient client = Factory.createClient(defaultConfiguration);

When I deploy my code on server, I get this path i.e. propertiesUrl.toURI() as abc://localhost/server/test/payment/ConfigLookup.properties

The 3rd party application refuses this value and doesn't create the configuration which is used to create a connection client.

A sample code where the property file is in my local bin folder works fine when passed on.

Path received as propertiesUrl.toURI()

file:/D:/Code/bin/ConfigLookup.properties

The above creates a successful connection.

Kindly guide me on what's missing between them. How to make the server code work in similar fashion as the local code works.

user2967948
  • 529
  • 2
  • 8
  • 23
  • What is the "abc:" scheme? – matt freake Dec 18 '15 at 10:26
  • It's actually the server where we deploy the code. Post deployment, it looks like say projectname(which I named as abc):://localhost/server/test/payment/ConfigLookup.properties – user2967948 Dec 21 '15 at 12:00
  • It' is not clear what "refuses this value" means, Is there some sort of error message or is the config simply not being loaded. Does the 3rd party jar do any logging? Can you get any logging from it that might provide more clues as to what it is looking for? – Steve Cohen Dec 28 '15 at 22:00

2 Answers2

1

Apparently that 3rd party JAR expects a local disk file system based URI. This is actually a mistake on their side. It's possible to obtain the contents via uri.toURL().openStream() without worrying about the context the URI is actually sitting in. The refusal of the value suggests that the 3rd party is using new FileInputStream(new File(uri)) for that. First and foremost, this should be reported on their side so they can properly fix it.

In the meanwhile, your best bet is to convert it to a local disk file system based URI instead offering a virtual file system or web based URI. You can do that by creating a temporary file with help of File#createTempFile() in container managed temporary folder, writing the contents to it and finally provide the temp file as URI.

Below example assumes that you're inside a servlet and thus have getServletContext() already at hands. Otherwise, the Java EE based framework you're using must have facility to give/inject you the ServletContext.

String tempDir = (String) getServletContext().getAttribute(ServletContext.TEMPDIR);
File tempFile = File.createTempFile("temp-", ".properties", new File(tempDir));
Files.copy(propertiesUrl.openStream(), tempFile.toPath(), StandardCopyOption.REPLACE_EXISTING);
// ...
defaultConfiguration = Factory.createDefaultConfiguration(tempFile.toURI());

That said, are you absolutely sure that this properties file shouldn't rather be placed in /WEB-INF folder? Right now it's publicly accessible to anyone in the world having a webbrowser. See also a.o. Where to place and how to read configuration resource files in servlet based application?

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
0

You can get the resource via classloader and then for the file the URI, see here for details.

Community
  • 1
  • 1
hecko84
  • 1,224
  • 1
  • 16
  • 29
  • I did get the resource, however it looks like abc://localhost/server/test/payment/ConfigLookup.properties which the 3rd party jar doesn't accept as a valid URI. – user2967948 Dec 18 '15 at 08:56