not sure if this is possible but was wondering if its possible to embed GWAN in spring boot app (like tomcat/jetty etc.) are. and how so?
As far as the Spring Boot documentation tells, the requirements are to package your G-WAN application as a jar (zip) file, and install and configure Spring plugins to connect the dots.
One of them, Gradle, takes 50.5 MB to let you use several programming languages: "Gradle makes the impossible possible, the possible easy and the easy elegant."
G-WAN delivers even more language mix in 200 KB of code. G-WAN works without configuration files, nor it needs any war archives to be built, and deployed each time you edit the code of a Java G-WAN script. G-WAN's philosophy is real-time "edit & play".
With some adjustments, it will be possible to use G-WAN with in a Spring Boot application, but thats' like trying to attach a lorry trailer to a formula one: are the expected gains worth the exercise?
If you see advantages at adding this much code, configuration and maintenance overhead to G-WAN, could you please try to enumerate them?
If you are an advanced Spring developer and you still believe that there's value in this proposition, we will help you by adapting G-WAN wherever needed, providing you or other Spring experts can tell what must be done.
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 like Dart, I have been playing with it for a while. I'd like to integrate with my Maven web app project based on Spring Boot.
I suppose the correct way is to use dart-maven-plugin. But I'm not sure how to properly glue it in place. Spring Boot has its own structure, Maven as well and Dart makes that none the better.
I will need probably the entry point for Dart part, means Spring Boot templates folder needs to include the html resources from Dart.
I would appreciate any idea, best practices.
PS: the aforementioned dart-maven-plugin is not really vivid, should I be afraid using it at all, as I don't see any progress there, compared to Dart itself.
UPDATE
So this can be solution(note I have only one so called "entry point"- .dart file so far)
normal Dart structure in src/main/dart
user dart-maven-plugin's pub build command into ${project.build.directory}/dart
maven-resources-plugin:copy-resources from ${project.build.directory}/dart/web to ${project.build.directory}/classes/public/
make war
I'm still able to use Intellij's Dart integration from src/main/dart.
The Spring Boot maps classes/public/ folder to / so the dart file and html files are loaded properly.
It's not ideal, but it works so far. Please fell free to write down any comments.
I have tried a few times to use dart in a maven project myself and always ran into some problems. Right now I'm developing my dart apps in a separate module that I build with pub which connects to the maven based java backends with rest.
This has several advantages for me, for example:
I can use pub and avoid problems with outdated maven plugins
I use the serving mechanism that fits best for the static dart code and assets (in my case a docker image with nginx)
I have a clean separation of backend and frontend code with a tailored REST API
As I like the microservice approach I also use spring session together with zuul (via spring-cloud).
If you want to combine dart with generated html from for example JSPs or another templating engine, then this isn't a good approach for you. But IMHO dart is not yet very well suited for these kind of architectures.
More of a standard practice questions:
Is there any difference in deploying an app as EAR vs WAR? How do you decide? (I know WAR is just a web application may or may not have Java EE features like messaging)
Lets say I have a Spring MVC application stack with Hibernate (MySQL DB), should this be deployed as a War or EAR?
When do we need to worry about JBoss deployment descriptors, if I am not using EJBs. (Just Spring MVC). Lets assume I have JMS as well. Do we need to configure/update/create any other JBoss related config files?
When we package our application EAR/WAR, it include EVERYTHING that we need for our app. Is there a scenario where we need to keep some config / xml files outside of this archive in a specified JBoss folder?
Is it common practice to deploy directly from Eclipse or better to use Ant, etc? Advantage / Disadvantage?
Obviously, I am a newbie :-). Trying to understand this.
1.
This is not always an easy decision, but for beginners and for small projects I would say it's nearly always a WAR. The reason for using an EAR is mainly to isolate a business layer from a UI/Web layer. See this question for more details: How can one isolate logical layers of an Java EE application
2.
I might be mistaken but I think that Spring people typically prefer WARs.
3.
JBoss (vendor) specific deployment descriptors are mostly needed to configure so-called "administered objects" and security. Sometimes they can be used for extra features that are not covered by the Java EE specification (e.g. setting the web root for a WAR). Administered objects are typically data sources (connection to a database) and JMS destinations (queues and topics).
In the traditional Java EE approach these have to be created as far away from the code as possible, which typically means a system admin would create them inside the target AS using some kind of GUI or admin console. In this setup, you as developer would throw a WAR with "unresolved dependencies" over the wall, and a system admin (or "deployer") would then spend days figuring out what those unresolved dependencies should be.
If the communication is relatively good between developers and deployers, the WAR or EAR might be thrown over the wall together with a readme-file, that at least gives some insight into which resources are needed. Depending on the organization the development team might not get any access or feedback about how those "unresolved dependencies" have been resolved. E.g. a data source with a max of 5 connections may have been created, but this may be insufficient if some code does say 10 parallel queries. Without the development team knowing the exact data source configuration, some classes of runtime problems and performance issues may be relatively hard to solve.
To mitigate these problems, some vendors, for some artifacts, offer the developer to create those "unresolved dependencies" instead using proprietary deployment descriptors which are then embedded in the WAR or EAR. For simple local JMS destinations this is then in most cases the end of it, but for data sources there is a little bit more to it. Namely, there has to be a mechanism to switch between data sources for different stages such as Dev, Beta, QA, Production etc. Additionally, it's rarely a good idea to have production passwords in the source code.
If you have a simple app that you want to try out locally, stages and production passwords are not a concern. If you deploy for a (large) company it is.
In Java EE 6 you can define a data source using a standard descriptor (web.xml, ejb-jar.xml or application.xml), and in Java EE 7 you can do the same for JMS destinations. There is no standard way to configure those based on stage, but there is a glimmer of hope that Java EE 8 will address this (see e.g. JAVAEE_SPEC-19). Vendors are not universally happy with those standardized methods, and their main documentation will almost always extensibly tell you how to do those things using their proprietary tools and descriptors, and if you're lucky as a small note tell you there's a standardized way (and then sometimes downplay that or scare you by saying it's not recommended to be used in production).
4.
See answer to 3 mostly. One option to solve the problem of how to switch between stages and keep production passwords out of the WAR/EAR, is to have the full definition of said data source inside the AS (inside JBoss in your case). Every AS installation is tied to a specific server in this setup. If data sources need to be updated, removed or new ones added, you have to communicate with your operations team (if any). As said, depending on your organization this can be anything between trivial and practically impossible.
5.
When developing you most often use your IDE to do a deployment. For production you would never do that. For production you may build with Ant (or Maven) and deploy via something like Jenkins, or e.g Chef.
Check here : .war vs .ear file
If you read the preceeding response, you'd guess that "WAR" it is.
Deployment descriptor are needed to manage the modules of JBoss, if you don't have any conflict or don't need any tweaking, you won't need any deployment descriptor.
You may need to play with some JBoss file if you want to add modules to JBoss, or configure datasources, etc. Read the JBoss documentation for more info.
You can deploy from eclipse during your development phase, but as your other environments (qualification, production, test, etc) should be separeted from your developing one and that they won't have any eclipse installed on them, you should get used to manage your server from the command line and drop your war's in the right directories.
It's a short answer, but I hope it will help.
Read JBoss documentation for more info.
Am a total beginner with spring framework and trying to know if it even fits my use case, before investing time learning it.
I'm responsible for a stand alone java project(used as a jar by a server) which basically serves requests from a server, and in turn makes service calls to various internal services.
This standalone java project, currently has all of its service calls hard coded. I want to use Spring to inject dependencies so I can make this stuff testable.
I have no idea how spring works. Does it even hold for standalone jars or is it only for 'running applications'?
If I make my standalone project 'spring enabled', when the server uses my jar, will it automagically work by creating beans or is there some requirement from the server side?
In short, yes, you can use Spring in a standalone jar-application ("console application", if you will), we do it all the time at work. You just need to create the ApplicationContext yourself when your application starts, see for example here: http://www.devdaily.com/blog/post/java/load-spring-application-context-file-java-swing-application
This is just one example I pulled straight out of Google, there are probably numerous others. Still, you really need to read at least the basics from the Spring documentation to get started, otherwise you'll probably hit a wall pretty soon.
The current system I am working on uses Tomcat 7.0 and Spring 3.1 the system is a collection of web apps that all have the same classpath in WEB-INF\lib, I am thinking of adding spring 3.1 to my tomcat\lib so that all the web apps have access to it. Is this safe to do with Spring 3.1?
Safe to add Spring 3.1 to the Tomcat main lib directory? Quite possibly. Good idea? Probably not; as the system administrator you'd be taking on the responsibility for ensuring that all the webapps can use that exact version of Spring (including all the issues that can crop up when you update things) because the webapps would not be able to override it to anything else. (To be fair, they could load classes from elsewhere that weren't in the standard system version you're proposing, but that's likely to be an extremely bad idea as there would be problems with warring versions of the same library. That's a very confusing situation to be in; avoid if at all possible!)
As a general rule I only put very basic shared libraries like JDBC drivers in tomcat/lib. Sharing other libraries will often lead to classloader issues in tomcat. Unfortunately, I don't know the publish date of it, but you might find this article http://www.mulesoft.com/tomcat-classpath useful.