I'm building web applications using Spring (scaffolded with ROO) and Velocity for the template engine.
Those applications are very similar in their flow, most of the time the logic doesn't change very much, so I can use the same controllers across multiple webapps. What needs customization is the UI side.
I want to build a flexible system that allows :
To work locally while developing
To package templates outside of the webapp
To change some templates without redeploying the webapp.
So far I have built something which uses the WebappResourceLoader and the URLResourceLoader :
resource.loader=url,webapp
webapp.resource.loader.class=org.apache.velocity.tools.view.WebappResourceLoader
webapp.resource.loader.path=/WEB-INF/views/
webapp.resource.loader.cache=true
webapp.resource.loader.modificationCheckInterval=1
url.resource.loader.class=org.apache.velocity.runtime.resource.loader.URLResourceLoader
url.resource.loader.root=http://localhost/templates/
url.resource.loader.cache=false
So basically, the "default" templates are located inside the webapp, and can be overridden by templates located somewhere accessible by URL (right now in a simple folder in Apache).
In the end, the templates for each "skin" should be packaged in a separate WAR.
Now I don't know how to be able to work locally with this architecture...
Most of the time, I'll be working on customizing the templates code, so I suppose I could have a WAR project with only templates, and use Maven's WAR Overlay to bring them to life.
But in this case, the templates are inside the WAR, and this is not what I want...
Any ideas ?
Related
I am trying to split Jhipster generated project into multi module project.
I want to separate Presentation layer with angularJs into separate module.
How could I do that?
However, with a little effort you can separate the deployment of frontend and backend. i.e. use nginx for the frontend contents (configured to proxy the requests to the backend) and use tomcat for the backend.
i.e. change the dist directory and then do "grunt build". A few things will be missing (init, bower_components and i18n). aka, editing a bit the Gruntfile.js will be required in order to fix it.
JHipster is not meant to be a "multi-module" project.
Of course you can do it if you want to re-code everything, but that would be really complicated.
We have several in-house developed application in Groovy/Grails and use a shared plugin containing code that is common to all applications. We're needing more advanced authentication (LDAP, CAS, etc.) so it's time to implement the Spring Security plugin. I've been doing a bunch of reading on it, but I'm stuck at something as simple as changing the URLs and GSP pages that are used for the login and logout. I'm assuming that we'll also need a custom controller to make these changes.
In a normal situation where an application is using the Spring Security plugin, changing the default controller and/or GSPs seems to be as easy as just creating a file with the same name and location as the original files (since application files override plugin files). However, we're including the Spring Security plugin in our shared plugin which then is included in the application ... so unless it's possible to have one plugin override another plugins files this sort of solution doesn't seem to work here.
What would be the correct approach for overriding the default login/logout pages, url, and possibly controllers being used?
The controllers and GSPs are part of the plugin in 2.0. If you want to customize them copy them from the installed plugin directory to your project in the same folders and make the changes there. App files always override plugin files because the plugins are compiled first, then the app, so the app's files take precedence.
This procedure worked successfully for me.
In my project I use Maven to package a web application to a WAR which is later deployed to Jetty using a custom Maven plugin on CentOS. The custom plugin is used by every project that deployes to a production environment. There is now a requirement that all static content (like web site text, properties) is packed outside of the WAR so that it can be changed in production without requiring a new release cycle. I am unsure how to achieve this externalization.
The Jetty server has the directory structure described in Jetty quick start guide. Currently, the web application already offers some .properties files which can be altered externally, and these reside in the resources/ directory. These files are moved here by the custom Maven plugin. The WAR resides in the webapp/ folder. One option for my problem is to use <packagingExcludes> of maven-war-plugin to not include e.g. *.xhtml and *.properties in the WAR. Later, I can use the custom Maven plugin to move excluded files to resources/ directory. But, I have a feeling this is not the correct way to externalize static content... Shouldn't xhtml files live in webapp/ folder while the only the properties file live in resources/ folder?
I have also researched the option of deploying the WAR as exploded, but I am unsure of the implications of such. Clearly, the changes in the exploded WAR files will be overwritten in the next deploy, but the idea is to do static changes both in development and production. Also, I am not sure how to achieve WAR "explosion", is it something that Jetty does for your WAR if configured in jetty.xml or do I have to extract the WAR before deploying?
Lastly, how do people serve static content in Jetty which can be altered in production? Do both the WAR and static files live side by side
The Jetty resources folder should not be used for application files. A J2EE web application (war) should be self-contained -- and in Jetty, reside only on the /webapps folder -- and its only binding to the container (Jetty servlet engine) is via the web.xml deployment descriptor.
Since property files may be read from the classpath and the Jetty resources folder is part of the system classpath, a property file there could be read by the web application class loader. Note that there are other ways to read property files as well and the Jetty resources folder should not be used for application properties. Also, the application may not be portable as other application servers have different forms of webapp classloader isolation.
If the below architecture approach does not work for you, then your only approach would be to expand (explode the war) in the /webapps folder and hope for the best when files are edited.
Tackling this from a different angle,
- if your web application depends on .properties and .xhtml files in order to function properly, then these files are probably not 'content'. The fact that there is a business process that requires them to to be updated ad hoc does not make them content.
- 'content' is something like text, images, and videos that is added, edited and removed by an administrative user. The application does not depend on it for correct execution, it merely reads and passes it on the browser.
Suggestions:
I would suggest that you deploy your application every time there is a change to the .xhtml or .properties files change. If the editors of these files are power business users, you might think of a git push-pull tool for them and a continuous build hook, so that when they make changes and push them to the git repository, the application gets tagged with a newer version and gets built and deployed. If there is a problem (tag not closed in xhtml), then it would be easy to roll back to the last tag.
Alternately, if the changes are minor (such as text descriptions), then modify the application to read them from an arbitrary external file (outside the webapp) -- a location that is provided to the webapp on startup. You can then package a 'default' version of the file in the webapp, but the code would attempt to look in the specified external location first.
I discovered that you can add HTML tags to properties and later use <h:outputFormat> to fetch these properties with parameters. Also, you can do pretty neat stuff with property files as described in MessageFormat API.
My solution was to keep the .xhtml files inside the WAR, but use simple HTML snippets properties from the default resource bundle which is based on a .properties file. These properties were included in the .xhtml using <h:outputFormat>and <h:outputText>. This allows the user to add simple styling like bold and underline to the snippets.
The properties file are copied to the Jetty resource folder using the custom Maven plugin, so I have kept the .properties files in the WAR. For some reason the Jetty resource folder has precedence over the packed .properties files, so this works out fine. Also, as Akber pointed out, I will have the default versions of the properties available if for some reason the WAR was moved to some other application server where the resource folder is not available.
Of course, with this approach the code can break if malformed HTML is placed inside the snippet properties, as pointed out by Akber, but it works for our application as it is very small. I may never have done this if this was a much larger application, but then I might have gone for a database based solution for adding static text (like Joomla/Drupal/Wordpress).
I am developing large web project, using IntellijIDEA (11.1.3).
I would like to have some environment, where I will be working under HTML templates. I won't use any server-side programming there, just HTML markup, CSS style sheets and JavaScript.
As well, I need different environment, where I will create dynamic application, using not only markup, style sheets and client-side programming, but also Maven, Spring MVC, Hibernate, PostgreSQL and, probably, other technologies.
I will use Tomcat to deploy both my template and my final application into container to view it in browser.
The question is how to structure my project?
That would be absolutely great if someone could show me step-by-step instructions of creating sample project, but any advises are appreciated.
IntelliJ IDEA 11 has a special Web module type for the plain HTML/JS projects, create one module of this type and another Java module for the rest of the technologies.
How do you have your GWT project setup? Do you have a single project for the client side and separate project for the server side? Can you share your experience with organizing projects for a GWT front end, spring backend system? I am looking to use Spring + GWT + Tomcat + Hibernate for this project.
Unless you have a really good reason to split the client and server side into multiple projects, you should go with just one project.
Otherwise, you'll need your server-side project to be dependent on your client-side project since any data objects that are shared will need to be part of the client (so gwt can create a javascript version of them). This intuitively strikes me as backward.
Alternatively, you could create 3 projects; one server, one client, and one with all the shared classes. But doing that will give you two projects that gwt has to compile which you'll then have to wire back together. Unless you have to deal with some weird gwt-based legacy code integration issue, I can't see what this would get you.
Of the two significant gwt-based projects I've worked on (using the same technology stack you refer to), I have used a single project.
I use a single project for a GWT client and Tomcat backend and it works great. I love the convenience of making a quick change in protocol to both sides and then having a single build step.
The war directory in a GWT project can do all of the non-GWT stuff you're used to, with arbitrary directories and files, so it's really convenient to mix JSP, HTML, and normal JavaScript right in with GWT.