celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: Apache Celix (Simple) HTTP Service
Date Tue, 15 Dec 2015 12:36:48 GMT
Hi,

On Wed, Dec 9, 2015 at 12:42 PM Miroslav Beranič <
miroslav.beranic@mibesis.si> 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 <pepijnnoltes@gmail.com>:
> > Hi,
> >
> > On Wed, Dec 2, 2015 at 10:56 PM Miroslav Beranič <
> > miroslav.beranic@mibesis.si> 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
> >> miroslav.beranic@mibesis.si
> >> http://www.mibesis.si
> >>
>
>
>
> --
> Miroslav Beranič
> MIBESIS
> +386(0)40/814-843
> miroslav.beranic@mibesis.si
> http://www.mibesis.si
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message