Hi, On Wed, Dec 9, 2015 at 12:42 PM Miroslav Beranič < [email protected]> wrote:
> Hi Pepijn, > > when I was looking around the project (when built and deployed) and > later on at the source code I've noticed that Celix already has "some" > HTTP interface - like the monitoring and REST services for RSA. I looked > at this, as I did not want to make "another" hot water or round wheel. > Later on I learned the HTTP is based on the Civet web, with "static" URIs. > > As said, this is PoC project/implementation. I was quite happy with it, > as it was "easy" to implement (I had all the examples available, so only > some code changes were done). > It makes sense to use existing open source HTTP implementation. I could not > agree more. But (there is always a but, when things looks positive, doesn't > it) the problems I faced (I was looking more at Nginx and Apache Httpd) > was that, I (perhaps it can be done, but for me it was an unbreakable > challenge) how to dynamically register/unregister request mappings. I know > HTTPD more, and there - server has to be restarted (if you do not use > some hot deploying module) to make effect. > Just before I "finished" my implementation, I found that there are "two" > HTTP servers in the Celix source code (examples). Civet and Mongoose, I've > started with Mongoose, but did not make much success; so I started my > "really simple" HTTP server. > The other "more relevant" why is : I did not want to have only one > HTTP implementation. So, I wanted to implement HTTP Service in a way, > that can work with any HTTP Server implementation - that is : C socket > simple, Civet, Mongoose, Apache HTTPD, Nginx, ... if someone feels his > implementation is better/best: woohoo, I want him to do it his way. > > But (again; do you notice a pattern here ...) that forces to make unified > bridge between HTTP Service and HTTP Server implementation. And that is > this additional work I had to do. Problem with this is, I haven't decided > if this is the best way or way I want to go/write. > > With filters and interceptors I am also facing some fundamental design > issues. Should this be part of HTTP Service or "framework" on top of the > HTTP Service (like Spring Framework). I guess you guys are all C, and I > also guess we see things different. To me Spring Framework became only > way I do HTTP related interfaces logic this days/years; and I do not really > care about the "core" HTTP Service provided/defined by the standard. > Plus, this is also related with how to implement HTTP Service - be a > general + different implementations or have only one. If general HTTP > Service is implemented with specific implementations, than this filters > have to be implemented in a way, that logic it portable/runnable across > different HTTP Server implementation. There are a lot of open questions > here. I did not want them to be opened. > Just curious which parts of Spring do you mean? I have some experience with Spring a few years back and at the time used Spring MVC. To be honest I really liked that and in a way I consider the Spring framework a (more static/config based) service oriented prorgamming framework if you do it correctly. > > I was building on only my trusted W520 Linux box :) I found (based on the > GIT Ignore file :D ) you guys are more-or-less on Macs. To be honest, > I am using CMake for the first time - with start of my involvement with > Celix. So yes, there is room for improvements. Thank you for the update, > will be used. > > At first I thought Celix is soo soo complex project, I started my own > uOSGI project. Found some people from around the Internet that were doing > the same, but -- well, it has to be complex as it is not a simple task; > event if it seems to be simple. So one year later I took another look > at the Celix project and wrote to Bjoern -- to get this "monster" built. > The documentation should be updated or if not relevant: deleted! :) It > made me wast more time than it was of good use to me. > But than you get into the flow and I was able to read/locate pieces of > source code that I needed and it was really easy -- it is all easy if you > have a good starting point. > Yeah documentation is lacking. Could you be more specific what is missing or did not work. e.g. did you use the gettting started doc ( https://celix.apache.org/documentation/getting_started.html) ? > > With Kubernetes project I mean INAETICS project, yes. As, I said before, > in Java one of the first things you do is a cluster :D If you want > performance. > So to have all this in a package: INAETICS project. It was a good day, > that day - I found/built/deployed INAETICS project. Really nice work. > Again, the docs could be better :D ; but, Bjoern pointed me to the updated > documents and added some pointers and it all worked in the first try. > > > I agree that HTTP is missing in Celix. To me, it is all about HTTP; I do > not know you guys. I guess you "play" with signals and bits; but I play > with massive HTTP traffic -- so "more or less" looking for a HTTP Service. > > > I am more at home with C++ than with C. Well, when you learn about C++, > you are told: this is like C plus classes; well, this is to not true and > total failed statement. It can be, do not get me wrong - but than just use > C; do not bother with C++. I was working with Java for ten years now and > my mind is somehow set on this OO style. It is difficult to think in a > way that C is set. I am not saying it is not the correct way, it is > different. Like Objective-C is different. > Well, for now I do not have any solid argument why use C++, to be honest. > Years I go I started to use Boost C++ for one project, and it worked > really well for me. So I used C++ more because of the Boost C++ library, > than because of the language. > Idea is to use (also) C++ as a HTTP server implementation; will see where > it goes. > I am picking arguments: what makes C so much better - is it simple syntax, > performance, common dominator, ... > > I use GCC, tried with Clang/LLVM but did not use it afterwards. When I > was playing about my own OSGi platform, I first fall into a trap - how to > load modules in runtime. In short: due to "C++ name mangling" it is not > possible to make pure C++ plugin. It is, but than again - you are quite > on the same level as to use existing C way. I do not know about the other > languages - like C, Rust. I do not like Swift, but not for the language; > I just do not like an idea of new languages being introduced. I see no > real value in it. Objective-C has it all, but this is how I see it. > > > I wrote PoC bundles that use Boost C++ and was able to trap events and > do all sorts of things with the bundle -- as long as the activator.c was > as is. So to me, this is "100% C++" bundle. > > Yes, I agree - the problem is in the cross-bundle/service usage of the > logic: use pure C++ abstract class in the C bundle. That would introduce > a lot of complexity. One solution I can think of is Apache Thrift. I am > not big fan of sucha solutions, but it promotes - it is up for the job. > We are working on remote service and for this looking at Apache Avro. Thrift is of course also an option, but that also brings the problem of such a solution ... which schema/idl to choose (Protobuf, Thrift, Cap'n Proto, OMG IDL, etc). Anyways this of course can be used for remote services (C<->C and Java<->C), but is also an option for cross native language support. The downside, and a big one IMO, is that it forces people to use a schema/IDL instead of directly using parts of the choosen language. > > Thank you for the review and comments. Much appreciated. > > > Kind Regards, > Miroslav > > 2015-12-03 21:58 GMT+01:00 Pepijn Noltes <[email protected]>: > > Hi, > > > > On Wed, Dec 2, 2015 at 10:56 PM Miroslav Beranič < > > [email protected]> wrote: > > > >> Hi All, > >> > >> this is my first post/mail to Apache Celix and also my first Apache > >> Celix (and after a long time C) project. > >> > > > > Welcome :) > > > > > > > >> I would like to use Apache Celix as base for my future projects. I am > >> big fan of OSGi (starting with Eclipse IDE) and Apache Felix and > >> Apache Karaf etc. > >> Well, to have it (OSGI) in C it makes it so much more fun! (well, > >> sometimes it is not that fun ...) > >> > > > > > > Could agree more. OSGI is great, but there is something about combing > OSGi > > and C that is really fun. Not always easy, often challenging, but fun :). > > > > > > > >> > >> My day ful-time job is in Java-based system integration projects. Jump > >> into C is (most of the time) fun, but different; so take that into an > >> account when you evaluate C code plus this is really simple PoC > >> project - to learn Apache Celix, CMake, C, ... I am not doing correct > >> cleanup, that much I know. > >> > >> What I've implemented is a simple HTTP Service, based on Whiteboard > >> pattern and whiteboard example located in the Apache Celix source code > >> tree. I used that example as a base: 1.) to learn the API of the > >> Apache Celix and 2.) it was already using Whiteboard pattern that I > >> wanted to use. > >> > > > > Cool. Something like the http service specification is really missing in > > Celix. In quite a few situation bundle run their own http servers (remote > > service admin, discovery). > > > > > > > >> > >> This implementation is split into multiple bundles. > >> - apache_celix_simple_http_server => Really simple HTTP server written > >> in C (pure socket open/listen) > >> > > > > Is there a reason not to use a 3rd party (open source) http service. e.g. > > something like civet web (https://github.com/civetweb/civetweb) ? I > would > > spare you some work, especially getting all the features of http correct > > (for example cache header.) > > > > > > > > > > > >> - apache_celix_http_service => HTTP Service that binds to (first > >> found) HTTP Server implementation and creates service tracker for the > >> servlet bundles > >> - apache_celix_examples_servlet_a => Servlet bundle for /hello_world_a > >> and some more URIs + HTTP methods > >> - apache_celix_examples_servlet_b => Servlet bundle for /hello_world_b > URI > >> > >> Most of the code was first hit on Google search and modified to do > >> this one simple job. It is not rock solid and ideally crafted. > >> > >> There can be any number of the Servlet bundles - started and stopped > >> at runtime. Regex URI are supported plus HTTP method filtering too > >> (GET/POST/DELETE, ...). Servlet bundle A makes use of the Regex URI > >> pattern and HTTP method servlet mapping filtering. > >> I am planning to add support for HTTP filters and interceptors (I am > >> "influenced" by Spring Framework project ... can't help it, I use it > >> daily). But than ... full HTTP "stack" has to be added with requests, > >> responses, sessions, security ... > >> > > > > Whoa big plans, but very cool. Would be interesting for sure. > > > > > > > >> > >> To build this baby: > >> CMake is used (who would have guessed it). Create build folder. And > >> run (from the inside of build folder): > >> cmake -DCELIX_DIR=/path/to/celix -DCMAKE_BUILD_TYPE=Debug > >> -DCMAKE_INSTALL_PREFIX=/path/to/install > >> -DJAR_COMMAND=/path/to/jdk1.8/bin/jar ../source/ > >> > >> Next > >> make all > >> make deploy > >> > >> > > For building on Mac. I needed to edit the CMake target_link_libraries > > command to include Celix libs (${CELIX_LIBRARIES). No big deal, but good > to > > known. > > > > > > > > > >> cd ./deploy/http_whiteboard/run.sh > >> chmod u+x ./run.sh > >> ./run.sh > >> > >> > >> (open new terminal) > >> [Handled by servlet/bundle A) > >> curl -X GET -i http://localhost:9090/static/resources/my-theme.css > >> curl -X GET -i http://localhost:9090/hello_world/a/ > >> curl -X GET -i http://localhost:9090/hello_world_a > >> > >> [Handled by servlet/bundle B] > >> curl -X GET -i http://localhost:9090/hello_world_b > >> > >> > lb > >> > stop 7 > >> > stop 6 > >> Try the curl URLs... how they come and go : if not registered HTTP 404 > >> error message is returned. > >> > ... > >> > start 6 > >> > >> And at the end press Ctrl+C to terminate. Trigger one more request, as > >> there is no timeout > >> implemented and it is waiting for the thread to terminate (running > >> flag to be false). > >> > >> > >> I know this is not usable in real world cases. But I like the idea. I > >> put this together in about ... 32hours of work, more ore less; keep in > >> mind: this was next task after compiling Apache Celix for the first > >> time ever and not really be a C expert; so to me - this is a proof > >> that Apache Celix has easy to learn API and it is easy to use it. I > >> did not use "deep and dark" corners of Apache Celix, but I like the > >> project. I looked/played with kubernetes project also and all worked > >> great - first time. > >> > >> > > Well that is nice to hear. Of course one of the benefits of Apache Celix > > should be a easier development time, specifically for more > > complex/abstracted applications. But it is nice to hear the experience > from > > the "field" :). > > > > > > > > With the kubernetes project I assume you mean the INAETICS project ( > > https://github.com/INAETICS/kubernetes-demo-cluster). > > > > Impressive that worked great for you, we known this is a difficult > project > > to setup, tryout and most importantly understand. > > > > > > > >> > >> What I am wondering though is - is there any plan to add Web-related > >> support (I am talking about the HTTP Service known from the > >> Felix/OSGI) to Apache Celix or is this considered non-Celix related > >> (to make Celix only the "kernel") : to make it as different/sister > >> project? > >> > > > > No real plans but there are wishes :). Apache Celix is already grown out > of > > it's "kernel" size and contains a lot feature from the > > compendium/enterprise spec. IMO something like the http service spec > should > > not be a sister project, but part of Apache Celix. > > > > > >> I am also not clear how the C++ is seen in the Apache Celix community, > >> is this no-go or go area? I will most probably be using Boost C++ > >> (mostly ASIO) library in the future (with Apache Celix). So, C for the > >> "framework" layer and C++ for the "application" layer. > >> > >> > > For now we are 100% C. Personally I a bit worried about introducing C++ > > even on the "application" layer. Because I am afraid this will slowly > move > > to the "framework" layer. > > > > That being said. I do think that eventually we want C++ and other native > > language support. Some time ago there where some discussion about Native > > OSGi. And I would like to see Celix move to that direction. That would > mean > > that we should support bundles written in 100% cpp and maybe D, Rust, > > Swift. > > > > I think support bundles written in other (native) language is quite > > feasible. I even started prototyping with some Swift code (which is > > promised to become open source) . The beauty about C is that it is the > > common dominator for native languages and therefore ideal as core > framework > > language. > > The biggest challenges would be how and if those bundles can share > services > > written in different language. So cpp pure abstract class as service used > > in a C bundle ?? > > > > Note that this is my opinion and not _the_ Celix policy, everything is > > discussable. > > > > > >> > >> Well, I guess this is all. I will attach source to this email. As I > >> did not publish the sourcecode to GitHub. In the source I state > >> "Author/Copyright" Miroslav, Mibesis (my company) -- but this code is > >> open to anyone that thinks will benefit to him. I hope there is no > >> filter on the mail server to filter attachments out. Attachments > >> contains source only, no binaries). But I have full GIT repo in - so > >> it can be seen, how I worked whiteboard example to get to the current > >> result. > >> > >> > > Before we can accept code the license must be Apache License v2 and > > attached as a attachment to a lira issue. > > But the start of I think is wise to discuss this a bit more and than see > > how we want to move forward. > > > > > >> > >> BTW: Bjoern was of great support and motivation to grab Apache Celix > >> and start working with it. Thank you Bjoern big time. > >> > > > > Good work Bjoern :) > > > >> > >> > >> Kind Regards, > >> -- > >> Miroslav Beranič > >> MIBESIS > >> +386(0)40/814-843 > >> [email protected] > >> http://www.mibesis.si > >> > > > > -- > Miroslav Beranič > MIBESIS > +386(0)40/814-843 > [email protected] > http://www.mibesis.si >
