Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Need to over ride default OS file.separator without changing the code base

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Prod code runs on UNIX, but need to run local DEV on windows.

The current code gets a path in UNIX format from a DB then builds on that path using file.separator which adds windows separators causing the ftp to fail as path for target is formatted incorrectly. ex: /incoming/ri-etl\DEV\Rulebooks/tate_rbid_1715_retest

/incoming/ri-etl from a DB setting
\DEV\Rulebooks built in code using file separator.

Since other team uses MAC OS for Dev they do not see the issue locally. Tried to over ride the path.separator using -DFile.Separator=\/ (and other variations) in Tomcat ARGS, JAVA_OPTS and CATALINA OPTS with no success.

I think if I can force the UNIX format Windows will accept it and FTP will work. FTP will not accept a path all built in the WINDOWS format.

I am running TOMCAT from within ECLIPSE (TOMCAT 8, Java 7, Eclipse MARS).

Any ideas?
 
Saloon Keeper
Posts: 21127
131
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can immunize your applications from OS file-naming dependencies with this one simple trick:

Use java.io.File.

Typically, when I have an uploaded file folder, I define its path as a JNDI property so that I can inject it externally. In Tomcat, that's easily done as an Environment element in the context.xml file. I then use JNDI in the application code to retrieve the symbolically-named folder path and use it to create a File object representing the base directory for uploads. Something vaguely like this:


Notice that at no time did I have to know or care what OS I was running under or what the directory/file path syntax was.

Incidentally, Java will accept Windows paths in Unix-style syntax, such as "C:/workdir/uploadedFile") and I do recommend using that style since it keeps you from getting zapped by mismatched backslashes. In some cases, Windows itself will even accept that syntax. However the one thing that Java is very insistent on is proper use of upper and lower case. Even though Windows doesn't care, resources will not match up properly in Java code if you don't capitalize properly.
 
Barb Switzer
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We are just inheriting this code and the code works ine in MAC OS and UNIX but not on windows. We only need to change
for our local DEv environment. As such, the existing team does not want us to change code that will go to prod for a DEV
environment issue. This is why I am trying to override withotu a code change.
 
Tim Holloway
Saloon Keeper
Posts: 21127
131
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I developed for quite a few years using XP as my development machine, deploying to Solaris (and later Linux) for production machines. By employing a proper application design, not only did I not have to hack anything for filesystem paths, I produced WARS that would run without any modification on Dev (local Windows), Test (data-center Beta) and Production (data-center production), even though they used different filesystems and different databases.

I'd be a lot more concerned about a situation where production was being hurt than developers. The developers are presumably going to be modifying code anyway.

However, that;s jsut be being my usual arrogant obnoxious self. There's a more critical reason why hacking the filesystem separator property is a Bad Idea.

The webapps aren't the only part of the system using the system property set. Tomcat itself does. If you mess with Tomcat's understanding of the filesystem you can destabilize Tomcat's internals really quickly.

I would go back and take a closer look at those "bad paths", though. Java can - and does - normally deal with schizoid paths in forms like "C:\Program Files\myapp/tempfiles/file1.txt" all the time. Java.io.File doesn't usually normalize backslashes. Meaning that your "separator" problem may actually be a bug-in-the-app problem.
 
CAUTION! Do not touch the blades on your neck propeller while they are active. Tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!