How to implement scala logging for a scala project? - scala

I am creating a command based application, and need to setup logging for the project. Previously, I have only used the logging provided by Play framework and the configurations were already set. But since I need to setup logging for this project, how do we do so?
I decided to use Scala Logging 2.1.2, but checking on the github page there isn't any tutorial explaining how to set it up.
So, can you provide me with links to tutorials or examples, which explains the process of setting up logging for a scala project. Thank you, any help is appreciated.

Just stick to the JVM "standard": http://www.slf4j.org/
You can use whichever implementation you prefer, either logback or log4j.
By the way, this is what Play uses under the hood, so you should be able to re-use most of what you learnt on your previous project.

Related

Hippo custom essential plugin creation

How do we add our own plugin. Lets say a new add-on or feature which can be installed and used. How do we develop that? I am sorry i am new to this.
Kindly help
Depending on your needs, I suggest you check out:
https://documentation.bloomreach.com/14/library/concepts/open-ui/introduction.html
You can also create various plugins more like the native functionality. Adding such to essentials is described here:
https://documentation.bloomreach.com/14/library/essentials-plugins/overview.html
That doesn't tell you how to create a plugin however. Essentials is just a helper application, the plugin can be various things from services, to configuration, to document types, to hst components... All of that requires some knowledge of the internals of the system. Look around the documentation, you can see how to create various things like workflows, perspectives, and more.
A plugin is no more than a collection of code and configuration bundled together. It could be a frontend thing or a backend thing. So I can't simply tell you how to create them. It can be quite difficult, depending on what you want, to create a plugin. Look into the code of some plugins, you will see that it is basically a java project with some configuration that can be found by the system on startup.
You might want to ask more specifically on what exactly you want to develop. That could lead to more specific advice. It can be daunting when you are starting to work with the cms. With experience it does start to make sense.

How do you use play framework as a library, in a scala project

Use Play Framework as a component got a server up, but configuring the file system paths for routes file, views, etc, give or take having to take care of a thread pool for the embedded play server is a different story. Basing on the aforementioned, I started a template for including play as a library, but it remains unclear how to wire the paths, hopefully in an IDE-import friendly way too, so that Play can be nicely used in an existing non-play project, as a library.
How do you configure the file system paths for the routes file and views?
What else should be handled for being as robust as running as the framework?
Anything special for bundling the project for deploy with Play now included?
Motivation: Adding Play to a project, in the current state of affairs, means wrapping the project definition and structure around Play, and losing full compilation in sbt (because only run completes the compilation when using the play sbt plugin). As future Spray support is vague and Akka http is beta-ish, using Play as a library seems to plug a hole.
Somehow this didn't pop up in google, until someone suggested the link on gitter: https://www.playframework.com/documentation/2.5.x/ScalaEmbeddingPlay
Note that an application.conf file containing the required crypto secret can simply sit under src/main/resources in this embedded mode (up until you want to override it for production as per the documentation about it). This is quite enough for a REST server.
However now back to the docs, in case you want more than REST:
This can be used in conjunction with the Twirl template compiler and Play routes compiler
So for Play view templates (which are twirl templates really), refer to the repo I mention in the question body, in which #JonasAnso kindly enabled exactly that.

OSGi Karaf Scala UnsupportedAudioFileException

