Multiple OpenWebBeans WebBeansContexts and ClassLoaders in a JavaSE Application

[Aaron Anderson <aa...@acm.org>]

Hi All,
I would like to build a Cloud based application server using Apache OpenWebBeans and Apache Ignite. I would like to use the OpenWebBeans JavaSE container to build a modular application server using CDI extensions, bean discovery, injection, etc. which is straight forward. However as part of the application jar files will be deployed to Apache Ignite and I would like to build a custom classloader to load and unload these applications at runtime similar to to Tomcat and how it deploys and undeploys web applications. My first thought is to build a custom application classloader that would load from the application jar file(s) first and then delegate to the parent class load which would shield access to most of the server class loader except for some exceptions like OpenWebBeans and API classes. However I think there are some challenges to this approach:
1) There would be multiple OpenWebBeans contexts, the server container and then multiple application containers. As long as OpenWebBeans is loaded from the application classloader and the CDI API is loaded at the server level and delegated down to the application level  there should be no container conflicts, right?
2) I would like to shield the server classloader as much as possible from the application classloader to avoid duplicate class scanning. Are there any OpenWebBeans properties I could set on the application WebBeansContext to ignore or include specific jars? Should I build my own extension of the ScannerService or use the org.apache.webbeans.scanExclusionPaths configuration?

3) In some cases I would like to bridge the server CDI container to the application CDI container to provide API implementations. For instance if there is an API interface called Foo with an implementation Bar both in the server container I would like for the application's CDI container to be aware of the Foo interface and have it be injectable but behind the scenes an instance in the server's CDI container would handle the requests. Has anything like this been done before? Are there any OpenWebBeans SPI interfaces that I should look into implementing for this bridging logic?

Thanks!
Aaron

Re: Multiple OpenWebBeans WebBeansContexts and ClassLoaders in a JavaSE Application

[Aaron Anderson <aa...@acm.org>]

Thanks Romain, I will explore the hierarchical BeanManager approach further.   

    On Tuesday, October 30, 2018 5:12 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
 

 Hi Aaron,
A custom scanner can not be needed since our exclusion config can be enough.
The closer of a tree of bean manager working not bad i know is the hierarchy of bean managers for ears in tomee. The idea is to skip parent beans during scanning and add them back after. Can be done through a portable extension if you can find the environment setup somehow.

Le mar. 30 oct. 2018 22:46, Aaron Anderson <aa...@acm.org> a écrit :

Hi All,
I would like to build a Cloud based application server using Apache OpenWebBeans and Apache Ignite. I would like to use the OpenWebBeans JavaSE container to build a modular application server using CDI extensions, bean discovery, injection, etc. which is straight forward. However as part of the application jar files will be deployed to Apache Ignite and I would like to build a custom classloader to load and unload these applications at runtime similar to to Tomcat and how it deploys and undeploys web applications. My first thought is to build a custom application classloader that would load from the application jar file(s) first and then delegate to the parent class load which would shield access to most of the server class loader except for some exceptions like OpenWebBeans and API classes. However I think there are some challenges to this approach:
1) There would be multiple OpenWebBeans contexts, the server container and then multiple application containers. As long as OpenWebBeans is loaded from the application classloader and the CDI API is loaded at the server level and delegated down to the application level  there should be no container conflicts, right?
2) I would like to shield the server classloader as much as possible from the application classloader to avoid duplicate class scanning. Are there any OpenWebBeans properties I could set on the application WebBeansContext to ignore or include specific jars? Should I build my own extension of the ScannerService or use the org.apache.webbeans.scanExclusionPaths configuration?

3) In some cases I would like to bridge the server CDI container to the application CDI container to provide API implementations. For instance if there is an API interface called Foo with an implementation Bar both in the server container I would like for the application's CDI container to be aware of the Foo interface and have it be injectable but behind the scenes an instance in the server's CDI container would handle the requests. Has anything like this been done before? Are there any OpenWebBeans SPI interfaces that I should look into implementing for this bridging logic?

Thanks!
Aaron



   

Re: Multiple OpenWebBeans WebBeansContexts and ClassLoaders in a JavaSE Application

[Romain Manni-Bucau <rm...@gmail.com>]

Hi Aaron,

A custom scanner can not be needed since our exclusion config can be enough.

The closer of a tree of bean manager working not bad i know is the
hierarchy of bean managers for ears in tomee. The idea is to skip parent
beans during scanning and add them back after. Can be done through a
portable extension if you can find the environment setup somehow.


Le mar. 30 oct. 2018 22:46, Aaron Anderson <aa...@acm.org> a écrit :

> Hi All,
>
> I would like to build a Cloud based application server using Apache
> OpenWebBeans and Apache Ignite. I would like to use the OpenWebBeans JavaSE
> container to build a modular application server using CDI extensions, bean
> discovery, injection, etc. which is straight forward. However as part of
> the application jar files will be deployed to Apache Ignite and I would
> like to build a custom classloader to load and unload these applications at
> runtime similar to to Tomcat and how it deploys and undeploys web
> applications. My first thought is to build a custom application classloader
> that would load from the application jar file(s) first and then delegate to
> the parent class load which would shield access to most of the server class
> loader except for some exceptions like OpenWebBeans and API classes.
> However I think there are some challenges to this approach:
>
> 1) There would be multiple OpenWebBeans contexts, the server container and
> then multiple application containers. As long as OpenWebBeans is loaded
> from the application classloader and the CDI API is loaded at the server
> level and delegated down to the application level  there should be no
> container conflicts, right?
>
> 2) I would like to shield the server classloader as much as possible from
> the application classloader to avoid duplicate class scanning. Are there
> any OpenWebBeans properties I could set on the application WebBeansContext
> to ignore or include specific jars? Should I build my own extension of the
> ScannerService or use the org.apache.webbeans.scanExclusionPaths
> configuration?
>
> 3) In some cases I would like to bridge the server CDI container to the
> application CDI container to provide API implementations. For instance if
> there is an API interface called Foo with an implementation Bar both in the
> server container I would like for the application's CDI container to be
> aware of the Foo interface and have it be injectable but behind the scenes
> an instance in the server's CDI container would handle the requests. Has
> anything like this been done before? Are there any OpenWebBeans SPI
> interfaces that I should look into implementing for this bridging logic?
>
> Thanks!
>
> Aaron
>
>