Loading of classes via Service Provider

[Sandro Martini <sa...@gmail.com>]

Hi all,
for some developments I'm doing in other projects I'm using the
standard Java ServiceLoader to be able to automatically load multiple
implementations of a given class/interface name, for a plugin-like
system.

In Pivot there is a similar thing: the class Service, doing all in our
code without using Java ServiceLoader for better flexibility, but
loading only 1 implementation (the first found in classpath) of the
given class/interface name.

I think it could be a good addition the ability to:
- handle more than 1 file META-INF/services/  ... if possible
- find/load more than 1 implementation (if found)
with this we could set some basis for a plugin-like component system,
or maybe for something like auto-discovery of Components and
auto-registering ... and probably other n things :-) .

These new features could expand existing Service class, and retrofit
(update but in a compatible way) its existing behavior.


Other approach would require classpath scanning (like Spring and many
other frameworks) but in a complex way, probably too much for our
requirements here.


What do you think ?

Bye,
Sandro

Re: Loading of classes via Service Provider

[Sandro Martini <sa...@gmail.com>]

Just created an issue to track this:

https://issues.apache.org/jira/browse/PIVOT-962


Bye,
Sandro

Re: Loading of classes via Service Provider

[Sandro Martini <sa...@gmail.com>]

Hi all,
here you can find a sample version of the same concepts, but more general:

https://github.com/smartiniOnGitHub/dynamic-loaders

It's a multi-project workspace managed by Gradle.
Currently Plugins are discovered and loaded in an automatic way, but
using standard Java ServiceLoader (simple to use but with little
customizations) ... a great feature (of ServiceLoader) is that all
manifest files with the given name are loaded, even in different
projects or jars (available in classpath).
To try it, run Unit Tests under dynamic-loaders-plugin-sample , and
even dynamic-loaders-core .

In Pivot I think that we could rewrite something similar (but simpler
:-) ), maybe using ServiceLoader initially (and maybe later changing
its implementation details), but instead of Plugins (like in my
experimental project) for Components and maybe even other kind of
classes, I still have to better generalize loaders there ...

For info, suggestions, etc please tell me.

Bye,
Sandro



2014-09-16 18:06 GMT+02:00 Roger Whitcomb <Ro...@rbwhitcomb.com>:
> Okay. That sounds good. I would love to see the hard-coded skin class list replaced (for instance).
>
> Ciao,
> ~Roger
>
>
>> On Sep 16, 2014, at 12:25 AM, Sandro Martini <sa...@gmail.com> wrote:
>>
>> Ciao Roger,
>>
>>> I think this sounds reasonable, but could you be more specific about your use case, and the way it could be used inside Pivot?
>> I think could be used for discovery/handle some kind of Components,
>> could be used for example in automatic registering of components with
>> a Skin, and many other things.
>>
>> At a more wide level even for group of features inside an application
>> (something like a module with a dedicated classloader) ... just as
>> idea.
>>
>>
>> Anyway I have to meke some test, and then post some update.
>>
>> Bye
>>

Re: Loading of classes via Service Provider

[Roger Whitcomb <Ro...@rbwhitcomb.com>]

Okay. That sounds good. I would love to see the hard-coded skin class list replaced (for instance).

Ciao,
~Roger


> On Sep 16, 2014, at 12:25 AM, Sandro Martini <sa...@gmail.com> wrote:
> 
> Ciao Roger,
> 
>> I think this sounds reasonable, but could you be more specific about your use case, and the way it could be used inside Pivot?
> I think could be used for discovery/handle some kind of Components,
> could be used for example in automatic registering of components with
> a Skin, and many other things.
> 
> At a more wide level even for group of features inside an application
> (something like a module with a dedicated classloader) ... just as
> idea.
> 
> 
> Anyway I have to meke some test, and then post some update.
> 
> Bye
> 

Re: Loading of classes via Service Provider

[Sandro Martini <sa...@gmail.com>]

Ciao Roger,

> I think this sounds reasonable, but could you be more specific about your use case, and the way it could be used inside Pivot?
I think could be used for discovery/handle some kind of Components,
could be used for example in automatic registering of components with
a Skin, and many other things.

At a more wide level even for group of features inside an application
(something like a module with a dedicated classloader) ... just as
idea.


Anyway I have to meke some test, and then post some update.

Bye

RE: Loading of classes via Service Provider

[Roger Whitcomb <Ro...@actian.com>]

I think this sounds reasonable, but could you be more specific about your use case, and the way it could be used inside Pivot?

Thanks,
~Roger

-----Original Message-----
From: Sandro Martini [mailto:sandro.martini@gmail.com] 
Sent: Thursday, September 11, 2014 9:14 AM
To: dev@pivot.apache.org
Subject: Loading of classes via Service Provider

Hi all,
for some developments I'm doing in other projects I'm using the standard Java ServiceLoader to be able to automatically load multiple implementations of a given class/interface name, for a plugin-like system.

In Pivot there is a similar thing: the class Service, doing all in our code without using Java ServiceLoader for better flexibility, but loading only 1 implementation (the first found in classpath) of the given class/interface name.

I think it could be a good addition the ability to:
- handle more than 1 file META-INF/services/  ... if possible
- find/load more than 1 implementation (if found) with this we could set some basis for a plugin-like component system, or maybe for something like auto-discovery of Components and auto-registering ... and probably other n things :-) .

These new features could expand existing Service class, and retrofit (update but in a compatible way) its existing behavior.


Other approach would require classpath scanning (like Spring and many other frameworks) but in a complex way, probably too much for our requirements here.


What do you think ?

Bye,
Sandro