I am developing a web application using JSP, but it seems that Java EE is very big for my application. I'm only doing something like a blog.
Can I use a pure JSP and ignore Java EE and the JavaBean and start a pure JSP project?
JavaSE on its own is not sufficient to use JSP, you need at least some components of JavaEE. Specifically, you need a servlet container, such as Jetty or Tomcat.
Neither of these requires (or even contains) the rest of the baggage that comes with a full JavaEE stack.
You don't need to download the huge Java EE packages as offered by sun.com/oracle.com. All it basically contains is the Glassfish server and eventually the Netbeans IDE. Glassfish is a fullfledged and heavyweight Java EE server.
The minimal requirement to develop and run JSP/Servlet is the following:
JDK (click the first Download JDK button) - about 75MB.
A JSP/Servlet container, I'd suggest Apache Tomcat - only about 7MB.
That's all. You have only to choose a development editor, which can be just Notepad. However to ease and speedup development, I'd recommend using an IDE like Eclipse for Java EE. It offers code completion, automatic builds (compilation), easy debugging, deploying to integrated server, etc.
That said, Javabeans is just a specification, say, a style of coding. Public classes with private properties and public getters/setters which represent real world data e.g. Person, User, Product, Order, etc. It doesn't require a download. You just have to write it yourself. However, to ease development and maintenance it's strongly recommend to use Javabeans in your code.
See also:
Is the sun tutorial the best way to learn how to make a Java webapp
Java web development - What skills do I need?
What is a Javabean and where are they used?
JSP tag info page
There's no requirement you use all the features of the Java EE server. There's also stand-alone servlet containers like Apache Tomcat.
Related
I've been learning Tomcat and servlets recently. Now I came to realise that the Oracle API and the Tomcat API are at least somewhat different. I know the Oracle API should be wider, but still even in the limits of Tomcat operation, they seem to have completely different packages, etc.
This may seem silly, but I can't find any answer. Could someone please explain the differences? And in practical terms, if I build a service that runs under Tomcat, will it also run in, say, Glassfish, without any refactoring of imports?
--- EDIT ---
So, apparently I mistook Tomcat API for Servlet API, etc.
The solution is not to look at the Tomcat Javadocs in the shot above, but at Servlet Javadoc, or whatever is in question. The list in the pic can be found at Apache Tomcat 8 Documentation Index, on the left, slightly down.
Thanks, Andreas and EJP.
Java Enterprise Edition
What you call the “Oracle API” is actually the Java Enterprise Edition (Jave EE) specification. I suggest you avoid using your misnomer.
Java EE is a vast collection of dozens of varied technologies layered on top of Java Standard Edition (Java SE). Various implementations of Java EE support different pieces, not necessarily all of them.
Subsets of technologies
The Apache Tomcat project, and similarly the Eclipse Jetty project and others, intentionally implement only these technologies:
Java Servlet
JavaServer Pages (JSP)
Java Expression Language
Java WebSocket
These few APIs are just a small, but vital, subset of Java EE.
The Tomcat API you linked is specific to Tomcat’s implementation. Developers would only very rarely go through that API. Instead we stick to the interfaces published in Servlet, JSP, EL, and WebSocket specifications all published as JSRs. Sticking to the specs means your web app can be deployed on other implementations as an alternative to Tomcat should the need ever arise.
Web Profile
The Java EE Web Profile is a specification that includes Servlet and JSP APIs along with several more, but still a subset of all the possible Java EE technologies. Apache TomEE is one implementation of the Web Profile, that starts with Tomcat and adds more libraries. Another example is Glassfish, which is/was available in either a complete Java EE edition or a stripped-down Web Profile edition. See the Question, What is different about the Java EE packages? (SDK/normal vs Web Profile).
“Full” implementations
Some products implement all (or nearly so) of the Java EE specifications.
Sometimes this is described as a "full" implementation. I consider that label misleading as it implies the subset implementations are missing or lacking something needed. Quite the opposite. You should always use the leanest implementation that includes only the parts you need. More heavily laden servers take more memory, start and stop more slowly, and may cost more money. For example, I build and deploy highly interactive desktop-style web apps using only Apache Tomcat 8 with Vaadin 7 on top of Java 8 Standard Edition (SE) on Mac OS X.
Also keep in mind that many of the Java EE technologies can standalone, separate from a full Java EE implementation. So you can start with a leaner implementation and then add the libraries for just the few individual technologies you need. For example, Bean Validation can be used on Tomcat by adding the JAR file of an implementation.
I would like to know what is the relationship between Java and FatWire.
I know it is possible to create templates using JSP but does it involve any standard Java programming? Also, is it possible to integrate it with MVC frameworks such as Spring or Grails?
Fatwire (now Oracle WebCenter Sites) is a CMS system originally based on an XML language. A JSP API (with the same features of the original XML language) was added later and it became prevalent. One of the biggest drawback of this design is that most of your coding must be done in JSP (that is a view only technology). So you have the (content) model and the view but not a controller layer.
But the real problem is that either you extend the Fatwire application with Java code (restarting the application server at each change, or using JRebel) or you have to code everything in JSP. Almost the website implementation I have seen so far uses a lot of JSP and some spare java classes, so websites have the tendency to be written with the crippled java available in JSP (you cannot share a class for example, or leverage the full Java OOP).
If you want to use full Java, you may use frameworks that implements MVC. For example, AgileSites (Disclaimer: I am the main developer of AgileSites). AgileSites basically uses JSP as interface to the CMS (as the documentation recommends) but those JSPs calls java code stored in hot swappable jar, built automatically while you do your development. So you can code everything using plain Java, without having to restart the application server at each change (only the jar, that is small, is rebuilt, when you save a file). On top of this Java enabling technology, AgileSites gives you plenty of features: clean separation of presentation from controller, using pure java controllers and pure html views, embedded unit testing support, an integrated build for continuous integration, scaffolding, a very simplified API covering 80% of normal needs (while giving full access to the full API) and more.
Fatwire templates can be developed using JSP, XML and HTML. Developing it using JSP has many advantages and Fatwire comes with JSP tags (called ICS tags) for standard based development. Most commonly you can see a JSP based template containing scriptlets of Java code invoking Fatwire's asset api which is implemented in Java.
Latest addition to this is Fatwire Web Experience Management (WEM) framework which are a collection of REST services with SSO that will enable you to write applications around Fatwire.
For example, I have developed REST based applications to integrate SVN, Translation systems and provisioning systems with Fatwire using Java.
Also, the latest Fatwire (Oracle Webcenter Sites) comes with set of developer tools called CSDT which is actually a Eclipse plugin that lets you develop templates within Eclipse (that has all the good features such as versioning, syntax checking) and facilitates local development, versioning of templates and continuous integration.
Yes, Java and FatWire can be used mutually. Code your java classes, wrap them and deploy in war or jar format in your app server lib folder. While coding inside JSPs, call your java classes or methods in JSPs and use them as required.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Java: A good introduction to J2EE platform for noobs
I'm not new to programming at all - I've programmed in .net for over a decade. I have dabbled now and then in java, but never at an enterprise level. Now I'd like to learn to use Java EE.
What are some good online resources, or books that I can buy? I'll need a step-by-step on what to download to set up my environment (I already have the Glassfish tools bundle for eclipse, but I'm not sure if this is what I need or where to go with it...).
I think coding a simple website to perform basic crud operations would give me a good start.
To begin with, I'd stay away from anything that says J2EE as it's an outdated uglier version. Look for Java EE 6 or at least Java EE 5.
Apart from that my recommendation would be to download the Java EE version of Netbeans
since it has everything you need. In the same site there several starting tutorials and a longer e-commerce tutorial
If you want to start with Servlets and JSPs in Tomcat, just make sure it is selected during the install procedure.
Glassfish is fine. You might consider JBOSS as well; it's another Java EE app server that's open source and won't cost you a thing to try out.
I'm not sure if WebLogic from BEA/Oracle is still available to download for developers to learn, but it's my favorite Java EE app server. Version 9/10 from BEA, before Oracle bought them, was simply the best.
You can start with a servlet/JSP engine like Tomcat or Jetty. You would begin with servlets (HTTP listeners that respond to GET/POST requests); JSPs (a templating language using tags that are compiled into servlets and executed on the server - think of them as servlet/HTML factories); and JDBC (relational database connectivity). You can go a long way with just those.
Once you've mastered those you can decide between a Java EE solution (EJBs) or Spring. Spring is not part of the Java EE spec, but it's a fine alternative. It's a combination of dependency injection, aspect oriented programming, and solid modules for persistence, remoting, messaging, web services, web MVC, LDAP, etc.
The NetBeans IDE is not so ubiquitous as eclipse (so eclipse is a very good choice), but makes Java EE 6 with Java 7 and GlassFish very easy. And netbeans.org has several tutorials.
I'am trying to dive deeper into Java EE,
so i was browsing SourceForge to look for a project
that can help me see how components fit together
so if comeone could point out a specific open source project
or any other resource that can help me with this.
The canonical sample application to learn Java EE used to be the Pet Store from the Java BluePrints program (now) at Oracle.
Check out here for a list of blueprints. The Pet Store is here
Barring a specific need, if I wanted to "learn Java EE" today, I would focus on the EJB-Lite profile of Java EE 6. Basically this is the web tier, JPA, and embedded Session Bean EJBs.
These components are the "90+%" of what folks do with a full boat Java EE server today. I don't consider learning the web tier enough to be considered "Java EE". Yea, it's a component of Java EE, but I think EJB is more important, and EJB is more "interesting" along with the web tier.
EJB-Lite hits the sweet spot of functionality and ease of deployment and packaging.
Open eSignForms by Yozons is an excellent Java EE application to learn on.
Check out their website and download their esignature and web contracting application.
You'll learn advanced topics such as sending and receiving mail, integrating with PostgreSQL, Apache Tomcat, encryption, and much more!
They also make extensive use of the Java framework Vaadin for a modern and responsive web application interface.
What has me going is the degree of web application development we are talking about.
There are different levels of web application development. For example, if I was asked to develop a web application to deal with housing customer information for a small mom and pop bakery (definitely not a enterprise situation), is there anything wrong with using Java EE as opposed to Java SE if I really want to.
I know you might say that it would be overkill, and I can understand that, however, am I going to run into development issues that I would not run into using Java SE? In other words, I am trying to determine when does a small business web application turn into a enterprise web application. It seems to me that I should be able to use Java model that I want.
Am I wrong in my thinking here?
Need clarification here if you can help me.
There seems to be some confusion over the usage of Java EE and Java SE terminologies. Just because EE expands to Enterprise Edition, it does not mean that it is used only by enterprises.
Java EE happens to be a set of specifications that are bundled together to form a platform. The moment you need to write a web application, you need to use the Servlet + JSP specifications at a bare minimum, which is a subset of the Java EE specification.
Java SE, on its own is usually used to write standalone applications. It is better to refer to Java SE more as an API or a library, rather than an as specification, in contrast to Java EE. It can be considered as a platform for the "non-enterprisey" applications.
Don't take Java EE literally. Java EE is not just enterprise development, per-se.
Java EE gives you the entire stack for building web apps on Java. You just can't do web development on Java otherwise.
Bottom line - you need the Java EE stack, even if you are a small/medium business. Don't let the name fool you.
Theres nothing wrong with using a full Java EE container. However this usually comes at the cost of complexity.
The minimum you need is a servlet container which is a subset of the Java EE specifications.
Full Java EE containers tend to have more to configure in them than simple servlet containers which may add overheads that are not worth it.
The other thing to consider is If you do use just javax.servlet to compile .war files then these are compatible with full Java EE containers so there is nothing to stop you upgrading at a later point.
Another point to keep in mind is JBOSS / GlassFish which implement the full Java EE stack use more memory and may have longer startup times than say tomcat.
If however you know that you will be using more of Java EE at a later point such as EJB; then I would start out with the full Java EE container.
To Summarise
Personally I would start out using just a servlet container. (not full Java EE). If and only if I needed a full Java EE stack then I would move to a full Java EE container.