I made a GAE-Project with JPA2 for db access. I store some Strings which are more than 500 Characters, so I use com.google.appengine.api.datastore.Text.
I got an interface Script.java which defines the value as String, and an ScriptImpl.java which has internally a Text member, and converts for getting and setting.
Because one requirement of the project is, that it is still able tu run on an simple tomcat with a database behind. So it must be possible to run inside and outside the google environment.
Is there some realistic way to implement my application so I can switch to a normal tomcat environment (e.g. via a spring configuration to use different beans...).
What else do I have to pay attention to to make this work in both environments and how do I take care of the parts that are seamed thight to GAE?
Update: So far I found the following critic issues: Google User Service & Login Process, Text Class in Domain Models, Wicket-GAE-Initializer (since I use Wicket)
GAE has it's own proprietary API. If you wrote application using this API then if you want to move off of the GAE you have two options:
Rewrite your code, obviously.
Use a API wrapper that implements GAE API but runs on other platforms. An example of such wrappers are AppScale and CapeDwarf. AppScale is older and probably more mature and supports both Java and Python. Also it supports more platforms (private servers + clouds). OTOH, CapeDwarf is targeted at JBossAS7, so it's probably better fit if you use that server (or OpenShift cloud). Also I guess you can expect better support from a mature open-source leader such as RedHat.
While in theory it might be possible to wrap GAE functionality and then delegate it to either app engine or your "normal" environment it's probably a lot of effort.
Possibly another approach would be easier. Are you aware of CapeDwarf?
JBoss CapeDwarf
Deploy and run your Java App Engine applications on your own private
JBoss Application Server (AS7) cluster or on RedHat’s OpenShift cloud.
JBoss CapeDwarf is an implementation of the Google App Engine API,
which allows applications to be deployed on JBoss Application Servers
without modification. Behind the scenes, CapeDwarf uses existing JBoss
APIs such as Infinispan, JGroups, PicketLink, HornetQ and others.
If it really needs to be "simple tomcat with a database" then more information or constraints will be helpful to know.
Related
I'm going to develop a map server with my own logic and entities. It will have postgres database, user management, specific layers with certain types, WFS, WMS, etc.
I'm going to use springframework and GeoServer as the GeoServer is an open source project. My question is whether I develop it or use it as a separated server? How about the user management problem? How can I integrate my own project security with the geoserver?
Typically you develop a front end that's completely separate and have GeoServer offer the OGC services to it and other clients. In case you need to customize it, GeoServer has a fully pluggable architecture, e.g., you can build a version of it that has more or less modules than the standard one, your own security subsystem, your own custom data sources, and so on, a lot can be either configured or replaced, so I'd suggest you look into those options.
Mind one detail, GeoServer is GPL'd, so any code you develop that depends on GeoServer API will similarly be GPL'd. If instead you develop something that's only based on GeoTools (e.g., a custom data store) that part can be closed source.
There seems to be a current trend in java space to move away from deploying java web applications to a java servlet container (or application server) in the form of a war file (or ear file) and instead package the application as an executable jar with an embedded servlet/HTTP server like jetty. And I mean this more so in the way newer frameworks are influencing how new applications are developed and deployed rather than how applications are delivered to end users (because, for example, I get why Jenkins uses an embedded container, very easy to grab and go). Examples of frameworks adopting the executable jar option:
Dropwizard, Spring Boot, and Play (well it doesn't run on a servlet container but the HTTP server is embedded).
My question is, coming from an environment where we have deployed our (up to this point mostly Struts2) applications to a single tomcat application server, what changes, best practices, or considerations need to be made if we plan on using an embedded container approach? Currently, we have about 10 homegrown applications running on a single tomcat server and for these smallish applications
the ability to share resources and be managed on one server is nice. Our applications are not intended to be distributed to end users to run within their environment. However, moving forward if we decide to leverage a newer java framework, should this approach change? Is the shift to executable jars spurred on by the increasing use of cloud deployments (e.g., Heroku)?
If you've had experience managing multiple applications in the Play style of deployment versus traditional war file deployment on a single application server, please share your insight.
An interesting question. This is just my view on the topic, so take everything with a grain of salt. I have occasionally deployed and managed applications using both servlet containers and embedded servers. I'm sure there are still many good reasons for using servlet containers but I will try to just focus on why they are less popular today.
Short version: Servlet containers are great to manage multiple applications on a single host but don't seem very useful to manage just one single application. With cloud environments, a single application per virtual machine seems preferable and more common. Modern frameworks want to be cloud compatible, therefore the shift to embedded servers.
So I think cloud services are the main reason for abandoning servlet containers. Just like servlet containers let you manage applications, cloud services let you manage virtual machines, instances, data storage and much more. This sounds more complicated, but with cloud environments, there has been a shift to single app machines. This means you can often treat the whole machine like it is the application. Each application runs on a machine with appropriate size. Cloud instances can pop up and vanish at any time which is great for scaling. If an application needs more resources, you create more instances.
Dedicated servers on the other hand usually are powerful but with a fixed size, so you run multiple applications on a single machine to maximize the use of resources. Managing dozens of application - each with their own configurations, web servers, routes and connections etc. - is not fun, so using a servlet container helps you to keep everything manageable and yourself sane. It is harder to scale though. Servlet containers in the cloud don't seem very useful. They would have to be set up for each tiny instance, without providing much value since they only manage a single application.
Also, clouds are cool and non-cloud stuff is boring (if we still believe the hype). Many frameworks try to be scalable by default, so that they can easily be deployed to the clouds. Embedded servers are fast to deploy and run so they seem like a reasonable solution. Servlet containers are usually still supported but require a more complicated set up.
Some other points:
The embedded server could be optimized for the framework or is better integrated with the frameworks tooling (like the play console for example).
Not all cloud environments come with customizable machine images. Instead of writing initialization scripts to download and set up servlet containers, using dedicated software for cloud application deployments is much simpler.
I have yet to find a Tomcat setup that doesn't greet you with a perm gen space error every few redeployments of your app. Taking a bit longer to (re-)start embedded servers is no problem when you can almost instantly switch between staging and production instances without any downtime.
As already mentioned in the question, it's very convenient for the end user to just run the application.
Embedded servers are portable and convenient for development. Today everything is rapid, prototypes and MVPs need to be created and delivered as fast as possible. No one wants to spend too much time setting up an environment for every developer.
I am looking at the Java Portlet API for the first time and trying to decide on whether or not to consider using it.
From the look of things, it looks like a technology that might be considered old school because i seem not to see very current references of its usages.
My question is, would you consider using the Java Portlet API, more so when you are planning to develop an integrated web application consisting of modules that may themselves be separate applications of their own.
Yes
Normally we go for a Portal application (using Portal API) in scenarios like this:
Multiple application(Portlets) in same page.
Multiple applications in separate pages but uses same Login(or User credentials).
Multiple applications which communicate to each other in same page or in different page.
These are just highlevel thoughts. Based on the application and available server stack, the Portal server can be chosen IBM Websphere Portal / Liferay / Weblogic Portal.
Portals are good at providing a common set of services, such as security and UI, to wrap around several applications that have a need to either pass information between them, or a need to be utilized as part of a similar process.
It's worth noting that there is also the JBoss Portal Platform, in addition to those above.
Also, there is a new version of the Portlet specification currently in development: http://jcp.org/en/jsr/detail?id=362
I'm carrying out a feasibility study on writing, let's say it's a lightweight run-in-browser MMORPG. (It's not exactly an MMORPG, but would take longer to explain, and the requirements are similar.) I'm trying to figure out the required technology stack.
Client side, it runs in the browser, so the client is Javascript. That was nice and easy :-)
Server side, I'm looking at Java. The common Lamp stack was designed for RESTful applications, as I gather were typical Java web frameworks, and this application is different - it needs a continual stream of data going back and forth between the server and all the clients. I think what I need in this case is Java of the non-framework, full no-holds-barred Java EE variety, someone please correct me if my understanding is incorrect or incomplete? I would need something that is commonly available on reasonably cheap hosting, Java EE fits this description, right?
(Figuring on using MySQL for the database, as this is what's most commonly available. Also I might actually write the code in Scala, being a Java-compatible but supposedly slightly nicer language. I assume neither of these makes any difference?)
Supposing I were writing a website in Lamp, doing at least the initial development on Windows, then I'd install Xamp, which gives you a running copy of the entire server stack right there on your desktop, so you can just alt-tab back and forth between your editor/IDE and browser for testing.
Now my question is: What's the best equivalent setup for Java, for developing something like this on Windows?
Right, in a sense it is. What I think I'm really saying is that almost all discussion of server-side Java seems to talk about JSP, EJB, Glassfish, Google app server etc which are frameworks in the sense that they put restrictions on what your code can do, whereas Java EE puts no such restrictions, you can use as much or as little of the standard library as you want, but it doesn't stop you running arbitrary persistent Java code. Is that correct?
You've thrown out a bunch of terms there:
Glassfish is an application server that implements (all of) Java EE.
JSP is a specification that is part of Java EE, and implemented by application servers such as Glassfish as well as web servers such as Tomcat and (I think) Jetty.
EJB is another specifications that are part of Java EE. It is typically implemented by application servers.
"Google app server" is really "Google Application Engine" (GAE), and is really a platform for implementing web servers in a cloud computing environment. If that's not what you want / need to do, GAE is probably a blind alley for you.
Glassfish, JBoss, Tomcat, Jetty and so on are all platforms that implement some or all of Java EE. None of them stop you implementing arbitrary persistent Java code.
GAE on the other hand does restrict what you can run, because the platform only allows you to run standard Java classes in a whitelist. If your "arbitrary" code depends on other standard Java classes, you are out of luck. (And hence my warning about blind alleys.)
And of course, there are various other Java-based frameworks that are targeted at web development in one form or another. Some are compatible with Java EE servlets and other EE technology, and some have gone off in a different direction.
My recommendation would be to start with something straight forward using plain servlets on a stock platform. Only look at the high performance stuff if and when performance looks like it will be a real concern (not just a "nice to have"). It is better to have a simple and non-scalable prototype, than a high performance solution that you don't have the time and skills to get working. And you can treat the prototype as a learning exercise.
A little hard to tell from the requirements given, but I would look at the following based on your description:
http://www.playframework.org/
http://www.zkoss.org/
http://code.google.com/webtoolkit/
Play Framework is a nice web-centric framework that provides a complete stack (you can code in Java or Scala). ZKoss (ZK) and GWT both provide user interface frameworks. ZK, GWT, and Play all run nicely in Tomcat/MySQL and should work just fine in typical Java/MySQL hosting environment.
... not sure what your definition of 'cheap' is but, that and 'no holds barred Java EE' don't exactly go together. Also, 'frameworks' by themselves don't put restrictions on running any arbitrary java on the server side. When I say 'frameworks' I mean Spring, Struts, etc. Servers will be a little different story. If you need EJBs you'll need Glasfish or JBoss or another EJB compliant container. Hosting with these will be more expensive compared to getting by with Tomcat. IMHO easiest and quickest way to get started is with NetBeans. Comes with Tomcat and / or Glassfish out of the box, all you need is a db.
I'll need to develop a Java service that is simple because:
It only communicates via a TCP socket, no HTTP.
It runs on a dedicated server (there are no other services except the basic SSH and such)
Should I make this a standalone service (maybe in something like Java Service Wrapper) or make it run in a container like Tomcat? What are the benefits and detriments of both?
If you aren't working with HTTP, you will have to build your own connectors for Tomcat. When I've written these types of applications, I've just written them as standard Java applications. On Windows machines, I use a service wrapper that allows them to be part of the Windows startup process. On non-windows machines, you just need to add a start up script.
Using a container (regardless which) buys you that all the details about starting, stopping, scaling, logging etc, which you have to do yourself otherwise, and it is always harder than you think (at least when you reach production).
Especially the scalability is something you need to consider already now. Later it will be much harder to change your mind.
So, if somebody already wrote most of what you need, then use that.
Tomcat doesn't sound like a good choice for me in your situation. AFAIK it's primarily made for Servlets and JSPs, and you have neither. You also don't need to deploy multiple applications on your app. server etc. (so no benefit from ".war").
If you need dependency injection, connection pooling, logging, network programming framework etc., there are a lot of good solutions out there and they don't need tomcat.
For example, in my case I went for a standalone app. that used Spring, Hibernate, Netty, Apache Commons DBCP, Log4j etc. These can be easily setup, and this way you have a lot more freedom.
Should you need a HTTP server, maybe embedding Jetty is another option. With this option too, you have more control over the app. and this can potentially simplify your implementation compared to using a tomcat container.
Tomcat doesn't really buy you much if you don't use HTTP.
However, I was forced to move a non-HTTP server to Tomcat for following reasons,
We need some simple web pages to display the status/stats of the server so I need a web server. Java 6 comes with a simple HTTP server but Tomcat is more robust.
Our operation tools are geared to run Tomcat only and standalone app just falls off radar in their monitoring system.
We use DBCP for database pooling and everyone seems more comfortable to use it under Tomcat.
The memory foot-print of Tomcat (a few MBs) is not an issue for us so we haven't seen any performance change since moved to Tomcat.
A container can save you from reinventing the wheel in terms of startup, monitoring, logging, configuration, deployment, etc. Also it makes your service more understandable to non-developers.
I wouldn't necessarily go for tomcat, check out glassfish and germonimo as they are more modular, and you can have just the bits the need, and exclude the http server.
We faced a similar decision a while back, and some parts of the system ended up being jsw based, and the others as .war files. The .war option is simpler (well more standard for sure) to build and configure.