Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deploy API-X as a servlet filter? #103

Open
birkland opened this issue Jan 18, 2017 · 6 comments
Open

Deploy API-X as a servlet filter? #103

birkland opened this issue Jan 18, 2017 · 6 comments

Comments

@birkland
Copy link
Contributor

birkland commented Jan 18, 2017

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:

  • Verifying that this is indeed possible
  • Add an OSGi framework to the war in order to deploy API-X components, or wire with Spring if not feasible
  • Creating a servlet filter with hooks into the API-X components.
  • Trying it out with the current Fedora impl (in a pattern similar to fcrepo-webapp-plus)
@acoburn
Copy link
Contributor

acoburn commented Jan 18, 2017

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.

@ajs6f
Copy link
Contributor

ajs6f commented Jan 18, 2017

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.

@ajs6f
Copy link
Contributor

ajs6f commented Jan 18, 2017

👍 to the basic idea. This would be a huge win for adoption, I believe.

@ajs6f
Copy link
Contributor

ajs6f commented Jan 18, 2017

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.

@birkland
Copy link
Contributor Author

@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

@ajs6f
Copy link
Contributor

ajs6f commented Jan 18, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants