We Keep Coding

Inject implementation of interface from dependent (plugin) JAR?

I have an interface A with a method Result doAction(Param param). I have a Spring application that will use implementations of the interface and call doAction() on it.
But the application does not define an implementation itself. The idea is that other people can provide their own implementations of the interface in JARs (plugins), the main application will pull those in as dependencies, and call doAction() on the JAR's implementation.
Any idea how I can do this in practice? The ideas I had were:
Try to autowire the implementation through Spring Boot, but for that I would need to know its package and add it to the component scan. So it would mean putting requirements on the naming of the "plugin" jar. Something I would prefer not to do.
With plain Java my first idea was to keep a registry of implementations (e.g. a Set<Interface A>), but the plugin wouldn't be able to access the registry -- it would be a dependency cycle.
What I'm doing right now is defining a Rest API that the "plugin" needs to implement, deploy the plugin in the same environment and the main application just makes the calls through the Rest API.
But for performance reasons I'm looking for a solution with more direct calls that doesn't involve communication over the network. Any suggestions?

Is there a way to 'alter' beans.xml without redeploying a WAR?

I'm packaging a WAR with multiple implementations of an interface. I have one implementation with no qualifier (i.e. #Default) and one with #Alternative. I'd like to know if there is an easy way (without editing the WAR itself) to change beans.xml to point to the alternative implementation, without having to package/deliver two different WAR files. If it's of any interest, I'm using JBoss EAP 6.4.
If not, what would be the best approach? I guess I could provide a property file where they can choose an implementation. I can then use #Inject #Any Instance<Intf> and match the correct implementation during server startup.
Edit:
The end goal is to be able to use the alternative implementation, even though it's not explicitly added in beans.xml alternatives.
The reason for this requirement is that the same service might be interfacing with different versions of the external system. I want to deliver the default, latest adapter implementation by default. At the same time, customers should be able to fallback to an older implementation if needed.

Problems with Dependency Injection

I'm new in Java EE and I have a problem which I have not yet resolved.
I'm working on a Java EE project, which has an EJB project, a project that contains a Web service and another project with a visual interface (Web application).
The problem is when I try to make a dependency injection from one of my web service interfaces to the user interface (web application project). First I would like to clarify that all injections by tags never worked and tried the method: InitialContext.doLookup (name); and this worked great.
I was able to get the implementation of my interface but when I make a call to one of its methods that returns the object, the returned object comes with all its fields empty. And when I test the service from a client created by me this returns the object with all values. I checked beforehand that all classes and objects were implementing the Serializable interface.
My question is: Why do the methods of the service implementation, which I inject in my web application project, return empty objects?
I am using:
Eclipse
Glassfish Server
JAXB(to Web Services)

I apologize for taking so to respond, I would like to tell you that I could solve the problem and would like to make a comment about the problem I had.
I'm working on a project JavaEE as I said. This project contains an EJB module, an EAR project, a web service and a dynamic web project. First I would like to clarify that projects were made by someone else and I'm continuing the work. I may discover that the problem was that they had the persistence within the EJB project, which is not bad but when generating entities rather than keeping them within the project that contains the persistence, the developer moved them to another project called "Utils" and it included in the EAR as another application module. Everything seemed to work well with instances of entities but apparently the project that contains the persistence (EJB) did not have the physical entities in their packages and therefore was not able to build and fill these data when a request was made by injection.
I want to thank you for your concern and quick response.
Regards.

How should I design a plugin system in a layered Java EE Application?

I have a Java EE based REST api application. It has a layered architecture like the following:
Resources (Jax-rs resources)
Object Validation
Object Mapper
Service Layer
Repository Layer
JPA Entities
Everything is wired using Spring dependency injection.
I need to design this core application in such a way that it allows other external developers to write extensions/plugins and override or extends any minor or major functionality in the core. Think of it like Wordpress CMS in Java EE if that helps. How would you design a plugin system around the current architecture?
One obvious way that I can think of is override or add new functionality to the proper resource (with validation, objectmapper), service, repository and entity and create a jar + xml out of it. But I want to make sure that the plugin developer has to write the absolutely minimum amount of code to get the new functionality working, while reusing mush of the core code.
Assume, you want to create a wordpress blog post extension that lets you create blog posts with few extra fields that don't exist in core yet. What would be the simplest and cleanest way to go about designing the current Java EE app, so its easy for the plugin/extension developers? Any patterns that could be useful like strategy or template method pattern?
Are there any open source Java CMS that follow the model using Spring/JPA and standard technologies?

I think you mean to extend the functionality, rather than override the core. Typical architecture examples define concerns which can be overridden (separate from core) and make provisions. Eclipse framework achieves this using a combination of plugin-extensions & extension-points mechanism. This is taken further using OSGI bundling.
Another alternative is to breakdown the application into smaller independent modules/services. All you need to do is host these modules over an ESB/Application Integrator (like Mule/Spring Integration) and allow users to configure their version of routing/transformation. Extension would mean creation of new transformers which get added to the message flow.

java question on jar dependencies

I have a project that its main part (e.g. main.jar) depends on libraries (e.g. u1.jar, u2.jar etc) that has been created as distinct separate projects.
So one could reuse the library elsewhere i.e. there is no dependency between the utility libraries and the main part.
The main part has dependencies on the libraries of course but this is ok.
Now I need to add a specific functionality in one of the libraries.
The needed functionality is already implemented.
It is implemented via a spring bean and the user can configure how the implementation will behave at runtime.
The spring application context is created and used only via the main project and so I do not have access to the spring context
from the utility libraries.
The problem is that I would like to reuse this implementation (and not duplicate the code) and it is not possible to move that part elsewhere
What comes to mind is to create a dependency in this specific util jar to refer to the main.jar.
I will do this to be able to have access to the spring context from the utility jar as well.
What concerns me is that now, I have a cyclic dependency between main.jar and util.jar.
I.e. main.jar already depends on util.jar and now I will create a reverse dependecy as well.
Is this a good idea to do it? Or am I into trouble (class loading issues etc)?
Is there a nice approach for these kind of issues?
Thanks

create an interface and let util.jar work with interface with main.jar passing the implementation which simply wraps this context?
cyclic dependency looks like a nightmare. Which one will you build first?

Once you see that you have cyclic dependency, you know that you have something wrong in the design. Have you thought about if you can apply the Observer Pattern ? Or try to read this one about Acyclic Relationships