Does exist any method in witch i can add a wildcard into a properties file, and have the meaning of everything, like a.b.*.c.d=lalalala, or set a regex for all that ends in a.b.c=anything?
A normal Java properties file doesn't handle this, no. Bear in mind that it's a hashtable really, usually mapping strings to strings.
It sounds like you probably want to create your own class for this - but perhaps you could use a Properties object as a simple way of inserting the data?
Related
What I want to do is quite straight forward. I want to create a config object in my code and some of the values should be references. I then want to save that config to a file and later, when reading it, the references will be substituted with the correct value.
I use lightbends typesafe config library and the scala wrapper pureconfig (but don't mind about pureconfig)
Now to read and substitute values correctly the config needs to look something like this:
"name" {
"someNormalValue" : "v"
"subsitute" : ${substitute-value}
}
The question is, how can I actually generate such a config using the mentioned library.
Ps. I'm looking for a nicer solution than just rendering the config and going back to 'manually' remove the double quotes around ${substitute-value}
Thanks for you responses!
I have an XML file, which contains rules for code analyzer (to search vulnerabilities). So, it has very different rules like parameter, parameter count, any parameter type, const value and etc for method call (to detect specific calls), rules to detect some imports, inheritance and so on. But how to store this inside my program?
I found two ways:
Parse xml while scanning (to internal representation)
Create classes for each element: parameter, parameter value, number of
parameters
Is there a real life example of implementing this thing? Or you may just say the best/common way to do this
Keeping in XML file will probably be the easiest method
If you like to keep config in your code - use code to do so. Here is good example of simple initialization:
Map<String, Integer> config = new HashMap<String, Integer>()
{{
put("One", 1);
put("Two", 2);
put("Three", 3);
}};
To this cases i love to use properties files
.properties is a file extension for files mainly used in Java related technologies to store the configurable parameters of an application. They can also be used for storing strings for Internationalization and localization; these are known as Property Resource Bundles.
Suppose you have a file in your package path.to.your with a properties file file.properties you can include them in you jar and recover the file with getClass().getResourceAsStream("/path/to/your/file.properties") then you can load the bundle, change the params, add new keys, etc, more info with MKYong - Java Properties file examples
I wonder if somebody has already met with a requirement to make a processing in Java depending on values defined in a .properties file and what would be the best approach to achieve that ? For example, a property file will have some key/value pairs like that:
file.input=csv
data.type=multi
data.separator=;
...etc
So in this case, depending on a property value(for example, 'csv'), I'll call CSV processing related classes, depending on 'data.type' value, I'll update the corresponding model values (e.g. class MultiCastXXX). The aim is to have something more or less generic like an API and be able to process no matter what is defined in a property file (of course with some conventions and restrictions applied). What do you think, any ideas ? Thank you.
My question more specificity is this:
I want users on multiple front ends to see the "Type" of a database row. Let's say for ease that I have a person table and the types can be Student, Teacher, Parent etc.
The specific program would be java with hibernate, however I doubt that's important for the question, but let's say my data is modelled in to Entity beans and a Person "type" field is an enum that contains my 3 options, ideally I want my Person object to have a getType() method that my front end can use to display the type, and also I need a way for my front end to know the potential types.
With the enum method I have this functionality but what I don't have is the ability to easily add new types without re-compiling.
So next thought is that I put my types in to a config file and simply story them in the database as strings. my getType() method works, but now my front end has to load a config file to get the potential types AND now there's nothing to keep them in sync, I could remove a type from my config file and the type in the database would point to nothing. I don't like this either.
Final thought is that I create a PersonTypes database table, this table has a number for type_id and a string defining the type. This is OK, and if the foreign key is set up I can't delete types that I'm using, my front end will need to get sight of potential types, I guess the best way is to provide a service that will use the hibernate layer to do this.
The problem with this method is that my types are all in English in the database, and I want my application to support multiple languages (eventually) so I need some sort of properties file to store the labels for the types. so do I have a PersonType table the purely contains integers and then a properties file that describes the label per integer? That seems backwards?
Is there a common design pattern to achieve this kind of behaviour? Or can anyone suggest a good way to do this?
Regards,
Glen x
I would go with the last approach that you have described. Having the type information in separate table should be good enought and it will let you use all the benefits of SQL for managing additional constraints (types will be probably Unique and foreign keys checks will assure you that you won't introduce any misbehaviour while you delete some records).
When each type will have i18n value defined in property files, then you are safe. If the type is removed - this value will not be used. If you want, you can change properties files as runtime.
The last approach I can think of would be to store i18n strings along with type information in PersonType. This is acceptable for small amount of languages, altough might be concidered an antipattern. But it would allow you having such method:
public String getName(PersonType type, Locale loc) {
if (loc.equals(Locale.EN)) {
return type.getEnglishName();
} else if (loc.equals(Locale.DE)){
return type.getGermanName();
} else {
return type.getDefaultName();
}
}
Internationalizing dynamic values is always difficult. Your last method for storing the types is the right one.
If you want to be able to i18n them, you can use resource bundles as properties files in your app. This forces you to modify the properties files and redeploy and restart the app each time a new type is added. You can also fall back to the English string stored in database if the type is not found in the resource bundle.
Or you can implement a custom ResourceBundle class that fetches its keys and values from the database directly, and have an additional PersonTypeI18n table which contains the translations for all the locales you want to support.
You can use following practices:
Use singleton design pattern
Use cashing framework such as EhCashe for cashe type of person and reload when need.
How can I store an ArrayList and/or a HashMap variable using java.util.properties? If it's not possible what other class can I use to store application configuration?
If you just need to serialize your collections into Strings, I highly recommend XStream. It uses reflection to serialize a class into XML. There is documentation if the default behavior doesn't work for the class you want to serialize, but the following has worked for me every time so far:
XStream xstream = new XStream();
String xml = xstream.toXML(myObject);
MyClass deserializedObject = (MyClass)xstream.fromXML(xml);
assert deserializedObject.equals(myObject);
So... if "don't do that" doesn't work for you, then you need to encode the data somehow. One common technique is to prepend some string to the name of each element. For example if I have a map MyMap containing a->1, b->2, c->3, I might store in the properties file:
MyMap.a=1
MyMap.b=2
MyMap.c=3
For lists, you can do the same, just mapping indices to values. So if MyList contains {a,b,c}
MyList.0=a
MyList.1=b
MyList.2=c
This is a hack, and everything everyone else said is true. But sometimes you gotta do what you gotta do.
Properties is basically Map<String, String> meaning both key and value must be String objects. If you want more advanced configuration, you could go with Spring. Its an excellent framework and I use it in every project. Spring config files are extremely flexible.
java.util.Properties is only intended to be used with String keys and values. It does inherit the put() and putAll() methods from Hashtable, but it's rarely a good idea to use those to "cheat". Have you considered just storing your configuration information in a HashMap rather than a Properties object? You would have to customize the serialization a bit, but you're going to have to do that in any case as you can't take advantage of the default loading functionality of the Properties class.
Storing a HashMap would be easy, since each key and value in the Map can be represented by a corresponding key and value in the Properties object (see the setProperty method in Properties.
For the ArrayList you could do something similar, the keys would be the indexes and the values the items in the corresponding indexes.
In both cases, remember that a properties file only stores strings, so you'd have to devise a way to represent the keys and values in your objects as strings.