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 Thu, 03 Dec 2015 20:58:52 GMT
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
>

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