I'm looking to add Sling within my own Karaf Container alongside other web applications I have deployed in Jetty. I have created an OSGI feature that contains all the required sling bundles and I am able to deploy this feature within Karaf without any issue and can make POST and GET requests to Sling, e.g: POST/GET http://localhost:8181/content/test without any issues.
The problem is all Sling Servlets & Filters are served from the ROOT '/' context of Jetty. There doesn't seem to be any configuration for Sling to either configure a HttpContextMapping to serve all sling resources from /sling or /cms nor does there seem to be a property to pass a httpContext.id property to all Sling Servlets & Filters registed via OSGI Service Registration.
Sling seems to assume that you either take the launchpad WAR and deploy it within the servlet container at which point the war name dictates the servlet context mapping, eg. you can rename to cms.war or sling.war OR if you take my approach Sling assumes that it will be the only application running within the container?
Does anyone know anyway of configuring sling to run at a given context eg: http://localhost:8181/sling when deploying the various bundles within Karaf?
Related
There might be something I fundamentally misunderstand about Docker and containers, but... my scenario is as follows:
I have created an asp.net core application and a docker image for it.
The application requires some settings being added / removed at runtime
Also some dll plugins could be added and loaded by the application
These settings would normally be stored in appsettings.json and a few other settings files located in predefined relative path (e.g. ./PluginsConfig)
I don't know how many plugins will there be and how will they be configured
I didn't want to create any kind of UI in the web application for managing settings and uploading plugins - this was to be done on the backend (I need the solution simple and cheap)
I intend to deploy this application on a single server and the admin user would be able and responsible for setting the settings, uploading plugins etc. It's an internal productivity tool - there might be many instances of this application, but they would not be related at all.
The reason I want it in docker is to have it as self-contained as possible, with all the dependencies being there.
But how would I then allow accessing, adding and editing of the plugins and config files?
I'm sure there's a pattern that would allow this scenario.
What you are looking for are volumes and bind mounts. You can bind files or directories from a host machine to a container. Thus, host and container can share files.
Sample command (bind mount - (there are also other ways))
docker container run -v /path/on/host:/path/in/container image
Detailed information for volumes and bind mounts
I am containerizing an older Java web application with Docker. My Dockerfile pulls an official Tomcat image from Docker Hub (specifically, tomcat:8.5.49-jdk8-openjdk), copies my .WAR file into the webapps/ directory, and copies in some idiosyncratic configuration files and dependencies. It works.
Now I know that Tomcat comes out-of-the-box with a few directories under webapps/, including the "manager" app, and some others: ROOT, docs, examples, host-manager. I'm thinking I ought to delete these, lest one of my users access them, which might be a security risk and is unprofessional at the least.
Is it a best practice to delete those installed-by-default web apps from an official Tomcat image? Is there any downside to doing so? It seems logical to me, but a web search didn't turn up any expert opinion either way.
Every folder under webapps represents discrete Web Application contained within Tomcat Servlet Container after the server startup and deployment.
None of those web applications have any implicit or explicit correlation with either Catalina, Jasper or any other system component of Tomcat.
You should be quite OK to remove all those folders (apps) unless you need to have a Manager tool/application to manage your deployments and server. Even that can be installed again later on.
Stuck with few limitations to build an effective cluster based design for a distributed app (using Docker + OpenShift Origin)
To give a brief idea about my current architecture, we have multiple war and micro-services and all these apps following common approach to read property files from external folder (outside of war).
Example: /usr/local/share/appconfigs and my app refers from classpath.
We are using token based approach to generate these property files, based on environment. These files will be available in github.
To Dockerize our apps (war & services), I am building these properties first then copying them to catalina_base to make them available in classpath in Dockerfile.
Now to make my app so flexible and run multiple instances for different environments (example: DEV, INT, PREFIX) I am considering spring-cloud-config (server).
Brief summary,
Step 1) My externalized properties are built and available in github (Example: appconfigproperties)
Step 2) One Docker container runs with spring-cloud-server-config to serve property files based on profile key
Step 3) Run Docker App (war & other services) in another container using above properties.
Now Limitations here
I cannot use spring-cloud-config-client in my app, because it is not built on Spring-Boot. So I have left with only option that is REST based api to get properties
But I need the properties from one running container (which are served by spring-cloud-config-server), in another container App in its Dockerfile to copy to its catalina-base folder (so technically before app running).
If I want to run myty app in Dev or Int, I just need to run a container with few clicks, to make this distributed app completely configuration driven and on demand.
Appreciate your time to read and suggest possible changes to the solution if needed.
I am creating an application with Spring Boot and Docker. What I want to do is edit the static resources (.js and .css) without having to stop/rebuild/start the container.
I have read a few tutorials, blogs, and examples (including http://bsideup.blogspot.com/2015/04/spring-boots-fat-jars-vs-docker.html) Every example I have seen looks like I must rebuild the jar, rebuild the container, and stop/start the container to see any sort of change.
Have I overlooked some configuration that would allow me to edit a .css file and immediately see the change reflected in the browser?
I sucessfully managed to complete with my Grail's new website and now i want to run it on my machine to acess it everywhere. I would like to know what is the best approach to do that, i'm a bit noob in what concerns servers and connections. Any help would be aprecciated.
Jm
You need a Java servlet container. The quickest and easiest approach is probably to use Jetty on a Linux system -- most will allow you to install it directly. This allows you run a deployed system from a "war" file. Basically, you would do something like:
grails war
To build the war file, and then copy that (it'll be created in the target directory, with a name based on your application name and version) to the webapps directory for Jetty. On my (Ubuntu) system, that's /var/lib/jetty/webapps/. If you name it root.war, it will serve URLs from the root of the server configuration (typically on port 8080), so http://myhost.mydomain:8080/ will be passed to your Grails application. You'll need to restart Jetty to pick up the new root.war file, e.g., sudo /etc/init.d/jetty restart
Jetty is not the most flexible or powerful servlet container, but it is probably the quickest way to get something up and running, and you can explore more powerful alternatives (Tomcat being an obvious one) as you have time.
Unless you need persistent storage in your app (e.g. end users uploading pictures, etc), you can use Cloud Foundry. It's free for now and makes deployment very easy.
http://blog.springsource.com/2011/04/12/one-step-deployment-with-grails-and-cloud-foundry/
I've been using is via STS and it works really well. There's just one really annoying thing and that's the fact that STS ends up doing a build war with every change.
There's a cloud foundry plugin that gives you command line deployment.
http://www.grails.org/plugin/cloud-foundry
Or there's a Cloud Foundry UI plugin that "provides a simple monitoring UI for your applications deployed to Cloud Foundry. It uses the same API as the Cloud Foundry plugin but is more convenient since runs in a web browser."
http://www.grails.org/plugin/cloud-foundry-ui