Kev's Development Toolbox

November 13, 2015

Weblogic Portal 10.3.6 from template: [Security:090820]The internal variable ServletInfoSpi is null and it should not be

On starting a new Weblogic Portal 10.3.6 domain created from a template of a previously created domain, you see this error:

Caused by: javax.servlet.ServletException: [Security:090820]The internal variable ServletInfoSpi is null and it should not be
at weblogic.security.providers.saml.SAMLServletAuthenticationFilter.init(SAMLServletAuthenticationFilter.java:51

As noted in this post here, the *.jks keystore files are omitted when creating from a template (is this a defect?). Copy them across from a new domain created via the config wizard into the root dir of your newly created domain fixes the issue:

[mwhome]\user_projects\domains\your_domain\*.jks

November 12, 2015

Video: Docker in 5 minutes

I’ve been spending some time working with Docker recently – it’s incredible technology and understandable why it’s getting so much attention for automating reproducible runtimes.

Here’s a quick 5 min overview covering an overview in 5 mins by Vincent Batts, who works at Red Hat on Docker and OpenShift:

November 10, 2015

Docker on Windows: interactive tty session gives “cannot enable tty mode on non tty input”

Trying to run a shell into a running container (docker exec -it containerid bash) using DockerToolbox/docker-machine on Windows 7 gives this error:

"cannot enable tty mode on non tty input"

(this runs fine on Mac OS X)

This is logged as an issue here. As a workaround, prefix the docker command with winpty, so:

winpty docker exec -it containerid bash

November 10, 2015

Docker ADD and COPY leave files owned by root by default

By trial and error I worked this out while building a container running Weblogic Portal 10.3.6 (see my Dockerfiles in the 10.3.6updates branch of my fork of oracle/docker: https://github.com/kevinhooke/weblogic-docker/tree/10.3.6updates).

Even if you do a ‘USER oracle’ followed by a COPY or ADD, the files transferred into the image are still owned by root. This was causing me issues as the WLST script could not read the files owned by root (as you’d expect).

This issue and the justification is described in issue 6119. It doesn’t seem that this will be fixed, it seems like it’s ‘working as designed’.