I looked at the profiles and static and find it interesting. I'll have to work with it some. There's obviously a bit of a mind shift there with the inheritance hierarchy. In my mind's eye I saw this as something I'd run from a parent pom with a bunch of child bundle projects but it would likely be better as an aside project separate from the main build hierarchy itself. Which is fine. Decouples it as a separate concern. Just a bit different than I'd imagined.
I'll have to give it a swing. On Tue, Apr 26, 2016 at 11:30 AM, Brad Johnson <[email protected] > wrote: > 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 >> >> >
