I am trying to implement an API gateway which has java plugin support. Have analyzed Kong, APIMan, APIsix, of which APIsix seems to be the best fit. But when i am trying to see the java plugin support, the github for java plugin runner displays as "This project is currently considered experimental."
https://github.com/apache/apisix-java-plugin-runner
So wanted to check with community, if that plugin is experimental and is there any other way to use ApiSix for production with java plugins enabled.
Anymore options for java enabled plugin API gateways are also welcomed.
So I'll quote out the reply that I had received for the same question on the slack channel from one of the maintainers of the project, for reference.
In fact, from some information I’ve gathered, there are already some users using it in production environments.
I can’t give an answer about whether it should be marked as production-ready or not. Here are some facts.
the design pattern, API interface and custom development approach of this project has not changed significantly since its inception, and should not be a major upheaval in the future, as it follows some common gateway design approaches in the Java world.
it is currently used in a rather primitive way, requiring clone project source code, but in the Java world, mature projects should import dependencies and use them by defining GAV in the dependency file.
Based on this, I think it is now production-ready in terms of stability, but not enough on other levels.
Apache APISIX Slack channel has the same question, link: https://the-asf.slack.com/archives/CUC5MN17A/p1653908139962639
Back to this question: Java Plugin Runner is used in production by some community users.
Here's the thing, from what I know, It has been used in a production environment in China(You can refer to this from the community bio-weekly talk).
So I would suggest you can try it.
Also, the plugin is still relatively easy to suit and I think could be better customized to suit your needs.
Related
Let me preface this with the fact that I am still very new to Apache Camel. I'm still trying to understand how it all works, and what needs to be done (and HOW to do it) to achieve a particular effect.
I am trying to develop a Spring Boot application that will use Apache Camel to handle the transmission (and possibly also receipt) of data to/from a number of possible sources and destinations. The purpose of the application is to provide a means to produce/generate network traffic, at the network application level, that will be fed into another Spring Boot application - let's call this the target. We are trying to observe and measure the effects various network loads have on the target.
We would like to be able to transmit data via a number of protocols, including: ftp, http/s, file systems (nfs), various mail protocols (smtp, pop) and data streaming protocols for voice and video. There may be other protocols added at a later time. The data itself is irrelevant, we just need to be able to transmit data via various protocols with various loads.
These applications/services will be running in a containerized environment (Docker) that will be run within our local development and test environment, as well as possibly in a cloud environment, such as AWS. We have used Docker, Ansible, Terraform and are currently working towards using Kubernetes and Istio to manage the configuration, deployment, and operation of these applications.
We need to be able to provide specific configurations of Camel routes for particular deployments.
It would appear that the preferred method to configure Camel routes is via Java DSL, rather than XML DSL. The Camel documentation and nearly every other source of information I've found have a strong bias towards using Java DSL. Examples of XML DSL route configuration are far and few.
My initial impression is that going the Java DSL route (excuse the pun), would not work well with our need to be able to deploy a Camel application with a specific route configuration. It seems like you are required to have Java DSL defined route configurations hardwired into the code.
We think that it will be easier to provide a specific route configuration via an XML file that can be included in a deployment, hence why I've been trying to investigate and experiment with XML DSL. Perhaps we are mistaken in this regard.
My question to the community is: Considering what I've described above, can the Java DSL approach be used to meet the requirements as I've described them? Can we use Java DSL in a way that allows for dynamic route configuration? Keep in mind we would not be attempting to change configuration during operation, just in the course of performing a deployment.
If Java DSL could be used for this purpose, it would be very much appreciated if pointers to documentation, examples, etc. could be provided.
For your use cases you could use XML DSL also. Anyhow below book covers most aspects Camel development with examples. In this book authors describes XML DSL use for most of java DSL examples.
https://www.manning.com/books/camel-in-action-second-edition
In below github repository you can find the source code for all the examples listed in above book.
https://github.com/camelinaction/camelinaction2
Simple tutorial and github repository for Apache Camel using Spring boot.
https://www.baeldung.com/apache-camel-spring-boot
https://github.com/eugenp/tutorials/tree/master/spring-boot-modules/spring-boot-camel
Maven Plugin for build and deployment of spring boot container application into Kubernetes cluster
https://maven.fabric8.io/
In case if your company can afford some funding for your effort look at below link which provides commercial offerings around Camel.
https://camel.apache.org/manual/latest/commercial-camel-offerings.html
Thanks
Madhu Gupta
Our team has a few projects which use the Java DSL for building routes. In order to make them dynamic, there are control structures for iterating and setting endpoints based off configurations. That works for us because the routes are basically all the same, just with different sources and sinks.
If you could dynamically add/change the XML DSL files in a way that doesn't involve redeploying your application, that might be a viable route to follow. One might, for example, change the camel.springboot.xml-routes property to point to a folder which changes as needed.
I am working on bringing up a new team in the Spring Boot ecosystem. I love the Spring Initializr service. We have written custom Gradle plugins for unifying our build systems across many Spring Boot projects. I am looking to provide our team with an Initializr that will take advantage of our build tooling as well as inject some of our business practices into the scaffolding of the project.
With these goals in mind we have decided that extending the wonderful Spring Initializr and running a custom instance locally makes a lot of sense.
Unfortunately, it appears that the Initializr project has very little documentation about customizing it, beyond the basics of editing the YAML configuration and the Templates for the java files, it is difficult (for someone with no Groovy Templating experience) to figure out how to best extend the Initializr such that we maintain much of the functionality but can also extend the site and service appropriately.
We have built the github project from source, and published the artifacts to our local artifactory, and have successfully created our own project that uses those artifacts as a dependency and stands up a mildly customized service (basic HTML and Java source editing, simple YAML configuration).
Can anyone help with even basic resources for extending the functionality of the Initializr? perhaps a roadmap? a project specific forum? really any help is appreciated, my google-foo seems to be failing me.
I know this is a reasonably broad question, but I am failing to get in touch with the right people, or find the resources for this.
So the answer is indeed Gitter. Spring Initializr should be seen at the moment as a service and not a library. We do our best to make sure things are nicely separated but that's not the case yet for everything (read: designed for extension).
We have some plans to allow external components to customize how the project is generated. It would help if you could share your use cases on the gitter channel. Thanks!
Does anyone know what the state is of the Spring Integration Extensions at https://github.com/spring-projects/spring-integration-extensions ?
Some seem outdated with regards to Spring versions. And others, whilst updated, don't seem to have recent releases or snapshots available at http://repo.spring.io/libs-snapshot/org/springframework/integration/ .
For example I wanted to integrate with AWS, but cant find a release or snapshot for the latest version of Spring Integration. And SQS support has been "coming soon" for some time.
The outdatedness of those that do exist, and lack of clarity on what is intended, make me concerned to use any of them. Does anyone know what the Spring team's intention is with regards to the release cycle of these extensions? Are they viewed as incubators that will eventually move into Spring Integration core, or something else?
Cheers,
Menno
Spring Integration extensions are community provided, and they will constantly change according to the will of the community. Your best chance is to get in touch with the contributors of the AWS extension.
You should use them, once you understand what they are doing, there are no more guarantees than other Spring projects, only the fact that others are also using it.
Has anyone integrated Spring Dynamic Modules (or Eclipse Gemini Blueprint) with Netbeans Platform? I cannot find any information on this.
I was thinking about potential use of Spring Services within the Netbeans Platform Application. Is this reasonable?
Thanks!
I don't know anything about Spring Dynamic Modules, but as long as it produces regular Spring services and DAOs, it's totally do-able. I outlined the process in this post. I am now also considering writing up a blog post complete with code examples on this topic since this seems to be a common issue. I'll update this answer with a link as soon as I'm done.
I have been trying to understand a bit more about the wider picture of OSGi without reading thru the entire specification. As with so many things, the introduction to what OSGi actually is was probably written by someone who had been working on it for a decade and perhaps wasn't best placed to put themselves in the mindset of someone who knows nothing about it :-)
Looking at Felix's example DictionaryService, I don't really understand what is going on. Is OSGi a distinct instance of a JVM into which you load bundles which can then find each other?
Obviously it is not just this because other answers on StackOverflow are explicit that OSGi can solve the dependency problem of a distributed system containing modules deployed within distinct JVMs (plus the FAQ keeps talking about networks).
In this latter case, how does a component running in one JVM interact with another component in a separate JVM? Can the two components "use" each other as if they were running within the same JVM (i.e. via local method calls), and how does OSGi manage the marshalling of data across a network (do you have to use Serializable for example)?
Or does the component author have to use some other distinct mechanism (either provided by OSGi or written themselves) for communication between remote components?
Any help much appreciated!
Yes, OSGi only deals with bundles and services running on the same VM. However, one should note that it is a distinct feature of OSGi that it facilitates running multiple applications (in a controlled way and sharing common modules) on the same JVM at all.
When it comes to accessing services outside the clients JVM, there is currently no standardized solution. Paremus Infiniflow and the derived open-source project Newton use an SCA approach. The upcoming 4.2 release of the OSGi specs will address one side of the problem, namely how to use generic distribution software in such a way that it can bring remote services into the client's JVM.
As somebody mentioned R-OSGi, this approach also deals with the other side of the problem, being how to manage dependencies between distributed OSGi frameworks. Since R-OSGi is not generic distribution software but explicitly deals with the lifecycle issues and dependency management of OSGi bundles.
As far as I know, OSGi does not solve this problem out of the box. There are OSGi-bundles, for example Remote OSGi, which allow the programmer to distribute services across a network.
Not yet, i think it's being worked on for the next release.
But some companies have already implemented distributed osgi. One i'm aware of is Paremus' Infiniflow (http://www.paremus.com/products/products.html). At linkedin they are also working on this. More info here: Building Linkedin next gen architecture with osgi and here: Matt raible: building linkedin next gen architecture
Here's a summary of the changes for OSGI 4.2: Some thoughts on the OSGi R4.2 draft, There's a section on RFC-119 dealing with distributed OSGi.
AFAIK, bundles are running in the same JVM, but are not loaded using the same class loader (that why you can use two different versions of the same bundle at the same time).
To interact with components in another JVM, you must use a network protocol such as rmi.
The OSGi alliance is working on a standard for distributed OSGi:
http://www.osgi.org/download/osgi-4.2-early-draft2.pdf
There even is an early Apache implementation of this new standard:
http://cxf.apache.org/distributed-osgi.html
#Patriarch24
The accepted answer to this question would seem to indicate otherwise (unless I'm misreading it). Also, taken from the FAQ:
The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring a restart
(Emphasis my own). Although in the same FAQ it describes OSGi as in-VM.
Why am I so confused about this? Why is such a basic question about a decade-old technology not clear?
The original problem of OSGI was more related to distribution of code (and then configuration of bundle) than to distribution of execution.
People looking at distributed components are rather looking towards SCA
The "introduction" link is not really an intro, it is a FAQ entry. For more information, see http://www.osgi.org/About/WhatIsOSGi Not hard to find I would think.
Anyway, OSGi is an in-VM SOA. That is, the OSGi Framework is about what happens inside the VM, it provides a framework for structuring your application inside the VM so you can built it too a large extent from components. So the core has nothing to do with distribution, it is completely oblivious of who implements the services, it just provides a mechanism for modules to meet each other in a loosely coupled way.
That said, the µService model reifies the joints between the modules and it turns out that you can build support on top of the framework that provides distribution to the other components. In the last releases we specified some mechanisms that make this standardized in the core and provide a special service Remote Service Admin that can manage a distributed topology.
If you are looking for a distributed OSGi centric Cloud runtime - then the Paremus Service Fabric ( https://docs.paremus.com/display/SF16/Introduction ) provides these capabilities.
One or more Systems each consisting of a number of OSGi assemblies (Blueprint or Declarative Services) can be dynamically deployed and maintained across a population of OSGi runtime Frameworks (Knopflerfish, Felix or Equinox).
A light weight RSA remote framework is provided which provides Service discovery by default using DDS (a seriously good middleware messaging technology) - (thought ZooKeeper and other approach can be used). Currently supported re-moting protocols include RMI and Avro.
Regards
Richard