I have a multi WAR web application that was designed badly. There is a single WAR that is responsible for handling some authorization against a database and defines a standard web page using a jsp taglib. The main WAR basically checks the privileges of the user and than based on that, displays links to the context path of the other deployed WARS. Each of the other deployed WARs includes this custom tag lib.
I am working on redesigning this application, and one of the nice things that I want to retain is that we have other project teams that have developed these WAR modules that "plug into" our current system to take advantage of other things we have to offer.
I am not entirely sure how to handle the page templates though. I need a templating system that would be easy enough to use across multiple wars (I was thinking of jsp fragments??). I really only need to define a consistent header and main navigation section. Whatever else is displayed on the page is up to the individual web project.
Any suggestions?
I hope that this is clear, if not I can elaborate more.
Have done something similar in the past using Sitemesh
we defined a new web app called skins-app which only has the common header, footer, navbar which all other need.
Sitemesh is configured via a file named WEB-INF/decorators.xml in the skins-app
then in any consuming webapp, you add a WEB-INF/decorators.xml as well.
And point your pages to be 'decorated' by the skins from another app
<decorator name="main" page="/decorators/layout.jsp" webapp="skins-app">
<pattern>/*</pattern>
</decorator>
You can have detailed include/exclude as well in your consuming webapp, if any pages needed to be excluded from the 'decoration'. Take a look at the Visual Example on the Sitemesh link page.
Related
I have an existing javaee application with multiple pages written in JSP.
My requirement is to create functionality on 3 independent pages with Angular 2.
So on each page , I will have a div that contains Angular2 component which performs CRUD operations on a specific tables. The rest of the page remains jsp.
the Angular functionality and pages are totally unrelated. For example one page is managing accounts, the other products, etc..
I am new to Angular2 so my questions are more about design and deployments.
1) Should I create 3 different Angular 2 apps for each functionality or one app with 3 components. If I do the latter, then what will my root component look like?
2) How to import the Angular2 app in the existing Javaee app? should I do compile.bundle and then copy the bundle?
As I mentioned, I am new to Angular2 so any guidance will be very helpful.
Angular is for "single page applications" and it's usually expensive to load it, but cheap to navigate when it's already loaded.
You can use Angular CLI for building and serving your apps. You will need the build - produced by "ng build" (Angular CLI command) to include in your war file and probably move the content of index.html to some of your JSPs.
Have you gone through the Angular tutorial (Tour of Heroes)? If not, give it a try, many things will get clearer for you.
Edit:
Maybe you could consider rewriting the existing JSPs in Angular, so it's all one application with routing. But if you really need to load it 3 times in JSPs, I would probably write just one application with four modules - three would represent the pages and would look like the AppModule. In main.ts, you would load a module according to the app configuration. The last module would be a code shared among them. This would make it easier to maintain than 3 separate apps.
Starting modules
In main.ts, you are starting the application by calling platformBrowserDynamic().bootstrapModule(AppModule). So you can import all modules and bootstrap just one of them. If you use Angular CLI, you can also import "environment" = configuration, so you can decide which module to load according to it.
I have recently started developing my own project from scratch using the Core of J2EE : Servlets & Jsps.
I could not evaluate whether my project folder structure is right or not. Here is my project folder structure.
The question: Is it a good sign to put my jsps outside of web-inf. If not, why is it so? If yes why?
Is there any standard folder structure convention for a J2EE web application, I know maven has brought up some standards but still, we can customize as per the requirement I believe.
What are the points to be considered while laying out the folder structure for a J2EE web application, importantly where should the Jsps, static content should go into & why?
All I can do is tell you the pros and cons to specific ideas. What follows is 100% my opinion. I don't know of any specific requirements or rules. I'm sure somebody will disagree with me.
JSP's
Let's work on whether to put JSP's in WEB-INF or not.
Pros of putting JSP's in WEB-INF:
You control how the JSP's are executed. If you want a JSP to be
parameterized and re-usable (which is really hard with a JSP anyway),
you can put them into WEB-INF and use a servlet or a Struts action
controller or some other front controller to do pre-processing and
then pass control to the JSP, passing in the right environment
context (like request attributes, any security checks, parameter
sanitation, etc.)
You can programmatically or even at a firewall or IDS level block
HTTP requests to *.jsp to reduce the likelihood of somebody uploading
a JSP to the web root and then being able to execute code as the web
server. They'd have to over-write an existing JSP. Not a huge
security gain, but it does make compromise slightly harder.
Enforces good habits, like MVC, front controller, servlet filters,
dependency injection, etc. as opposed to a big monstrous JSP that
does all the work itself and is difficult to read/maintain.
Cons of putting JSP's in WEB-INF:
You cannot access the page directly, even if it is a simple
standalone page which needs no upfront processing. This is because
files under /WEB-INF are not servable by a servlet container.
Static files
In terms of purely static files like HTML, image, stylesheet, javascript, etc. put those under the web root (my_app in your case), but NOT /WEB-INF (because it is not accessible).
Overall layout
As for the overall directory layout, it depends somewhat on your build process. I like storing everything under "src" or "source" because it makes it clear what files are generated by building and which are pure source files. main lets you separate test code like junit classes from your main source code, which is good too. But if you don't have any unit tests (oh no!), then it's a meaningless distinction.
On the other hand, if you don't manipulate the web root at all during build (like if it's all JSP and static files), then perhaps you keep it at the top level, like /webroot or /deploy and copy files in as needed, such as .class or .jar files. It is a habit of human beings (especially developers) to over-organize. A good sign of over-organizing is having lots of folders with only a single sub-folder.
What You've Shown
You've indicated that you are following a convention set by maven, so if you are already using maven, just stick with that layout. There is absolutely nothing wrong with the layout you described.
In case of WEB-INF,
If you put JSPs in WEB-INF then you won't be able to access them directly. i.e. By absolute url
Outside, WEB-INF you can directly access them
Can i Have a single application with more than one web.xml files? And can two applications have a parent child relationship so that there are two web.xml?
For below servlet 3.0 you cannot.
If you are using 3.0 there is a possibility.
In JSR 315: Java Servlet 3.0 Specification, web-fragment.xml is introduced for pluggability of library jars which are packaged under WEB-INF/lib. The content of web.xml and web-fragment.xml are almost the same. One can define servlets, filters and listeners there. One can also specify metadata-complete=true in a given web-fragment.xml. In the latter case, the annotation processing of classes in that jar would be skipped. With web-fragment.xml, library jars can be self-contained and provide web related metadata information.
For sure, having two xml creates confusion and besides all, If you explain whats your exact requirement, you'l get a good/standard solution for your problem.
Can i Have a single application with more than one web.xml files?
It depends on the approach.
Approach 1
If you are working in an environment where there are certain servlets (I remember I worked on an old project where there was a Minification servlet and its purpose was to minify the JS/CSS at deploy time) and settings like e.g certain user-contraints and realms that you don't want configured on your development environment since you will be working with exploded JS/CSS and you want to bypass basic secuirty constraints configured in the application just for ease of development but you want them all tested out on QA , so it "sort of" of makes sense to have 2 different deployment descriptors configured for the same application. One in which you have only the basic settings to just deploy the application for development and on the other you have all your production settings that you want tested out on QA from A to Z.
But again, I want to make it clear that you can deploy you application using only ONE deployment descriptor.
Approach 2
Lets say you want your deployment descriptor to be broken down into small parts for plugg-ability purpose like you define your Servlets in one file and you define your securutiy constraints in other file. These files or web-fragments.xml can only work with Servlet3.0. If you look closely to how these fragments are used, at deploy time all these fragments are merged and read by the container as a "single" file (the deployment descriptor).
So in the end , we again wind up with a SINGLE deployment descriptor for the application.
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!