I wrote an application which uses a SQLite database, now I want to extend the apllication with a webinterface.
Since I want everything to be in one application with no need to set anything up or install something else I plan to embed Jetty in the application and then install some CGI servlet to use PHP.
The application and the website should be able to modify the database.
This is most likely not to be accomplished with SQLite.
What ideas do you have to accomplish this? Important is that everything can be integrated into one application.
Ensure you access the database only via a javax.sql.DataSource definition from JNDI, and you are golden, as both sides, both the Application and the WebApp will have the same access patterns, techniques, rules, etc ...
Related
We are trying to deploy Camundas webapplications as standalone spring-boot application and also deploy .bpmn diagram and engine in another stand alone Spring-boot application. But only connect the two SB-apps via a shared DB or REST-calls, and still be able to update the task through Camundas webapplications.
We have managed to deploy them and connect them to a file based H2 database. So now we can do rest-calls to the .bpmn Spring-boot app and submit forms etc. and then make it show in the Webapps-tasklist/cockpit.
The problem is that if we try to submit the form through the tasklist, we get an error that it’s trying to look for a javaclass (which we have implemented in the engine-SB-application but not in the Webapplications-SB-application).
Is there any way to make it so that we can use the web-apps-tools and submit the form from there (without changing that the .bpmn diagram uses java-classes)?
Either through making the webapps update the database, or maybe through REST-calls?
We solved it by using Asynchronus Continuation.
A very good video about can be found here:
https://www.youtube.com/watch?v=Nx4I8lNMUs0
Hi I'm sorry for the naivety of this problem but I need some guidance as I have confused myself greatly.
I have been tasked with creating a database(mysql) and creating a web interface for i to be interacted with. I have experience with web design and database development. Previously I have used java to interact with a DB and was hoping I could use JSP for the web interface. This is where my problem is, how I would I deploy/host this website?
I have 2 theories which are misguided:
(A). Use a cms which has a web server for me to place the jsps in?
or
(B). Use a domian/web hosting site that has a server for me to place the jsps in?
I'm totally lost and any guidance would be greatly appreciated.
Simple answer is you will require a Java Application Server to host your JSPs.
You can use Apache Tomcat, GlassFish, or some other application server to do this.
You will also need a database e.g MySQL running on your host or some other host accessible by the machine running the Java application server.
You can choose to host all of this locally or farm it out to a web host provider depending on your resources.
A CMS seems like overkill. See this link for a description of CMS and its functionality. I don't believe this is what you are looking.
I don't know exactly what you're looking for, but I think you need (B)
You need a MySQL instance running your database and a servlet container (e.g. Tomcat) to host your JSPs.
Running a CMS which is just used to use the DB that it works with is a little bit heavy for that usecase.
As suggested by Mr #cmd , yes there is no need to go for an outsourced server just to host your website, unless you need it to be visible to the world.
Else for your testing purpose, you can use Any of the Apache Tomcat, Glassfish servers for hosting the applications designed in JSP or in other web interface language.
And Inside of the JSP coding itself you may write the interaction coding with your database.
your database also can be installed in the same server.
And actually instead of a server, you may even use your PC to install the Apache Tomcat and the database and start using it.
I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.
If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.
It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.
I am developing a web application and this web application is to be sold to many people. The application is being developed in Java Spring. The application has a database and when sold this database could be on different locations.
Where is the best way to store this database location so the Java code can find the database?
I would store it in a XML file but where would it go, so that the database location can be changed easily by someone.
I don't want to store it in the Spring Beans. Is there another way?
The problem is that it's a web application, which suggests that you'll give them a WAR file. All the Spring configuration and properties will be packaged; changing something will mean opening the package, which you don't want them to do.
You should set up database access using JNDI names, which are set on the app server the package is deployed to. Give instructions to show how to set one up for Tomcat and other app servers. When your app starts, it'll get the data source name from the app server.
You're assuming that they'll be sophisticated enough to be able to create a JNDI data source on their app server or that your documentation is good enough. Good luck with that.
Another thought would be for you to create a small in memory database like Hypersonic or Derby that comes with configuration information for your app. Tell users to put it in a location outside the app that you specify (e.g. c:/yourApp/configuration), provide a script to start it up when the app starts, and let your application query for database connection information when it loads.
Now you'll be counting on them knowing how to create INSERT or UPDATE queries for your in-memory database. But your chances of writing documentation to instruct how to do it are better, because you don't have to figure out how to do it for WebLogic, Tomcat, Jetty, JBOSS, WebSphere, Glassfish, and every other Java EE app server.
I've read some articles on the Internet that this is not possible. To communicate own SQL database that is located on other server from GWT application. Jetty doesn't allow it.
I found a way how to perform it but it's not very cosy. I have client and server part inside GWT. The server has to communicate with MySQL database on localhost. So I've written an ant script to build a war that I can launch on Apache Tomcat server. It works perfectly there but I'm not able to debug the code effectively.
Do you have some advices how to perform this task? I was thinking of writing the clienty only in GWT and find some waz how to communicate my own server written outside the GWT. I've found Apache Thrift for GWT but this edited library of thrift seem not to work properly.
Thank you very much for your answers:)
It is possible to communicate with a database from a GWT application. The client side has to call the methods of the server via GWT-RPC, which can communicate with any database.
Maybe Jetty does not support it (have not tested it personally) but you can develop your web application using Apache too. There you can access the database the same way as from any web application:
You will need the mysql-connector-java-5.1.20-bin.jar file (downloadable from: http://dev.mysql.com/downloads/connector/j/ ), and restart the server added to the $CATALINA_HOME/common/lib directory.
OR added to the WEB-INF/lib folder of your web application.
You can find tutorials online of how to develop an application using Tomcat instead of Jetty. For example: https://wiki.auckland.ac.nz/display/BeSTGRID/Deploying+GWT+to+Tomcat+in+Eclipse
Reshi, stop and think about how applications really work. Nobody provides web pages with javascript to read/write databases, that would be crazy and unsecure. Servers are always in themiddle of all communication in this case. You need to create services that run inside your server, one of these services will be a database layer.
Javascript cant create network connections and read/write binary data, thus it would be insane to attempt to get the gwt compiler to compile any jdbc drvier and more.
Jetty does NOT stop us from connecting to a database. All you have to do is to follow the MVP model way. Although MVP is better bet against all hurdles, at a minimal point, you would have to try not having SQL code on the client package.