this is my first post here. I'm currently working on a simple http audio servlet in Scala on Apache-Karaf 3.0.0. I'm deploying it as a feature from inside some bundles, which I've built using a maven project. I'm using the 'javax.sound.sampled' library to get the audio, and I'm loading the file from the AudioSystem with 'java.io.File'.
val file = new File("audioFile.wav")
val audioStream = AudioSystem.getAudioInputStream(file)
This is obviously not the actual code, as I've stripped out all of the trivial bits. But this is where it fails, on the 'getAudioInputStream' call.
When I deploy this code to Karaf it fails with 'UnsupportedAudioFileException'. The file does exist, and is readable, I've already validated this. Also, I've made sure that this code can be run under the following.
- Scala 2.10.2, 2.10.3
- Java 1.7.0_45 ( This is the same JRE as my Karaf program is using )
- SBT 0.12.4 ( With the different Scala versions )
The only place this fails is when I deploy it to Karaf. I don't know if Karaf has cut out some random audio support, or what is going on, because this otherwise works when deployed through SBT or using the Scala command line. I've also looked into alternative libraries, but to no avail. Most other solutions seem to be based around actually playing the audio through a sound driver, which is useless to me. I need the actual byte data.
Also, keep in mind that just sending the file over is also useless me. Another requirement is that I need to be able to be able to merge multiple audio files in to one seamless audio stream. I already have this done, I just need to port it to OSGi, and for some reason I am now getting this error. I don't know if Karaf has something to do with it, or if my building it through a Maven project has broken something. I've looked around, and have found very little hint as to where the problem might be.
The audio files I'm using are of Waveform audio. 8,000 sampling rate, 16 bits per sample. I don't think this would actually make a difference, but I'm no expert on audio formats.
My pom.xml dependencies are as follows. The only plugin I'm using is the Scala compiler, and of course my root pom.xml is using the org.apache.felix maven-bundle-plugin. There's really not much magic going on here, yet the mystery remains.
<dependency>
<groupId>org.scala-lang</groupId>
<artifactId>scala-library</artifactId>
<version>2.10.3</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
</dependency>
Any clues would be greatly appreciated, thank you.
I think AudioSystem is not fully OSGi ready. This is what I found in the Aries Spy Fly dcoumentation.
Not sure what exactly you have to do to make it work but this might help.
https://aries.apache.org/modules/spi-fly.html
Special Cases
SPI Fly can be used for most SPI provider/lookup systems that use the TCCL pattern to obtain implementations. However in some cases, some special treatment is needed. This special treatment is often needed when the API itself does not match the name of the resources in META-INF/services, java.util.ServiceLoader is such a case, however SPI-Fly has built-in knowledge of ServiceLoader. Known APIs that require special treatment are listed below:
javax.sound.sampled.AudioSystem: This class uses sun.misc.Service under the covers (via com.sun.media.sound.JDK13Services) which is a predecessor to java.util.ServiceLoader. There is no special treatment for sun.misc.Service in SPI Fly (yet), but the AudioSystem.getAudioInputStream() API can be made to work by explicitly listing it in the provider bundle (the one that contains the relevant META-INF/services resources): SPI-Provider: javax.sound.sampled.AudioSystem on the consumer side you can use SPI-Consumer: javax.sound.sampled.AudioSystem#getAudioInputStream
Christian's answer is correct but I wanted to provide an updated link to the spifly documentation page. Specifically:
Java's java.util.ServiceLoader.load(), other similar methods such as
sun.misc.Service.providers() and also other static finder methods such
as the FactoryFinder.find() methods try to locate 'service'
implementations by looking for resources in the META-INF/services
directory of all the jars visible to the Thread Context ClassLoader
(TCCL).
There are a number of issues with the above mechanisms when used in
OSGi:
The Thread Context ClassLoader is not defined in general in an OSGi context. It can and has to be set by the caller and OSGi cannot
generally enforce that.
A bundle can't Import-Package META-INF/services as potentially many bundles will contain this pseudo-package and the OSGi framework
will only bind a single exporter to an importer for a given package.
Instantiating an SPI provider generally requires access to internal implementation classes, by exporting these classes an
implementing bundle would break its encapsulation.
Even if an implementation class was exported, importing this class in a consumer bundle would bind it to the specific implementation
package provided, which violates the principle of loose coupling.
Bundles have a dynamic life-cycle which means that provided services could disappear when a bundle is updated or uninstalled. The
java.util.ServiceLoader API does not provide a mechanism to inform
service consumers of such an event.
The SPI Fly project makes it possible to use existing code that uses
ServiceLoader.load() and similar mechanisms under OSGi.
Please note that as of 2016-05-20 new versions of the com.googlecode.soundlibs artifacts were uploaded to the maven central repository. These new versions of the artifacts are proper OSGi bundles. This will help everyone who needs to use the Java Sound API within an OSGi container
I created a simple example project on github that demonstrates how to play an MP3 file inside an OSGi container using the Java Sound API. Checkout the branch static-weaving and dynamic-weaving to see the respective solutions.

What does the Hammock.dll do?

I referenced the Couchbase assembly using NuGET in my project and it has a dependency on Hammock.dll. What does this assembly do? And is it really needed? In simple unit tests, my application works fine without the Hammock.dll being present. But I don't want any surprises when I move this app to production.
I would say [couchbase] still needs it, given there is a HammockHttpclient.
To answer the original question:
Hammock is an HTTP API library for .NET that greatly simplifies consuming and wrapping RESTful services.
This can easily be reasearched by going to the CouchbaseNetClient page and under Dependancies clicking Hammock. You can also go to the Couchbase Project and browse through the source to view if/where the library is still being used (as I have linked in the first sentence).

Can I write Eclipse plugins using Groovy?

Groovy seems to fix a lot of the things I dislike about Java, and I was wondering if it would be possible to actually write an Eclipse plugin in Groovy instead of Java.
Does anyone know if this is possible, and if so how to go about it?
I've just found a blog entry which says it's not officially supported but is actually possible.
Not yet tested to see if it works, but it seems promising:
Writing Eclipse plugins with Groovy, by Jörn Dinkla
#Peter, I do not think that the blog post you linked to is complete or if it will really work. It is pointing to the old version of Groovy-Eclipse, which is no longer supported and is out of date.
Yes. It is possible to create your own plugins in Groovy.
First, install the Groovy-Eclipse plugin from here:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/
Then you can create a new plugin project and add the Groovy Nature.
Remove the Groovy Libraries classpath container
Instead, add the org.codehause.groovy as a required bundle
Create your Groovy code as normal
Now, the tricky part is exporting the plugin using PDE. See this blog post for how to do that: http://contraptionsforprogramming.blogspot.com/2010/08/groovy-pde-redux.html
One important thing to note is that you will need at least one Java file in your project for PDE to compile anything, It can be a dummy, empty file (this is a bug that has not yet been fixed).
Rejoice!
As an example, here is the codenarc Eclipse plugin that was written completely in Groovy:
http://sourceforge.net/projects/codenarceclipse/
You can also use JRuby, or Javascript ...
JAM Circle is a great example showing how to make great use of a scripting language in an Eclipse plugin, by allowing the end user to write his own actions and load them at runtime.
There's a proxy-like plugin that allows you to implement the plugin virtually in any language that supports JSR223 (javax.scripting)