I have a task to collect and report some runtime statistics for my application. Ostrich looks quite friendly in both API and feature set. But I can't find any documentation about the most of declared features. Especially it is difficult to configure stats reporting through the web interface without any understanding of configuration principles.
So my main question: is there any documentation besides the README?
If no, could someone give an example of the following features (all of them are from the top of README):
load & reload per-environment configuration (there is example on SO already, but what if I want to use a classpath resource? how to define an environment? how to reload configuration?)
report statistics into log files
Or (perfectly) give a good architectural overview of configuration in Ostrich so I can find some way to do configuration by myself.
Ostrich config files are just regular scala classes, so if you want to load a classpath resource, you probably should create the config instance in code instead.
Here is how I load default config if -f command-line arg is not specified:
val runtime = RuntimeEnvironment(this, args)
val server =
if (runtime.configFile.exists) {
runtime.loadRuntimeConfig[Server]()
} else {
(new RPCServerConfig)()(runtime)
}
Note that you have to
- create config instance
- then call it's apply() method
- then apply(runtime) on the result
You can easily extend this to load different configs depending by e.g. lift's Props.mode
Related
I have a really complicated system which use multiple languages and frameworks (Java Python Scala Bash). In each module I need to retrieve configuration values which are similar and change frequently. Currently I'm maintaining multiple conf files which holds lots of duplicates.
I wonder if there is out of the box RestAPI which can retrieve variables by demand from remote location.
All I manage to find by now are ways to load the entire file from remote source which is half a solution from me:
YAML.parse(open('https://link_to_file/file.yaml'))
My goal, which I fail to find a lead to it, is to make a direct call.
MyRemoteAPI.get("level1.level2.x")
P.S
YAML is not mandatory solution for me, I'm Open for suggestions.
I don't know about an out-of-the-box API, but it's fairly trivial to build. Make a service that will read the YAML file and traverse to the appropriate key. e.g. using a dynamic language like Ruby (+Rails), you could do something like
def value
config = YAML.load_file '/local/path/to/config.yaml'
render plain: config.dig(params[:key].split('.'))
end
dig essentially traverses a structure and safely returns nil if a key isn't found, so this returns the value at the "leaf" of the requested path.
You might also want to cache the structure in memory to prevent constantly reading from the file, e.g. could do something like ##config ||= YAML.parse(open('https://link_to_file/file.yaml')) or config = Rails.cache.fetch('config', expire_in: 1.hour) { ... }. And/or cache the API's HTTP response.
In Paper [A Software Product Line for Static Analyses(2014)], there is an illustration related constructing call graph(Listing7).
In this example, Line14 is related to construct call graph. while i check the src code and API, what i could find is DefaultCHACallGraphDomain.scala which has no implementation of construct call graph.
As my purpose is using OPAL to construct call graph. Is there any demo or documents help me understanding existing CallGraphDomain in OPAL? currently, i can only find some class declaration.
I'll be really appreciated if anyone can give me some suggestions related this topic.
Thanks in advance.
Jiang
The interface that was shown in the paper doesn't exist anymore, so you can totally forget about it.
The default interface to get a CallGraph class is provided by the Project object you retrieve when you load the bytecode a Java project.
A general code Example:
val project = ... // a java project
val computedCallGraph = project.get(/* Some call graph key */)
val callGraph = computedCallGraph.callGraph // the final call graph interface.
The computed call graph contains several things. It contains the entry points, unresolved method calls, exceptions when something went wrong at the construction time and the actual call graph.
OPAL provides you several call graph algorithms, you can retrieve each by passing the corresponding call graph key to the Project's get method.
Currently, the following two keys are available and can be passed to Project.get (more information is available in the documentation of this classes):
CHACallGraphKey
VTACallGraphKey
Analysis mode - Library vs Application
To construct a valid call graph for a software project it depends on the project kind which analysis mode to chose. While applications provide complete information (except incomplete projects, class loading and so on), software libraries are intended to be used by other projects. However, those two different scenarios have to be kept in mind, when construction call graphs. More details can be found here: org.opalj.AnalysisModes
OPAL offers the following analysis modes:
DesktopApplication (safe for application call graphs)
LibraryWithClosePackagesAssumption (safe for call graphs that are used for security-insensitive analyses)
LibraryWithOpenPackagesAssumption (very conservative/safe for security analyses)
The analysis mode can be either configured in OPAL's config file or set as project setting at runtime. You can find the config file in the Common project under /src/main/resources/reference.conf.
All of those analysis modes are supported by the the CHACallGraphKey while VTACallGraphKey only supports applications so far.
NOTE: The interface may change in upcoming versions again.
Typesafe Config documentation and library examples make a point that type safety can be achieved by making a configuration object or nested objects with getter methods mapped to Config.getType(key) methods.
If I wrap config calls in something like this:
class MyConfig (cfg:Config) {
val language = cfg.getString("app.language")
val database = new {
val url = cfg.getString("db.url")
val port = cfg.getInt("db.port")
...
}
}
I can do decent looking calls like config.database.url. Neat. (That dot looks so much greater than underscore)
What I don't quite get is how to allow modifying properties and saving them - quoting documentation, config is immutable. My attempts so far turned into either a gross spaghetti (closures with var config) or horrendous boilerplate (modifying a plain object and creating a new config from it to save), so I turned here for help.
I'd appreciate if someone showed me a good pattern for programmatically modifiable configuration using Typesafe Config.
It is possible that Typesafe Config just isn't a right tool for the job. I have little use for it's powerful merging and inheritance capabilities, instead I mostly need a simple, concise, unicode-friendly and type-safe way to load and store properties. I already do have one, a reflection-based java lib working with annotated POJOs. Doesn't seem to be a lot of variety with configuration libraries in Scala. I may have been too eager to throw away my trusty java tools.
Using the standard GWT logger, is it possible to disable the Log statements for a complete package in the xml?
Or at least individual class's?
At the moment in the xml I can disable/endable all the logging with;
<set-property name="gwt.logging.enabled" value="TRUE"/>
This seems to set it globally for all class's in all packages. Is it possible to do this selectively in the xml?
The guide here; http://www.gwtproject.org/doc/latest/DevGuideLogging.html seems to only cover configuring the rootlogger, covering every log in the project. I am probably missing the obvious, but I don't "get" how to apply this selectively.
Given all my log statements are named;
protected static Logger Log = Logger.getLogger("parent.childc");
It seems like selectively turning them on/off should be possible.
Thanks,
Thomas
If you have all of your logger instances really initialized as Logger.getLogger("Example"), you can't selectively turn them off and on, since they are all one instance called 'Example', so I'm assuming that this isn't actually the case.
For the most part, this is normal JULI - the standard mechanisms that work on the JVM will work here. This is doubly true in dev mode, which actually uses the standard java.util.logging.Logger implementation. So if you are just looking for cleaned up logging in dev mode, treat it as you would any other logger - from the root instance, find the package or class that you want to disable/enable, and set the log level to where you want it.
In compiled code this behaves a little differently, you may need to experiment a bit to see exactly how, I don't recall at the moment. However, you can still use LogManager, and can walk all existing loggers, packages:
LogManager manager = LogManager.getLogManager();
Enumeration<String> allLoggers = manager.getLoggerNames();
// for each String in the list, grab the logger via manager.getLogger
The advantage to this as opposed to Logger.getLogger is that this will only tell you about loggers that already exist, instead of creating them as you go. This way you could have a config file or url param that specifies which details you wish to see logged, and disable the rest.
EDIT: I ran an old sample I had made again, and it appears that the chief difference between dev mode and prod mode is that in prod mode you get a logger per package, with root at the top and the specific named loggers as 'leaf nodes', while in dev mode all loggers seem to be placed in the root logger directly, with no intermediate packages. It is possible that if you requested a logger for a particular package that it would then make one, but I didn't test to find out.
As a simplest example, say I'm starting my application in a certain mode (e.g. test), then I want to be able to check in other parts of the application what mode I'm running in. This should be extremely simple, but I'm looking for the right Scala replacement for global variables. Please give me a bit more than : "Scala objects are like global variables"
The ideal solution is that at start-up, the application will create an object, and at creation time, that object's 'mode' is set. After that, other parts of the application will just be able to read the state of 'mode'. How can I do this without passing a reference to an object all over the application?
My real scenario actually includes things such as selecting the database name, or singleton database object at start-up, and not allowing anything else to change that object afterwards. The one problem is that I'm trying to achieve this without passing around that reference to the database.
UPDATE:
Here is a simple example of what I would like to do, and my current solution:
object DB{
class PDB extends ProductionDB
class TDB extends TestComplianceDB
lazy val pdb = new PDB
lazy val tdb = new TDB
def db = tdb //(or pdb) How can I set this once at initialisation?
}
So, I've created different database configurations as traits. Depending on whether I'm running in Test or Production mode, I would like to use the correct configuration where configurations look something like:
trait TestDB extends DBConfig {
val m = new Model("H2", new DAL(H2Driver),
Database.forURL("jdbc:h2:mem:testdb", driver = "org.h2.Driver"))
// This is an in-memory database, so it will not yet exist.
dblogger.info("Using TestDB")
m.createDB
}
So now, whenever I use the database, I could use it like this:
val m = DB.db.m
m.getEmployees(departmentId)
My question really is, is this style bad, good or ok (using a singleton to hold a handle to the database). I'm using Slick, and I think this relates to having just one instance of Slick running. Could this lead to scalability issues.
Is there a better way to solve the problem?
You can use the typesafe config library, this is also used in projects like Play and Akka. Both the Play and Akka documentation explain basic parts of it's usage. From the Play documentation (Additional configuration)
Specifying alternative configuration file
The default is to load the application.conf file from the classpath. You can specify an alternative configuration file if needed:
Using -Dconfig.resource
-Dconfig.resource=prod.conf
Using -Dconfig.file
-Dconfig.file=/opt/conf/prod.conf
Using -Dconfig.url
-Dconfig.url=http://conf.mycompany.com/conf/prod.conf
Note that you can always reference the original configuration file in a new prod.conf file using the include directive, such as:
include "application.conf"
key.to.override=blah