[
https://issues.apache.org/jira/browse/OWB-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated OWB-1319:
-----------------------------------
Description:
Apache OpenWebBeans (OWB) is a IoC container implementing CDI (Java Contexts
and Dependency Injection) specification.
With the rise of Kubernetes and more generally the Cloud adoption, it becomes
more and more key to be able to have fast, light and reliable servers.
That ecosystem is mainly composed of Microprofile servers.
However their stack is quite huge for most applications and OpenWebBeans-based
Microprofile server are not CDI centric (Meecrowave and TomEE are Tomcat
centric).
This is why the need of a light HTTP server (likely Netty based), embeddable
in CDI context (as a bean) comes.
It will be close to a light embedded servlet container but likely more
reactive in the way the server will need to scale.
It must handle fixed size payload (with Content-Length header) but also
chunking.
This task will require:
# define a lightweight HTTP API
** start with the most essential features, later enhance it with features like
file-upload
** at least supporting filter like interception, even interceptor based but in
a reactive fashion - CompletionStage
# implement the API (marry our API / CDI / OWB / Netty)
# make it configurable
** via code (Builder pattern)
** via Micoprofile Config (can be done after native image generation)
Once this light server is ready, the next step for a Java application to
embrace the cloud is to make it native runnable.
Today OWB generates the class proxies, which are required per CDI specs to
enable features like Interception and Decoration, lazy in runtime-mode.
A native-image can be generated via the "{{native-image}}" cmd tool from
GraalVM, where you can include the classpath. This classpath must already
contain the generated class-proxies as no bytecode manipulation is possible in
a native runtime.
It's not a trivial task to enable OWB to create proxies in buildtime.
This task will require:
# change the dynamic classname generation to static, otherwise we can't rely
on the classname when lookup the proxyclass.
# implement a proxy SPI in OWB, to enable to load pre-generated proxies
instead of generate them in runtime
# implement a BuildTimeProxyGenerator class (TODO)
In scope of this project, it's enough to manually call the
BuildTimeProxyGenerator via a Runnable (with a companion main(String[])) and
add the generated proxies in the classpath of the "native-image" cmd.
You should know:
• Java
• HTTP
*Difficulty*: Major
*mentors*: tandrasc...@apache.org, rmannibu...@apache.org
*Potential mentors:*
Project Devs, mail: dev (at) openwebbeans.apache.org
was:
Apache OpenWebBeans is a IoC container implementing CDI specification.
With the rise of Kubernetes and more generally the Cloud adoption, it becomes
more and more key to be able to have fast, light and reliable servers.
That ecosystem is mainly composed of Microprofile servers.
However their stack is quite huge for most applications and OpenWebBeans
Microprofile server are not CDI centric (Meecrowave and Tomee are Tomcat
centric).
This is why the need of a light HTTP server (likely Netty based), embeddable in
CDI context (as a bean) comes.
It will be close to a light embedded servlet container but likely more reactive
in the way the server will need to scale.
It must handle fixed size payload (with Content-Length header) but also
chunking.
File upload is an optional bonus.
This task will require:
1. to implement a HTTP server with Netty (or alike),
2. define a light HTTP API (at least supporting filter like interception, even
interceptor based but in a reactive fashion - CompletionStage),
3. make it configurable (Micorprofile config or so) and embedded.
Once this light server is ready, the next step for a Java application to
embrace the cloud is to make it native.
This is generally done through GraalVM.
Today OpenWebBeans proxy generation is not stable so making it native is not
trivial.
The end of the task will therefore be to implement a proxy SPI in OpenWebBeans
enabling to have pre-generated proxies and reload them at runtime (per bean).
The delivery of this task can be a Runnable (with a companion main(String[])).
You should know:
• Java
• HTTP
*Difficulty*: Major
*mentors*: tandrasc...@apache.org, rmannibu...@apache.org
*Potential mentors:*
Project Devs, mail: dev (at) openwebbeans.apache.org
> Implement lightweight CDI-centric HTTP server + allow build-time CDI proxy
> generation
> -------------------------------------------------------------------------------------
>
> Key: OWB-1319
> URL: https://issues.apache.org/jira/browse/OWB-1319
> Project: OpenWebBeans
> Issue Type: New Feature
> Reporter: Thomas Andraschko
> Assignee: Thomas Andraschko
> Priority: Major
> Labels: gsoc, gsoc2020, mentor
>
> Apache OpenWebBeans (OWB) is a IoC container implementing CDI (Java Contexts
> and Dependency Injection) specification.
>
> With the rise of Kubernetes and more generally the Cloud adoption, it becomes
> more and more key to be able to have fast, light and reliable servers.
> That ecosystem is mainly composed of Microprofile servers.
> However their stack is quite huge for most applications and
> OpenWebBeans-based Microprofile server are not CDI centric (Meecrowave and
> TomEE are Tomcat centric).
> This is why the need of a light HTTP server (likely Netty based), embeddable
> in CDI context (as a bean) comes.
> It will be close to a light embedded servlet container but likely more
> reactive in the way the server will need to scale.
> It must handle fixed size payload (with Content-Length header) but also
> chunking.
> This task will require:
> # define a lightweight HTTP API
> ** start with the most essential features, later enhance it with features
> like file-upload
> ** at least supporting filter like interception, even interceptor based but
> in a reactive fashion - CompletionStage
> # implement the API (marry our API / CDI / OWB / Netty)
> # make it configurable
> ** via code (Builder pattern)
> ** via Micoprofile Config (can be done after native image generation)
> Once this light server is ready, the next step for a Java application to
> embrace the cloud is to make it native runnable.
> Today OWB generates the class proxies, which are required per CDI specs to
> enable features like Interception and Decoration, lazy in runtime-mode.
> A native-image can be generated via the "{{native-image}}" cmd tool from
> GraalVM, where you can include the classpath. This classpath must already
> contain the generated class-proxies as no bytecode manipulation is possible
> in a native runtime.
> It's not a trivial task to enable OWB to create proxies in buildtime.
> This task will require:
> # change the dynamic classname generation to static, otherwise we can't rely
> on the classname when lookup the proxyclass.
> # implement a proxy SPI in OWB, to enable to load pre-generated proxies
> instead of generate them in runtime
> # implement a BuildTimeProxyGenerator class (TODO)
> In scope of this project, it's enough to manually call the
> BuildTimeProxyGenerator via a Runnable (with a companion main(String[])) and
> add the generated proxies in the classpath of the "native-image" cmd.
>
>
> You should know:
> • Java
> • HTTP
>
> *Difficulty*: Major
> *mentors*: tandrasc...@apache.org, rmannibu...@apache.org
> *Potential mentors:*
> Project Devs, mail: dev (at) openwebbeans.apache.org
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
