I have a Java web app. Over time it has evolved in to what should really be two apps. There are things like CSS and Javacript files though that both ill need. Is there a way to have them shared so I do not need to duplicate these files.
Here is some additonal info:
Java 1.7
Using JSF running in Glassfish 4
If you refactor to 2 web projects say Web1 & Web2, make one of them base Web say Web1 and have other Web2 reference Web1, so you dont have to duplicate and keep them separate as well.
But unless you have a strong reason to split out 2 web projects, its advisable to keep it one if you have shared resources since a lot of shared resources like DB connection objects, services could be commonly pooled and will require relatively lesser resources
Perhaps the best option is to have a third web application, even in another domain (e.g. the Google Hosted Libraries), containing static resources such as CSS, JS, images, etc.
This is very convenient when the site is a huge sets of pages and different sites in the organization. Thus, if you need change to another style sheet or image, just change in one place.
Related
I'm currently working on a Servlet/JSP platform but I would need to be able to manage multiple frontend (different look and feel and features) with only one unique backend.
I tried to manage frontend and backend in two different war files on the same tomcat instance but I'm facing issues on the session sharing (refer the question asked).
I would like to find an architecture which provides me a way to simplify the deployment and avoid having one single and huge WAR File to be deployed. Typically if I want to add a new front end look and feel, I would like to be able to avoid a service disruption on the backend side and manage my developments independently for each part of the solution.
Do you have any architecture proposal that I can follow ?
How can I cache server-wide (with cache scope spanning multiple WARs on this server) instances of classes from a JAR which is contained binary-identical in several WARs on a web container (server, e. g. Tomcat)?
<EDIT> I want to cache application data across WARs because the data is common to them. (It's a portal project, where it can be useful to share common data across different "views" implemented as different portlets deployed as different WARs, and using a Java object cache is much faster and more simple than using a central data-holding service.) </EDIT>
Is that possible at all? Or is it required to put such a JAR on a path accessed by a common parent classloader, like in /lib/ext ?
See: Java, Classpath, Classloading => Multiple Versions of the same jar/project
See: How does class loading work when the same class exists in different applications on the same server?
See: cast across classloader?
See: What is a serialVersionUID and why should I use it?
Yes, the best option is to put the classes in a class loader that is a parent of the two applications. If by lib/ext you mean JAVA_HOME/lib/ext, then I would not recommend that. Instead, you should put them in CATALINA_HOME/lib directory. See the Shared Library Files section of the documentation, which links to the Class Loader HOW-TO documentation.
You can add common classes (jars) to the shared.loader property in conf/catalina.properties. Those classes are available to all web apps but not tomcat itself.
If you implement a cache around a static singleton, then you would be able to access the objects from different web apps. I don't know if that is best practice however. For example it makes it hard to scale because it makes it impossible to load balance the apps onto many servers.
The answer seems to be "it depends".
If the JAR(s) (or classes) in question do not have dependencies conflicting with other components also deployed on the server, both proposed solutions (CATALINA_HOME/lib/ext/ and CATALINA_HOME/conf/catalina.properties :: shared.loader) should plainly work. Thus both are "correct answers" and I cannot see which one is "more correct" than the other.
However I missed a crucial detail when I first asked the question (but this does not invalidate it): In my case the JAR in question required Spring 4.2.9.RELEASE (and other dependencies), but other relevant WARs deployed on the same server contain and require Spring 3.0.7. (The objects to be cached do not depend on Spring, but the JAR was not designed with this problem in mind, and it also contains other related code depending on Spring which now would be very difficult to separate.)
Generally it should be possible to put into CATALINA_HOME/lib/ext/ what ever you want as long as all already deployed WARs contain everything they need: The "module first / parent last" class loading policy should prevent conflicts, even if (as in this example) Spring 4.2.9 is available to the parent classloader and Spring 3.0.7 is available to the WAR classloader. But it looks somewhat "unclean" and messy to me to mix-up things that way.
Therefore I decided to use the "to-be-cached" object's classloader hash code as the key in a map, in which the cached data are the values. Then all cached data is selected "by classloader" which automatically and transparently ensures assignment compatibility. If there is also another WAR deployed on the server which can change and thus invalidate the cached data, it can remove the whole map from the cache, forcing the "read-access" WARs to reload data on next access.
However this approach DOES NOT allow cross-WAR cacheing: Effectively every WAR will get its own private cache segment.
Another approach would be to deliberately transform all data to cache to/from e. g. JSON so as to get a "naturally global" data type like java.lang.String for the cached data. If chosen from the beginning of the project, to me this seems to be the cleanest way, but if there is already a complex (and generally working) implementation in place, this may cause some work to do.
Comments on this self-answer are welcome!
I am totally new to Struts2 framework (and Java web services), and just went through few tutorials.
I have a general question here, in most tutorials, web contents like pages and back-end logic are stored in one single war package.
If I would need to make some quick changes to the pages (small ones, like updating text or picture), seems like I would need to deploy the war package again (according to the hello world tutorials).
In real life web applications, is there a better way to apply quick web page changes?
Thanks in advance.
It really depends.
There are companies using a Continuous Delivery approach, that allows them to release in production in minutes. For this lucky guys, it's not a problem.
Other companies are uglily drowned in burocracy, and every release means time, money and documentation, and hence this should be handled carefully.
Since JSPs (and Facelets) are not simple views but contain logic (not serverside logic like in the dark scriptlets days, but presentation logic), they should be part of a release process. Then you should keep them in the usual WAR, and extract from it only the pure presentation files, referencing them externally: .css, .js, images, HTML files and so on.
This way, if you will need to change the company logo, or the background color, you won't need to release anything except the static resources, if instead you'll need to add a new functionality, this will imply a release process.
This discussion can change with recent front-end frameworks (AngularJS, React, etc...) because HTML and .js there are part of the business logic. In those case, I'd take out just .css and images, keeping the rest under release control.
I need to build a dashboard for an application, the dashboard will have different dashlets and each dashlet can have any one of the following things:
Graphs (JFreeCharts and some Javascript Chart)
Table data from tables
Data from external sources
Maps
What can be a good architecture for such kind of application?
What I have currently in mind is:
Each dashlet should have its own lifecycle and when the dashboard loads it should just show the UI of the dashlets initially.
After the page load each dashlet sends a server call (based on its type) to fetch its data
After the data has been fetched, each dashlet (based on its type) renders the data.
First of all, there are plenty of front-end frameworks to get you started. Some of the more popular ones include:
Backbone
Javscript MVC
Sproutcore
A bit of Google searching can yeild pros and cons of each and I would weight your options accordingly.
That all being said, the basic problem you posed actually seems similar to ours. In the end, we built something a bit different in house. Many of the frameworks out there are optimized to display a singular canonical "view" based on a Model reflected by the DB and a Controller to manage small changes. A dashboard has, in essence, a variety of different modules that must be doing their own independent things as you've mentioned in your question. Because of the high number of independent modules, I feel like you might feel pains in some of the frameworks listed above.
I can't tell you exactly how to implement such a module architecture, but here are some rules of thumb we used when designing ours:
Module Design:
Module-based. (Login module, Map module, each Dashlet may be a module, etc.)
Modules must have one Model, may have no more than one Collection (which is-a Model), and may have one or more Views.
A module may be used in multiple places and pages. The singular Model should stay the same, but the Views are likely different.
Rendering:
Almost all HTML on the page is written and updated by javascript modules. The template files are almost empty except for headers and basic scaffolding.
All modules render their full HTML selves and replace themselves into the DOM. The module should have as complete of a static HTML representation ready to go before inserting into the DOM. This means the render functions use “.replaceWith()” instead of “.append()”.
If simple HTML replacing isn’t an option (i.e. needs to be animated) a transition function should be defined detailing how to go from one rendered state to another.
Because rendering is expensive, Views by default do not auto-refresh on all Model changes. Re-rending happens through events only. _render() is in-fact an internal method.
Orthogonality:
A single inter-module event dispatcher on the page Controller handles all cross-effects between modules.
Modules should never “reach outside” of their own DOM context. If an event in one module affects another, it should go through the page controller dispatcher.
Each module as orthogonal as possible. They depend on each other as little as possible.
Each module in its own file.
Connecting to backend:
All modules use the same global backend adapter. Modules never talk to the backend by themselves. This makes your front-end back-end agnostic.
Recursive:
Modules are commonly included in other modules.
Modules re-render recursively.
Testable:
Because modules render static HTML, they can be predictably tested.
Modules must be testable.
Standard input -> Module -> Predictable static HTML output.
Standard events -> Module -> Predictable static HTML output.
If anyone knows of other frameworks along these lines, please share!
Our web app is based exactly on this architecture and in production since end of last year. You can see it at http://beebole.com
We just optimized the calls to our own server.
There is a single call to get the common data needed by most widgets, each time a screen is loaded.
Then if a widget needs additional data, it makes a call itself to our server.
The external widgets call their own data too, but to another server.
I would advise against using a custom web framework when there are so many free ones available.
As mentioned in another answer, the traditional MVC style frameworks don't really fit well to your 'dashboard' desired style of UI. They are best used for creating static web sites based on data retrieved elsewhere. They don't handle user interaction well and you usually have to hand roll your own AJAX to do anything useful without a page request.
A better breed of web frameworks to look at are the Web 2.0 fraemworks, also known as the frameworks which help you build web applications. It is important to understand the difference between web site and web applications. They are usually differentiated by the latter being interactive and the former being mostly static. Websites which also have some interactive components are still web sites. A good way to think of it is ask yourself "Does this feel like a desktop app?".
For web application development in the Java (JVM) realm, I would use Vaadin. It lets you write Java code similar to Swing programming, with event based methods. You can even avoid writting HTML altogether if you'd like by defining your views programatically. This lets you unittest your view logic (in web apps, there is more than usual) which is not posible with regular HTML template based frameworks. The other main advantage is that it has built in methods which allow you to write Java code to handle dynamic, asynchronous functionality and it all gets translated to JavaScript automatically. No need to write 4 different languages while writing your web app, just write Java for everything! Try it out, it is fun to work with!
Another web app framework that is getting alot of attention is Lift. I do not have experience with it but many devs I have spoken with have promoted it to me. I believe it uses HTML templates with Java code as the back-end. It is also apparently really easy to get started and your web app spun up. It also has built in support for doing AJAX like functionality. Worth looking into at least.
There are probably many more web app frameworks out there that would suit your needs. These all have the advantage of being tested, independently maintained, updated, and secure*. If you roll your own framework for this project, you need to worry about everything yourself. Written a web framework that doesn't offer anything new would be like written yet another programming language that isn't innovative; it is just a waste of time.
I think what you are looking for is more along the lines of managing or controlling your dashboard. I am designing something similar. I would suggest you look at google app engine it can be used to automate and control this: https://developers.google.com/appengine/docs/whatisgoogleappengine
Also look at these open-source dashboards: https://github.com/twilio/stashboard
I'm trying to construct a java web app along modular principles, with some common resources (JSPs, mainly) in one WAR, and some custom resources in another. This means JSPs scattered across different WARs.
Now JavaEE frowns upon this sort of shenanigans, and wants you to put everything in one place. My current workaround to this is to have an Eclipse-triggered Ant script which copies the content of one WAR into the other, but this is not a pleasant solution (it's fragile and too IDE-dependent).
Ideally, what I'd like to be able to do is for a servlet to forward to a JSP located in a different WAR to one in which it is itself deployed. This would allow greater freedom in how I assemble my WARs. However, the RequestDispatcher does not seem to support such things.
Another possibility is to use <c:import>, which does allow resources to be imported from a different WAR (with some caveats). This would probably allow me to have a "hook" JSP in one WAR, which then drags in the required JSP from another. This is a bit clunky, though, and the fact that <c:import> permits it shows that the underlying servlet API does also. But how do I access that functionality via the RequestDispatcher in a servlet?
You can, with the following steps:
obtain the foreign context using ServletContext.getContext(contextPath)
get the RequestDispatcher of the foreign ServletCotnext.
in META-INF/context.xml set crossContext="true" (perhaps tomcat-specific)