I'm reading through the Java EE 7 Tutorial, and I came to the section Packaging Web Archives. I'm already familiar with the way Java web applications and WARs should be structured, but something caught my eye:
A web module has a specific structure. The top-level directory of a web module is the document root of the application. The document root is where XHTML pages, client-side classes and archives, and static web resources, such as images, are stored.
What on earth do they mean by "client-side classes"? If you put a .class file outside of WEB-INF, obviously you can download it using a web browser or other HTTP client. I suppose you could distribute a small application this way. Would these "client-side classes" have any other use?
I believe what the author is getting at is classes which will be executed on the client-side, such as the browser.
Related
I'm working with an application which has a modular architecture - each module is contained in a WAR file running on top of Tomcat. One of the modules allows users to extend its functionality with a request Interceptor interface, which is #Autowired into the class by Spring.
I'm working on a custom Interceptor and would like to make it available to Spring for autowiring within the module. Until now I've been building a custom version of the module's WAR which contains my interceptor, but I do not feel that this is a clean approach because the idea was to make the application easily extensible, and building my own fork for this reason seems to almost eliminate the benefits of the Interceptor interface.
I know one possibility is to crack the WAR open (it's just a ZIP archive) and drop a custom JAR in there, but that doesn't feel right either. Perhaps there is a way of adding custom JARs using Maven? Is there an industry-standard way of doing this?
I think I have at least a partial answer, everyone is welcome to provide a better one.
There is a helpful documentation page about class loading in Tomcat. It describes where classes are loaded from, snippets which are most interesting to a casual reader are reproduced below:
unpacked classes and resources in $CATALINA_BASE/lib
JAR files in $CATALINA_BASE/lib
unpacked classes and resources in $CATALINA_HOME/lib
JAR files in $CATALINA_HOME/lib
WebappX — A class loader is created for each web application that is deployed in a single Tomcat instance. All unpacked classes and resources in the /WEB-INF/classes directory of your web application, plus classes and resources in JAR files under the /WEB-INF/lib directory of your web application, are made visible to this web application, but not to other ones.
I am creating a web application using Java, Spring, Hibernate and AngularJS.
but I am not clearly understand the role of WEB-INF directory. As per I know WEB-INF is a web directory where we keep our web configuration files. But I have seen some example in AngularJS app where js and html are put in WEB-INF folder and it is known that WEB-INF is not publicly accessed. So why do we put those files in WEB-INF and what actually mean of publicly accessed even when we response for a request html and js are visible to clients, and if we put in WEB-INF folder these files how to access those files.
I need some clarification on these few points before starting my app development.
Please anyone can help me regarding these issues.
As you said, we put configuration files into the WEB-INF folder. But there are cases when you use resource files (e.g. HTML templates) which are not sent to the client as-is, but usually some transformations or parameter substitution happens, which are usually handled by a Servlet.
It is ok to put such templates and resources to the WEB-INF folder because the files as are should not be visible/accessible to the clients but only the result of transformations/parameter substitutions.
Resource files are frequently stored within WEB-INF because the Java servlet container will not directly serve those files. Instead, some Java controller code is being used to serve them indirectly. This is perfectly acceptable, but I would prefer a solution that serves static content from a different server and let the Java container handle dynamic code only. In a pinch, you might just add a reverse proxy and off-load static content handling that way.
In case of Spring you can build your app without WEB-INF directory. For example: spring-boot + thymeleaf, it is possible put all html, css and js files to src/main/resources/static .. so WEB-INF directory is not necessary for all java web applications.
You don't have to use WEB-INF at all.
Here's a simple AngularJS example app (official Spring guide) on how to do this.
Now, like Elliot mentions, sometimes using proxies is a good idea (depending on the kind of traffic your application should support). You could also use a CDN, which is easier to set up and has no configuration requirement in your application.
I am reading Beginning Java EE 6 with GlassFish 3 and I am confused about what is correct about packaging a Java EE application.
EJBs Lite can be pacakaged directly in a war or in a jar file. If you need to use the full EJB specification (e.g., remote interface, JMS, asynchrounous calls...) you have to packaged it inot a jar, not a war.
What does this mean? If I deploy an application packaged as a WAR in Glassfish, doesn't it give me all the Java EE services? If so what am I missing.
I understand that 3.1 introduced a new profile EJB Lite which is intended to be a subset of the full specification was targeted to implementors which doesn't want to implement everything, and that you from 3.1 can package EJBs in the WAR and use the services specified by the EJB Lite spec. But if you deploy a WAR in a full spec container it should give you everything as it would if you had created a JAR? Isn't a WAR just another name for a JAR? The distinction can't be on how it is packaged but what it actually supports?
Could somebody clarify.
The motivation of putting EJB logic beans in JAR files comes from a separation between business logic and view logic. At this time, as far as I am aware, there is no need to package all the EJBs into JAR and then combine this JAR with a WAR into EAR.
But... since EJBs are supposed to concentrate only on business logic, it makes sense to package them in a separate archive. WAR on the other hand is an archive of all things related to showing the GUI to the user, so JSPs, Facelets, images, CSS files and JavaScript libraries. WAR files can have a set of Classes in a WEB-INF\classes folder, as well as their own libraries in WEB-INF\lib. WAR file does not have to be a file, anyway. WAR file can become an exploded WAR, basically a directory with the same structure as it was in the archive.
A key aspect of that comes to class loader isolation in the class loader hierarchy. The WAR module has access to resources in EJB archive (JAR) and EJB module can reference and access resources (libraries) in the EAR file itself. The other direction, specifically an access to WAR resources from EJB module, is prohibited. And it is that way by design, as it prevents the developers - working under pressure - to mix those concerns and create a spaghetti code. Business Logic should be separated from View Logic, as it can and should be reused by Java SE clients, different Web Module clients, JAX-RS or within SOA based solution. If the business logic had any dependencies among JSFs or Servlets, using them in Java SE desktop solution would be impossible.
So, having a structure of EJB archive, which consists of many JAR and WAR files may not be necessary, but it is a best practice and one should be careful and concious about violating that rule.
I have a Struts web app deployed to an EAR that has some pretty extensive JavaScript. I now need to create a new web app that will be deployed to a new EAR but will probably need to share most if not all of the JavaScript and some images from the first application. What's the best way to avoid code duplication so I don't have to put a copy of each JavaScript file in each EAR in my development environment?
You could maintain the Javascript in a separate .jar library and serve it as a resource, not as a static file. That way the JS content would be a regular dependency in your project setup. Unfortunately there isn't a straightforward universal way to do this because you need at the very least a servlet that will send the file from the .jar. (Depending on your web framework you might already have this available.)
This also has some performance implications, but for a line of business application you probably don't need to optimize the load time of your internal Javascripts all that heavily.
Another alternative would be doing this at the source control level, using something like Git submodules.
I want to build a java web application and I don't have any background how to do that.
Can you plz tell me what is the starting point to do that and where can I found useful open source codes that I can use them to design my web application.
There are many different frameworks and without more information it's difficult to know what would suit you.
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Java is a good starting point.
You have to know concepts such as Servlet, Servlet Container, Application Server(such as Apache tomcat) and little information about Html.
Exist several book for this goal, my opinion is : you start by a book related to Jsp/Servlet concept, these books good explained.
Here you can learn how java web applications work and here is a very basic java web application example to get you started. I hope this helps :)
You should follow the Java EE tutorial, its Web Tier part. I think it's the fastest way to get knowledge that would allow you to understand the base concepts...
The minimal structure of a web application is the following:
/WEB-INF
/classes - stores the compiled Java classes your webapp uses
/lib - contains the additional libraries your webapp may need to run
web.xml - key file in every webapp; explained below
web files and folders (HTML/JSP/CSS/Javascript)
You may want to start out with Eclipse for Java-EE, since it automatically creates the webapp structure for you, so it's the perfect place to start learning, in my opinion; you can find it here.
After you install, the basic steps to create your web application are:
Create your project by accessing File > New > Dynamic Web Project.
Name your project, click Next, Next and check the Generate deployment descriptor checkbox. Now hit Finish.
Now that the structure is created, your main points of interest will be:
Deployment Descriptor - Is an overview of your web.xml file. Here you can declare all your servlets and their URL paths, you can point to specific error pages triggered by specific codes (e.g 404, 500) or exceptions that occur in your Java/JSP code (e.g NullPointerException, FileNotFoundException), plus do many other things to enhance your webapp. You can trigger between text and graphical XML editing in the bottom-left of the code window.
Java Resources - Here you define your Java classes and servlets. The main role of a Java class in a webapp will be to collect and process data. For example you can define your own math class that exposes methods which do basic calculations. A servlet will usually call one of these classes and output the result to the response output stream. Be sure to provide a solid project structure with the help of packages.
WebContent - this will contain all the web pages your webapp will show, including scripts, images and stylesheets. You are free to create your own folder structure in this section.
Some useful tutorials to get you started:
HTML
JSP
Servlets, Server setup
CSS
Once you're done with your webapp, you can either Run it on a server directly from Eclipse, or you can export it as a WAR file and deploy it on the server of choice, which is usually done by copying the WAR file in the webapps folder.
Finally, try to experiment with all the webapp features Eclipse exposes to you. Good luck!