-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cris,
On 3/10/17 2:02 PM, Berneburg, Cris J. - US wrote: > Chris > > Thanks for taking the time to help me out. I appreciate it. > Sorry, my response is kinda wordy. :-P > >> If you really REALLY want a file path, you could use the >> catalina.base system property or the tmpdir and go from there. >> The former is Tomcat-specific, of course, and the tmpdir would >> be *anywhere*, but if you just really REALLY need a path on the >> disk, you could get it from there. > > Aha! Yes, that could work. It will work, but it's going to suck. :( >>> Also, maybe I'm not asking the right question. How do you all >>> configure the location of a special folder that is not part of >>> the deployment package itself? A site-specific config file >>> perhaps? >> >> Well-known location like /etc/myapp/config.cfg? Well-known >> configuration URL like >> https://internal-config.myapp.com/config.cfg? > > Actually it's Windows. Also, the config file should live in a > folder that is (1) obvious and (2) we have access to. > >>> Currently I'm using getRealPath for a relative-path location >> [SNIP] >> >> If the file can be bundled with the WAR file (which would be >> best), then you should get >> ServletContext.getResource("/path/rooted/in/the/WAR/file/config.cfg") . > >> >> > Unfortunately it's a site-specific configuration, meaning the > value for the setting may be different for each environment, so it > really cannot be bundled as-is. The file would need to be tweaked > before starting the webapp. > > Well, I suppose it could be bundled if, after deploying the > webapp, we extracted the config file, modified it for the current > location, and then reinserted it into the WAR file... But that > sounds like a lot of work and not what you intended anyway. ;-) > Actually, that's exactly how we handle other custom settings, only > without using a WAR file. It's clumsy, and I wish there were a > better way of doing it. So instead of having to tweak the > configuration after every deployment, we would only do it 1x for > the first time the application is installed. That would be great. That's super-ugly. Better to have an external configuration file. That supports the Principle of Least Surprise[1]. > I'm not sure I understand how to configure a custom resource or am > even grasping the concept. Can the resource (config file > location) be defined in the application context web.xml? If so, > wouldn't it already be too late since that would mean the config > file is already bundled with the application? Unless the location > of the config file in the resource definition can be expressed as > an OS-path (not virtual) to point outside of the webapp's home. I would use a well-known location for the file. Maybe the application can be installed anywhere, but the config file needs to be in %APPDATA%\YourCompany\YourProduct\config.properties Would that be okay? Or are you saying that you need to do things like configure the JNDI DataSource that would usually be in context.xml? > Guess I could explain it better. It's a custom report-generation > engine. A template file is read by a library, processed, dumped > to an output file, then served to the client. There is a folder > with template input files and another folder with the output > files. Neither of those are in the WAR, right? Obviously, not the output files, but what about the input templates? > Based on what you and Chuck said, it looks like the input > templates can be claimed as Resources. Since the library can accept > a java.io.InputStream, then the input templates could be included > in a WAR file, if we used one. Be specific when you use a term like "Resources". That has a special meaning to Tomcat, and actually multiple meanings depending upon the context. Which did you mean, here? You can certainly include the templates in the WAR file, but I suspect that one of your features is clients being able to build their own templates? > However, the output folder needs to live outside a WAR file, and > we need a non-virtual way of specifying the folder (an actual OS > path) so the library can write the output there. AND we currently > don't use a WAR file. But we could, provided the config file issue > can be taken care of. If so, how do you resolve a virtual path to > a resource outside the WAR file since it's outside the package > "folder" structure of the WAR? To WAR or not to WAR, that isn't really the question. But you should always work as if you were confined to a WAR file. To directly answer your question about translating virtual paths to real paths, the answer is "you can't (at least not reliably)". > Hence the use of getRealPath, so all this configuration juggling > can simply be bypassed. > > I feel like I'm stuck in a "which came first, the chicken or the > egg" loop. I would go for a well-known-location and just tell your customers "the config file has to go HERE". Maybe you could have a number of locations that you check in order. If there's one somewhere special, you use that one. If you don't find it, use a backup, all the way back to the one bundled with the application. If you are always on windows, you can use the Preferences API (yuck) which will store your information in the Windows Registry. > -- Cris Berneburg CACI Lead Software Engineer Are you in Arlington, VA? - -chris [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYwwegAAoJEBzwKT+lPKRYqEoP/ikYBtaOEvuH9JchIKo1e4Np NA5532ivfbfue304m4IvDIhEo4twJWS2mXTw27wJ6WA8fVWhrbmu37ZcZl3FIHPt WJirwq3VczpIJ6oF7dTDAQge6c/WZlaNZrXEDogN9zwHq3wXbMqlj2ygyIU2vd24 jtnSKotm9BxkQrafgcaMg4bkj17YtjRZUa58fObNm+mk4FSOiyKzYXpl7t0XGw+3 Ed+1eY3JgIpaf/8+g+z845YCgaQ8//L1udCyjISlUd90urRxw2Hhs80k/qkyX9J5 8JUX+aVfAqtpkJTJP2Y4eHNGLth8qhrDXrNOeIpWUoznsb0lNpv2rU3Sa/JdneHP CozYaXAtqrVSpxmD3eb0OVc0gFHfna0n4ih4dSUjhmb75z3uK3HBpMbnX0VCdWpP 7XPlpcmsJWfrKLefyAArZLJYZ2bil+3aURKNXH9eewPeP+GT3tRNYD7ehet0P4BQ zWpdpDxNzkI96FfKkGQ9evJ7F+aXmBV00B+uk5azX8C6xxjgGzzHSzlAYl6Pwm0g XKxsKM1yLW60W8JTenuya4/8gukbc7JNogf/rldosYybxvrnbF2IBC1hBejSP0+L y0J3DRZqxAwMOXDrMNWfuYd2czYJVxFwDWb1VvTby2pWwRERolJgCbVlafdzO5i0 xsK5FMuPD7AbjJMg7oF6 =gIVf -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
