Today MoSKito 2.7.3 is released, and it contains the hottest feature since long time. But decide for yourself.
The feature request goes back some years to Dec 02, 2010 to my time at Parship, as Malte once asked, if it would be possible to know where a call to a method actually came from. It was on the list since then, but time was hard to find.
So what are tracers anyway? Tracers have 3 purposes or aspects:
- Tracers allow you to find out which part of your code has been calling some methods in a class of your application you are interested in. They achieve it by guarding the class in question (works with most monitoring points) and triggering and saving a stack trace once something passes by. This is useful if you see strange behavior of some method/class in the MoSKito monitoring, but don’t know who is actually using this class.
- After the execution has passed the tracer, the tracer start to record everything that happens afterwards. This means that a TracedCall (part of MoSKito Journey) is created on the fly and recorded. Every call on the monitored class will be noted, along with parameters and return values.
- To round this up, tracer will gather some amount of traces (code passing by). Depending on how you configured MoSKito, the tracers could collect only calls with largest duration or simply oldest or newest calls. This way you can run a tracer over a long period of time, collect all slow calls and investigate what slows them down.
Today we are going to connect MoSKito-Central to MongoDB database.
In a few words, MoSKito-Central is a service (remote or embedded) that receives your MoSKito statistics and stores it in the place of your choice (Filesystem, Database, …).
Our choice for now is MongoDB and MoSKito-Central in embedded mode.
After we decided to move everything we publish as open source into maven central and made a successful show case it’s time to start moving!
The new parent has now the sonatype parent as it’s parent (what a sentence!) and publishes everything to sonatype repositories – https://oss.sonatype.org/content/groups/public/.
To prevent version mismatch, every artifact will get a major upgrade, which means that effectively everything will start with a 2.
So it’s parent 2.0 and ano-util 2.0.0 which are already there:
and the rest will follow.
We keep you informed!
We often want to restrict access to specific part of an application from some parties. Moreover we usually want to do it with high flexibility at runtime, don’t we?
With the recent release of ano-site (version 2.4.1) we’ve added a brand new access control mechanism based on the ano-access framework. The idea was to make all parts of the application, that user interacts with, configurable from access point of view.
In this article we’ll make a brief overview of capabilities that are available in current version. It won’t replace comprehensive developer documentation, though.
Currently access can be controlled for such entities as:
- Navigation item
All configuration is done traditionally through ASG (ano-site content management system) which was enriched with two new modules for access control configuration: Ano-Access Configuration and Ano-Access Data. While latter is pretty straightforward, the former requires some explanation.
This is a short overview of topics in opensource that took place in september.
As MoSKito 1.5.0 hits the maven repositorty today, so do some new features about threads.
Here’s a short overview on 4 new screens added in 1.5.0 for threading issues.