Comments (5)
This documentation from "behavior-configuration" seems to be incorrect:
The WEB-INF folder is the default location of the configuration.properties file, but you can define a new location by following these steps:
In WEB-INF/web.xml, find the following lines:
rdapConfigurationUserPath
Uncomment them, and write a valid directory path in param-value.
Save the changes and test the configuration.
First, because the "rdapConfigurationUserPath" is not commented, this doesn't seem to be valid XML. Secondly, I could not find this code in the predefined web.xml so there was nothing to uncomment.
I think the documentation should say, "If you want to define a different path for the configuration files add the parameter" rdapConfigurationUserPath "in the web.xml file" and then put an example of how to put the parameter in the xml file or simply Add in the xml file the parameters to be configured, disabled correctly, to be consistent with the documentation.
Third, it seems that it was envisioned that the user would be able to enter an absolute path to whatever file anywhere, but this is not working: The code never actually queries the filesystem outside of the classpath and the servlet context.
So this is currently a seemingly pointless feature; one can redefine the configuration file, but only if it still is within the context.
response-privacy largely suffers from the same problems.
I think that this was the original vision for all the configuration:
First, query the classpath (ClassLoader#getResourceAsStream(String)) to get default values.
Then, if the user somehow defined custom locations for configuration files, then try and find that in the servlet context (ServletContext#getResourceAsStream(String)), and if that fails, try and fall back to find them elsewhere (Files#newInputStream(Path)).
Otherwise (if there were no custom file definitions) find the files in their default servlet context locations (Again, ServletContext#getResourceAsStream(String)).
My opinion on how to read the settings is as follows.
-
First read the default configuration provided.
-
Second, if the user configures a path to a directory, the rdap-server will read the configuration to that path, the path should be provided as an absolute path.
-
If the user does not configure a path to a directory, rdap-server should read the configuration in the default location defined in the documentation (usually WEB-INF).
Keep in mind that if the user sets a path to a directory to read the configuration, the configuration file should no longer be read in the default directory that the documentation indicates. (This is a personal comment, but we can always do that if there is no configuration in the path defined by the user, the rdap-server looks in the default folder defined in the documentation.)
The configuration provided by the user will overwrite the values โโof the default configuration. I.e. If the user only overwrites a single parameter, the other parameters will retain their default values.
In other words, configuration placement is a bit of a mess right now. We need to first agree on a standard and then follow it.
I Agree
from rdap-server.
The WEB-INF folder is the default location of the configuration.properties file, but you can define a new location by following these steps:
In WEB-INF/web.xml, find the following lines:
rdapConfigurationUserPath
Uncomment them, and write a valid directory path in param-value.
Save the changes and test the configuration.
There is no doubt that the documentation above is a mess. So, will the user really use that feature? I think this can be kind of confussing.
I think that this was the original vision for all the configuration:
1.First, query the classpath (ClassLoader#getResourceAsStream(String)) to get default values.
2.Then, if the user somehow defined custom locations for configuration files, then try and find that in the servlet context (ServletContext#getResourceAsStream(String)), and if that fails, try and fall back to find them elsewhere (Files#newInputStream(Path)).
3.Otherwise (if there were no custom file definitions) find the files in their default servlet context locations (Again, ServletContext#getResourceAsStream(String)).
My opinion is that the behavior should only consist of point 1 and 3 (together), in other words, load the default configuration, and then, rdap-server should read the configuration in the default location defined in the documentation (WEB-INF) looking for overwrited parameters, as @dhfelix said:
The configuration provided by the user will overwrite the values โโof the default configuration. I.e. If the user only overwrites a single parameter, the other parameters will retain their default values.
I think we should only give the users the option to write their configuration in the folder WEB-INF.
from rdap-server.
(DAlpuche)
So, will the user really use that feature? I think this can be kind of confussing.
(...)
My opinion is that the behavior should only consist of point 1 and 3 (together)
Really? I was under the impression that you were the one who wanted this feature. Then who was? What was the point?
(dhfelix)
Second, if the user configures a path to a directory, the rdap-server will read the configuration to that path, the path should be provided as an absolute path.
Yeah, I kind of feel that there is something inherently wrong about mixing the servlet context directory structure and the actual filesystem directory structure, which is what the help loading code is doing by querying the servlet context first and the filesystem second, using the same string.
Perhaps an alternate solution would be to define two separate web.xml keys:
<context-param>
<param-name> rdapConfigFileAbsolute </param-name>
<param-value> /home/myself/Desktop/config.properties </param-value>
</context-param>
<context-param>
<param-name> rdapConfigFileContext </param-name>
<param-value> WEB-INF/config.properties </param-value>
</context-param>
And the user would use whichever feels right and ignore the other.
But perhaps there is no point in doing this at all. It all comes down to why we wanted to support absolute paths in the first place. Do we have an answer for that?
from rdap-server.
(dhfelix)
Keep in mind that if the user sets a path to a directory to read the configuration, the configuration file should no longer be read in the default directory that the documentation indicates.
Agree.
(dhfelix)
(This is a personal comment, but we can always do that if there is no configuration in the path defined by the user, the rdap-server looks in the default folder defined in the documentation.)
This will lead to confusion; we don't want to accidentally load values the user is explicitly telling us not to.
from rdap-server.
Talking with @pcarana, we conclude that the way the application configuration should be read is as follows:
- First read the default configuration provided.
- Second, if the user configures an absolute path to a directory outside of the context of the web application, the rdap-server will read the configuration to that path, the path should be provided as an absolute path.
- If the user does not configure a path to a directory, rdap-server should read the configuration in the default location defined in the documentation (usually WEB-INF).
Users will not be able to configure where the application can read the configuration inside the rdap-server.
from rdap-server.
Related Issues (20)
- SLF4J in war File HOT 3
- Compatibility issue between Tomcat and Jetty HOT 5
- IDNs in the zone table HOT 6
- fk_entity_remarks_remark1 constraint HOT 2
- proxyName / proxyPort Connector properties HOT 3
- IDN Domain names where the Unicode contains letters not in the Latin character set HOT 2
- about the automatically generated ("rel":"self") links HOT 4
- Database schema changelog - v1.4.1 to v1.4.2 HOT 2
- Unnecessary constraint public_id_pid_id_UNIQUE in domain_public_ids table? HOT 7
- Documentation inaccessible due to IPv6-address certificate problems HOT 3
- Database access HOT 8
- SEVERE: Exception sending context initialized event to listener instance of class mx.nic.rdap.server.listener.RdapInitializer HOT 2
- I can't run demo server on my windows machine. java.lang.IllegalArgumentException: java.lang.NullPointerException
- "last update of RDAP database" event is not created for nameservers/domains/entities searches when is_db_data_live is true HOT 2
- "is_country_code_released" configuration doesn't apply to vcards into an entity into a nameserver into a domain
- country code and contact-uri privacy cannot be configured
- "last update of RDAP database" event's date is not updated when it is included in a nested object HOT 1
- rdapConformance - Default Value HOT 2
- Redaction of Contacts and the contact handle HOT 8
- Can anyone share a schema (.sql) file with sample data inserted? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rdap-server.