Remote Service Admin example?

[scottslewis]

I'm considering contributing example(s) that use RS/RSA (api, impls and consumers). First, are there any known reasons why this wouldn't be expected to work? e.g. dynamic-importpackage

Second, if such a contribution is made is there someone contributing to the project to incorporate and release it in a timely manner (by timely manner I mean release that would include it in ~9 months).

[tjwatson]

I can only speak for myself, I don't have much time to spend on Atomos.

While I think it is an interesting concept and execution, it does not currently fit into any other work I do at the moment. At one point I had a strong need for Atomos because I was investigating native compilation (among other things, like embedding OSGi in a spring boot application JAR) for OSGi based products but none of that effort came to fruition. Atomos worked great for that purpose but the whole native compilation effort for the rest of the product and its users was simply not worth the cost and complication to the product.

I would really like if someone could pick up Atomos for something real and advance its releases, but until someone shows up to fill that role I am doubtful there will timely releases of Atomos.

But what does it mean to release an example? Atomos has only had one release where the only artifacts released to maven central were org.apache.felix:org.apache.felix.atomos:1.0.0 and org.apache.felix:atomos-maven-plugin:0.9.0. Otherwise the examples are all just code examples within this repository.

[tjwatson]

e.g. dynamic-importpackage

I'm not sure if that is a blocker for remote services, but ...

Dynamic imports are problematic because Atomos gives up the class loader control to be outside of the framework. For example, there is no actual class loader for a native compiled app. All the classes are "just there" so there is no ability to add additional content later that you would dynamically wire to. Similarly for flat class path there is no way to add more JARs to the Java class path that would get wired to dynamically. For Java modules (JPMS), additional module layers can be added dynamically but the modules (bundles) in the parent layers cannot wire successfully to modules (bundles) in child layers. And Java modules do not have a concept of late binding package visibility for the module class loaders. But even if they did, there is no hook from the Java module class loader that could notify the OSGi package resolver to do the dynamic import before the class load can complete/fail.

[scottslewis]

On Mon, Jun 9, 2025, 12:57 PM Thomas Watson ***@***.***> wrote: *tjwatson* left a comment (apache/felix-atomos#85) <#85 (comment)> I can only speak for myself, I don't have much time to spend on Atomos.

I dont see anyone else's name on anything Atomos...are there others that are active or could be active? While I think it is an interesting concept and execution, it does not

currently fit into any other work I do at the moment.

Ok.

< stuff deleted>

I would really like of someone could pick up Atomos for something real and

advance its releases, but until someone shows up to fill that role I am doubtful there will timely releases of Atomos.

If someone offered lead the project going forward, do you have the power to allow it? If not, who does? But what does it mean to release an example?

<stuff deleted> Probably wouldn't be same as existing examples, but to be honest I haven't thought it through yet. Is atomos formally under Apache felix? My belief was no, but not sure how its related to felix/apache other than name copyright.

[tjwatson]

Is atomos formally under Apache felix? My belief was no, but not sure how its related to felix/apache other than name copyright.

It is formally part of Apache Felix and all Felix committers have commit rights to Atomos. We just decided to separate it out from the main Felix git repo so we could control the git workflows for building and testing PRs without impacting the rest of Felix.

[tjwatson]

I dont see anyone else's name on anything Atomos...are there others that are active or could be active?

@karlpauls and @stbischof were involved at one point, but not sure they have more time for Atomos.

[scottslewis]

Is support for dynamic importp something that could be added to atomos...eg with constraints wrt layering? Or is this impossible? I dont think its a killer for rsa, but it does limit generality. Thanks

…

On Mon, Jun 9, 2025, 1:05 PM Thomas Watson ***@***.***> wrote: *tjwatson* left a comment (apache/felix-atomos#85) <#85 (comment)> e.g. dynamic-importpackage I'm not sure if that is a blocker for remote services, but ... Dynamic imports are problematic because Atomos gives up the class loader control to be outside of the framework. For example, there is no actual class loader for a native compiled app. All the classes are "just there" so there is no ability to add additional content later that you would dynamically wire to. Similarly for flat class path there is no way to add more JARs to the Java class path that would get wired to dynamically. For Java modules (JPMS), additional module layers can be added dynamically but the modules (bundles) in the parent layers cannot wire successfully to modules (bundles) in child layers. And Java modules do not have a concept of late binding package visibility for the module class loaders. But even if they did, there is no hook from the Java module class loader that could notify the OSGi package resolver to do the dynamic import before the class load can complete/fail. — Reply to this email directly, view it on GitHub <#85 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABHB5AIYV2H47TZJTMSLPL3CXSIRAVCNFSM6AAAAAB65SFBDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJWHA4DKNRWHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tjwatson]

Is support for dynamic importp something that could be added to atomos...eg with constraints wrt layering? Or is this impossible?

I don't see how dynamic imports can work if the class loader is not a framework provided class loader.