The log simulator we’ve built and written about in the past has had a release made that lines up with the Logging In Action book (v0.1). I am now continuing to add improvements on the main line. Not best Git branching practice, but as I’m working on this solo it doesn’t represent a problem.
If you expect multi line events all you need to do, is add to the properties file a name value pair, with the name FIRSTOFMULTILINEREGEX and the value is a Java/Groovy regular expression which can be used to determine if a line in a log entry is the 1st line in a new log. Then all subsequent log lines are appended to the previous line until a line identifies as a new log entry. The log entry will be written with newline characters in the same place as the read.
In addition to this if the synthetic log events need to be set to be new line then using the ALLOWNL property to be set to true will result in any new line escape sequences (\n) to be made into proper new lines in the output.
The details are all included in the documentation in GitHub.
For those who regularly follow my blog, I like Groovy as a way of scripting given its portability, proximity to Java, its use of the JVM means its really easy to work with. With the extra language features it makes it easy to work with without needing to setup Maven builds to manage dependencies for something simple. As a result, the utils I’ve produced to support Oracle API Platform CS (here) for example are written with Groovy.
However, not everyone is such a fan, or sees Groovy as niche and, to be honest in the last few years Python has made huge in roads in the scripting space. So I can appreciate the preference for Python to be used. This was really brought home to me by a peer review comments for my latest book project. This got me to thinking what options do I have to remove Groovy from the equation, without resulting in needing to mess with maven POM files. The options as I saw it are:
Replace any use of Groovy extensions with Java libraries
Switch to using Java 11 and the shebang feature (more in a minute)
Compile code with Groovyc and package the jars manually including dependencies.
From Java 11, the ability for a single Java file to be executed without compiling etc was introduced – known as shebang (more here). The issue here is a lot of applications have been certified against Java 8, and in an Enterprise environment this is important. Which means either installing Java 11 locally without changing environment variables, or you need to add code to switch Java versions as necessary. The upside being that you can run your code as a script, and then if necessary build it into a jar to distribute. Aside from the need to switch between JDK versions, Java’s language gets ever richer, but Groovy has a nice set of extensions that make JSON object navigation really nice, and these aren’t necessarily in core Java.
Groovy provides a tool to compile Groovy to bytecode for the JVM (i.e. create class files). From which we can create a JAR file with using the javac command. But this doesn’t bundle the Groovy dependencies necessary to run the jar, as a result Groovy still needs to be installed. You could do this through the use of a maven, Gradle or other build tools. But we’re back to creating a POM file or equivalent., and to be honest creating a POM file from scratch is slow going unless everything lines up neatly with file structures, which it won’t because when you produce a script you’re not expecting to need to worry about packages and associated folder structures.
In looking to see if someone had simplified the process I came across this excellent tool scriptjar (more here). Script jar takes the location of the class files, creates a jar file and loads it with the Groovy jar dependencies, and assembles the manifest file etc. Net result, a jar file created in 2 lines that has no Groovy deployment dependencies to use, and will work with older Java versions such as Java 8.
I started out referring to the API tools, but the same mechanism can be applied to the LogSimulator tool I’ve created that allows you to generate or replay existing logs in real-time or faster than real-time, making it easy to test log monitoring setups from a monitored source all the way through (today it only handles log file replaying or the use of the Java native logging).
The last week or two I have been working on a new API Platform utility to add to my existing tools (see here). This tool addresses the question of generating documentation. Much as been said about API documentation and the quality of it, check out these articles :
If you look at these articles and others, there are some common themes, which are:
Document the URI / payload
Describe error handling
Describe contracts such as how many API calls
How the API is authenticated
Apiary covers the first theme to a first class standard, and you will see Apiary called out for its ability to document APIs in a lot of articles. Well written API Blueprints will cover the bulk of the second bullet. But the other points tend to fall outside of a Blueprint and fit more the API Policies and their use.
Not everyone is so commited or enjoys writing documentation. The other driver for going beyond the use of Apiary is that some organizations feel the need to have a traditional word style document to capture/define an API’s contract in detail. With the API Platform the management portal enables an API to be published into the developer portal with the Apiary definition and a markdown file for further documentation.
With version 11 of Sparx‘ Enterprise Architect tool a new cloud feature was introduced to support team working, which previously had been achieved using a shared Database.
When we heard about EA Cloud, both myself and my colleagues got rather excited, thinking that this would be the opportunity to offload the effort of looking after a central DB (making sure backups happened, fine tuning the DB settings and so on) plus maintaining the platform’s patching for security etc. Not only that through the cloud capability we could host the repository that made it very easy for the team to access the repository on the move without needing to have another whole in our corporate firewall etc.
Unfortunately, EA Cloud provides all the software to establish a cloud based repository – which can be used through firewalls etc – HTTPS traffic rather than DB connectors on unusual ports but not the hosting. This seems to a bit of a missed opportunity for Sparx who already have to deal with all of these points to host 3 demo cloud servers. So the next step of instantiating a server for a regular on going fee doesn’t seem too challenging, not to mention promotes customer tie in, plus the ability to capture some potentially interesting metrics about its users (e.g. which modelling techniques are most popular etc). Having looked at Sparx partners they don’t offer the capability either which is a shame.
You must be logged in to post a comment.