Open birkland opened 7 years ago
I would note that while this would lower barriers to entry (an excellent goal!) and it would employ a traditional war-based deployment strategy, this also seems distinctly counter to most trends in application deployment methodologies. That is, rather than piling lots of applications into a single app server (tomcat, jetty, etc), most modern deployment strategies employ other, more scalable/distributed strategies, whether that involves an isolated Docker container or an OSGi container. As long as this move doesn't prevent an OSGi (or containerless) deployment strategy, this is fine.
What @acoburn said, and also that what he says should happen can happen, I believe. We may just be taling abot a bit (okay, a lot) of Maven cleverness.
👍 to the basic idea. This would be a huge win for adoption, I believe.
Using spring for wiring rather than OSGi (due to the absence of an OSGi framework)
Erm. grumble grumble. What about just loading an OSGi framework? They're really not that bulky or heavy. And Spring is... it's not the best thing ever.
@acoburn agreed. JHU (for example) wouldn't have any specific interest in this deployment mode; the high-level stakeholder goals related to scalable/distributed deployments still stand! I also see the docker-based demos as important educational tool which concretely demonstrates API-X as part of a microservice-style architecture in action. That being said, it would be great if a single-war option serves as a stepping stone to help bootstrap adoption or evaluation.
@ajs6f Interesting... if it's tacking on an OSGi container can be done, that'd be great (preferable, even). Edited description
Let's distinguish right now between an OSGi container (say, Karaf, or Eclipse Virgo) and an OSGi framework (say, Apache Felix, or Eclipse Equinox). I'm talking about the latter. I am not talking about shoving Karaf into a webapp, I'm talking about Felix or Equinox, which are considerably smaller and lighter.
It has been discussed previously on API-X calls that it may be possible to expose API-X functionality as a servlet filter, e.g. intercepting and processing requests in a servlet filter pipeline in front of a repository webapp, as an alternative to deploying API-X as a separate piece of network infrastructure. While there are availability and scalability downsides to doing so, it would present an even lower barrier to entry, allowing the creation of war files that bundle API-X and a repository webapp.
This would likely involve: