You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by "Andi Huber (Jira)" <ji...@apache.org> on 2020/01/06 09:45:00 UTC

[jira] [Updated] (ISIS-2183) Convert all remaining plugins (ServiceLoader) into regular service beans.

     [ https://issues.apache.org/jira/browse/ISIS-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andi Huber updated ISIS-2183:
-----------------------------
    Description: 
A more general question re: plugins ... what is it about them that means that they can't be implemented as regular services, with Spring finding the implementation using classpat scanning?
 Is it that we need to load them before Spring?
 ie using ServiceLoader or similar?
 Not challenging the design, just want to be able to write some sensible docs about it

Andi, 11:01
 Let me check this first ...

I think we have these, that use ServiceLoader mechanics:
 1. IsisJdoMetamodelPlugin
 -2. UriBuilderPlugin-
 -3. IsisJaxrsServerPlugin-
 -4. ProxyFactoryPlugin-
 5. ValuePropertyPlugin
 6. DateConverterPlugin
 7. ComponentFactory

Its likely we could convert 2-7 to service beans, with 1. I need to check the rational ...

11:12
 I think we should do that, then.

Andi, 11:13
 I believe with (1) its also possible now to convert it to a service. It was not possible when the ServiceLoader introspection was run during the post-construct phase, but I changed that to now run after the post-construc pahse, when all the services are discovered and initialized.

11:14
 OK, that would then be a very nice place to get to... the whole framework is just a bunch of Spring-loaded beans.

Andi, 11:14
 yep I agree

11:15
 I think it also means that there isn't really any concept of plugins ... or at least, any of these service beans could be replaced by a different implementation with a higher @Order( if required.

  was:
A more general question re: plugins ... what is it about them that means that they can't be implemented as regular services, with Spring finding the implementation using classpat scanning?
Is it that we need to load them before Spring?
ie using ServiceLoader or similar?
Not challenging the design, just want to be able to write some sensible docs about it

Andi, 11:01
Let me check this first ...

I think we have these, that use ServiceLoader mechanics:
1. IsisJdoMetamodelPlugin
2. UriBuilderPlugin
3. IsisJaxrsServerPlugin
4. ProxyFactoryPlugin
5. ValuePropertyPlugin
6. DateConverterPlugin
7. ComponentFactory

Its likely we could convert 2-7 to service beans, with 1. I need to check the rational ...

11:12
I think we should do that, then.

Andi, 11:13
I believe with (1) its also possible now to convert it to a service. It was not possible when the ServiceLoader introspection was run during the post-construct phase, but I changed that to now run after the post-construc pahse, when all the services are discovered and initialized.

11:14
OK, that would then be a very nice place to get to... the whole framework is just a bunch of Spring-loaded beans.

Andi, 11:14
yep I agree

11:15
I think it also means that there isn't really any concept of plugins ... or at least, any of these service beans could be replaced by a different implementation with a higher @Order( if required.


> Convert all remaining plugins (ServiceLoader) into regular service beans.
> -------------------------------------------------------------------------
>
>                 Key: ISIS-2183
>                 URL: https://issues.apache.org/jira/browse/ISIS-2183
>             Project: Isis
>          Issue Type: Improvement
>    Affects Versions: 2.0.0-M2
>            Reporter: Daniel Keir Haywood
>            Assignee: Andi Huber
>            Priority: Major
>             Fix For: 2.0.0
>
>
> A more general question re: plugins ... what is it about them that means that they can't be implemented as regular services, with Spring finding the implementation using classpat scanning?
>  Is it that we need to load them before Spring?
>  ie using ServiceLoader or similar?
>  Not challenging the design, just want to be able to write some sensible docs about it
> Andi, 11:01
>  Let me check this first ...
> I think we have these, that use ServiceLoader mechanics:
>  1. IsisJdoMetamodelPlugin
>  -2. UriBuilderPlugin-
>  -3. IsisJaxrsServerPlugin-
>  -4. ProxyFactoryPlugin-
>  5. ValuePropertyPlugin
>  6. DateConverterPlugin
>  7. ComponentFactory
> Its likely we could convert 2-7 to service beans, with 1. I need to check the rational ...
> 11:12
>  I think we should do that, then.
> Andi, 11:13
>  I believe with (1) its also possible now to convert it to a service. It was not possible when the ServiceLoader introspection was run during the post-construct phase, but I changed that to now run after the post-construc pahse, when all the services are discovered and initialized.
> 11:14
>  OK, that would then be a very nice place to get to... the whole framework is just a bunch of Spring-loaded beans.
> Andi, 11:14
>  yep I agree
> 11:15
>  I think it also means that there isn't really any concept of plugins ... or at least, any of these service beans could be replaced by a different implementation with a higher @Order( if required.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)