Christian, That's probably somewhat more what I'd want. Not necessarily even in a docker image but possibly. That's one of the reasons I'm curious to see how Karaf boot looks when it comes out. I haven't used the static profile mechanism in Karaf or the plugins associated with it in Maven yet. For a small microservice sort of bundle what would be ideal is a Maven plugin that simply used the Maven dependencies and the framework and created a runnable or semi-runnable version of it. If it used the features as part of the build then for this purpose I'd just as soon have it read the features file and pull the required bundles in from that features file. Perhaps that's what the static profiles do and I need to take the time to work with it.
To be honest I haven't had a lot of time to think it through as I'm still working in Fuse on a day-to-day basis but I'm faced with more and more problems where such static micro-container strategies with pre-packaged container and bundles will make sense. In that case the slimmed down karaf that doesn't have the features resolver would be beneficial as well. Perhaps think of it as karaf as an appliance. An example of that might be a gateway appliance for deployment to a corporate DMZ. It has certificates and authentication to grant access to identical web services inside the firewall that use different certificates and authentication perhaps authorization features but identical services. That's a fairly static set of features and a standard project/design pattern could be set up for that. When run it could create that appliance in ready to run form. Ideally everything would be stuffed inside it that it needs to be deployed and perhaps I might even run it from my unit test and exercise those webservices. Conceptually I always think of that with a Tanukisoft wrapper but realize that that isn't the right licensing model but it is the right idea I think. In most cases I'd want to run something like that as a service on whatever platform. That's why conceptually I don't put Docker in the mix since to me that is just another level of abstraction that may or may not make sense depending on the context. In many cases my clients aren't using Docker and I don't have a desire to push for it. Brad On Tue, Apr 26, 2016 at 10:37 AM, Christian Schneider < [email protected]> wrote: > Why do you want to use blueprint outside of OSGi? > Wouldnt it be easier to just package a small OSGI application as a docker > image? > > Karaf now has a static profile that allows to package an application quite > like a microservice. Basically you create a tgz of the osgi framework + > some karaf features + you own bundles. > > Christian > > > On 17.04.2016 17:36, Brad Johnson wrote: > > Thanks. I'll give it a look. I have a project coming up where I'm > developing a new endpoint to send updates of information coming in from a > payment processor. So I'll have a CBR in line looking for updates to > information on request/response. Internally there are a different > divisions interested in that information and I have to set up a dummy web > server/service to serve up an API so that my application can call it (to do > a prototype/PoC). So having a little blueprint bootstrap mechanism to set > up a JAX WS/CXF server would be spankin'. If they continue with their > obsession with Docker it might become even more relevant since these > self-contained bundled applications become something like half-way between > what a WAR and OSGi are. It obviously has to include all its dependencies > like a WAR but it can run outside of a container. > > By that I mean, a Docker image might have some blueprint bootstrap with a > Tanukisoft Java Service Wrapper or equivalent. I can imagine a new set of > EIPs springing up around that. A small applciation, for example, that boots > in a DMZ and exposes a Java annotated interface with certain security > configurations and then turns around and uses the same interface to make a > service call inside the firewall with different security and credentials. > A tiny router/firewall EIP for Docker. > > Part of the issue I run into currently is many of my clients are not using > straight open source but going through a well known commercial organization > so licensing becomes an issue. So as different technologies get thrust at > me because clients like them and want to adopt them and I find other > technologies like blueprint NoOSGi that allow me to use the karaf based > solutions for the more integrated enterprise but also repurpose the same > XML and Java for small non-enterprise applications I become intrigued. > > And I don't know how often I want to do integration testing where being > able to boot up small test applications. I certainly could turn around and > use Spring for that sort of work but now me and my teams would have to > switch paradigms. > > Obviously a lot of that is still just hand waving and scheming on my > part. Until one starts putting nails in it it is hard to tell if it'll > stand up or not. > > Brad > > On Sun, Apr 17, 2016 at 5:46 AM, Guillaume Nodet <[email protected]> > wrote: > >> You have some examples in the unit tests : >> >> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/test/java/org/apache/aries/blueprint/BlueprintContainerTest.java >> >> Also, the last release of blueprint-noosgi is a bit old, we may want to >> do a new release with more recent versions of blueprint-core, though it >> should work well enough. >> >> 2016-04-17 1:22 GMT+02:00 Brad Johnson < <[email protected]> >> [email protected]>: >> >>> Are there any examples/sample code for this? I find it a fascinating >>> idea. I could see some cases for testing. >>> >>> http://aries.apache.org/modules/blueprintnoosgi.html >>> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Red Hat, Open Source Integration >> >> Email: <[email protected]>[email protected] >> Web: http://fusesource.com >> Blog: http://gnodet.blogspot.com/ >> >> > > > -- > Christian Schneiderhttp://www.liquid-reality.de > > Open Source Architecthttp://www.talend.com > >
