Skip to content

Instantly share code, notes, and snippets.

View rhuss's full-sized avatar

Roland Huß rhuss

View GitHub Profile
@rhuss
rhuss / jolokia-cors.md
Last active October 10, 2018 10:24
Jolokia and CORS

Jolokia and CORS

[Jolokia][1] has configurable [CORS][2] support so that it plays nicely together with the Browser world when it comes to cross origin requests. However, Jolokia’s CORS support is not without gotchas. This gist explains how Jolokias CORS supports works, what are the issues and how I plan to solve them.

tldr; Jolokia CORS support is configured via jolokia-access.xml but has issues with authenticated requests which are tackled for the next release 1.3.0

CORS Primer

[CORS][3] (Cross Origin Resource Sharing) is a specification for browsers to allow controlled access for JavaScript code to locations which are different than the origin of the JavaScript code itself.

Receiving source from STDIN as archive ...
Pulling image "docker-registry.default.svc:5000/fuse-ignite/fuse-ignite-s2i@sha256:3c9f66a53c5e2651d77bffec13ad61619a50ede99c74ba690f243568c9faef95" ...
Preparing to build proj242508/i-db2db-1:69a82d11
Copying sources from "/tmp/s2i-build157931650/upload/src" to "/tmp/s2i-build157931650/upload/src"
Clean build will be performed
Running "assemble" in "proj242508/i-db2db-1:69a82d11"
==================================================================
Starting S2I Java Build .....
S2I source build for Maven detected
Using MAVEN_OPTS '-XX:+UseG1GC -XX:+UseStringDeduplication -Xmx310m'
Starting the Java application using /opt/run-java/run-java.sh ...
exec java -javaagent:/opt/jolokia/jolokia.jar=config=/opt/jolokia/etc/jolokia.properties -cp . -jar /deployments/fabric8-maven-sample-custom-enricher-app-3.3-SNAPSHOT.jar
2017-04-11 10:21:03
Full thread dump OpenJDK 64-Bit Server VM (25.111-b15 mixed mode):
"server-timer" #6 daemon prio=5 os_prio=0 tid=0x00007f2ae020c000 nid=0x68 in Object.wait() [0x00007f2ac07c6000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000eb1eac68> (a java.util.TaskQueue)
at java.util.TimerThread.mainLoop(Timer.java:552)
minishift destroy
sudo rm -rf ~/.minishift
brew uninstall xhyve
brew install --force -HEAD xhyve
brew update docker-machine
brew link --overwrite docker-machine
brew unlink docker-machine-driver-xhyve
brew install docker-machine-driver-xhyve
sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
apiVersion: v1
kind: ImageStream
metadata:
name: cdi-camel
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ kubernetes-client ---
[INFO] io.fabric8:kubernetes-client:jar:1.3.74-SNAPSHOT
[INFO] +- io.fabric8:kubernetes-model:jar:1.0.42:compile
[INFO] | +- com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.6.3:compile
[INFO] | \- javax.validation:validation-api:jar:1.1.0.Final:compile
[INFO] +- com.squareup.okhttp:okhttp:jar:2.7.2:compile
[INFO] | \- com.squareup.okio:okio:jar:1.6.0:compile
[INFO] +- com.squareup.okhttp:logging-interceptor:jar:2.7.2:compile
[INFO] +- com.squareup.okhttp:okhttp-ws:jar:2.7.2:compile
[INFO] +- org.slf4j:slf4j-api:jar:1.7.13:compile
@rhuss
rhuss / ruler-issue.html
Created June 26, 2012 06:57
Ruler issue with Cubism 1.2.0
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<style type="text/css" media="all">
@import url("http://square.github.com/cubism/style.css");
</style>
<script type="text/javascript" src="http://square.github.com/cubism/d3.v2.js"></script>
<script type="text/javascript" src="http://square.github.com/cubism/cubism.v1.js"></script>
</head>
<body>

gofabric8 IDE setup for IntelliJ IDEA

In Shell:

  • export $GOPATH=~/go/workspace
  • mkdir -p $GOPATH
  • export PATH=$PATH:$GOPATH/bin
  • cd ~/go
  • rm -rf workspace/*
  • go get github.com/tools/godep
@rhuss
rhuss / gist:b0e1884c990a8351d3e9
Last active August 29, 2015 14:21
Docker-Hammering

With an empty OpenShift 0.5.1 started up (except for some services) within a Vagrant setup, I noticed, that /var/log/messages grows very fast because of the requests logged below. I could (and have) set the loglevel to WARN but this doesn't solve the issue of many requests needs to be processed by the Docker daemon which leads to a constant CPU usage of about 4-5%. I wonder where these requests for container meta information comes from and why they are sent in such a high frequency (look at the timestamps).

May 21 13:06:52 localhost journal: Suppressed 741 messages from /system.slice/docker.service
May 21 13:06:52 localhost docker: time="2015-05-21T13:06:52Z" level=info msg="GET /containers/json"
May 21 13:06:52 localhost docker: time="2015-05-21T13:06:52Z" level=info msg="+job containers()"
May 21 13:06:52 localhost docker: time="2015-05-21T13:06:52Z" level=info msg="-job containers() = OK (0)"
May 21 13:06:52 localhost docker: time="2015-05-21T13:06:52Z" level=info msg="GET /containers/json?all=1"
@rhuss
rhuss / gist:a83633c512fe0d0f1f2c
Created May 5, 2015 10:10
Debug output for "jmx4perl tomcat exec jolokia:type=Config debugInfo"
1430820552: Execution time: 1 ms
1430820552: Response: {"timestamp":1430820552,"status":200,"request":{"mbean":"java.lang:type=Runtime","attribute":"Name","type":"read"},"value":"11257@Tichny.local"}
1430820552: Execution time: 0 ms
1430820552: Response: {"timestamp":1430820552,"status":200,"request":{"mbean":"java.lang:type=Runtime","attribute":"VmVersion","type":"read"},"value":"24.75-b04"}
1430820552: Execution time: 0 ms
1430820552: Response: {"timestamp":1430820552,"status":200,"request":{"mbean":"java.lang:type=Runtime","attribute":"VmName","type":"read"},"value":"Java HotSpot(TM) 64-Bit Server VM"}
1430820552: Execution time: 0 ms
1430820552: Response: {"timestamp":1430820552,"status":200,"request":{"mbean":"java.lang:type=Runtime","attribute":"VmVendor","type":"read"},"value":"Oracle Corporation"}
1430820552: Execution time: 0 ms
1430820552: Response: {"timestamp":1430820552,"status":200,"request":{"mbean":"java.lang:type=Runtime","attribute":"Uptime","type":"read"},"value":98185}