In my existing web project the directory structure for the served html content while development with jetty is "myProject/src/main/webapp/"
Now, I want to integrate an angularjs project here.
I've played a little bit with Yeoman.
If I'm scaffolding with yeoman, I'm wondering how I can integrate it into our existing dev and deployment structure.
I suppose to use the main folder "myProject" to run yeoman scaffolding would be fine. Then I would get a "myProject/app/" diretory for all my frontend stuff. Should I instruct somehow (how?) my jetty server to use ".../src/main/webapp/" as an alias for the new app directory?
We use jetty mainly as a proxy for requesting the backend. Is there also a way to do a live reload similar to "yeoman server" in combination with jetty?
Take a look at my answer on how to do Django-Yeoman integration.
Architectural concepts will be the same, even external articles (definitely must-reads) are Java-based.
In short:
Use yeoman-maven-plugin. If you are on Gradle that's still ok. Even better, since you will have better control over which grunt tasks are being invoked.
Your project structure should resemble this:
pom.xml
src/
main/
java/
...
resources/
...
webapp/
WEB-INF/
yo/
dist/
<<the rest of the Yeoman-generated stuff>>
Yeoman generators, including the one initialising the frontend part, should be invoked exclusively from yo directory.
The plugin takes care for copying production-ready yo/dist to WEB-INF.
All you have to do is to serve the latter as a static resource.
Config for Spring MVC (dispatcher servlet):
<!--Yeoman static content-->
<mvc:resources location="WEB-INF/yo/" mapping="/**"/>
One should aim for similar config when using other technologies, like Jetty, or pure Servlet config.
The rest, particularly dev setup, is described in referenced answer.
Related
We have an existing JSP project that serves a website and a REST interface. However its an old project (started in 2013) and now it does not scale well with new requirements. We would like to add Spring REST interface under the same project (sharing same tomcat and sessions) until we we migrate completely and drop the old REST interface (and the website) entirely.
Current project structure is:
Root/
website/
rest/
WEB-INF/
web.xml
classes/
META-INF/
context.xml
Current rest interface is accessible via /rest/xyz.jsp
Now we would like to use Spring and migrate rest/* such that they will be accessible via /api/*
How do I integrate Spring boot into this project? what set of configuration do I need to make?
Spring boot docs and internet weren't helpful.
I have a webservice that uses Java, REST, Jersey and runs on Tomcat8. The webservice requires access to a database. Depending on where we are in the process the we may be using a testdatabase, production database or something else. Ideally we would like to be able to set which database to use without requiring a code change and recompile.
The approach we have tried is to have a properties file defining the database parameters and use an environment variable to point to the file. This has proved troublesome, first we've had a hard time defining system properties on the Tomcat server that we can read from the application, also it seems like all the files will have to be defined on the classpath, i.e already configured ahead of time and part of the codebase.
This seems like fairly common scenario, so I'm sure there is a recommended way to handle situations like this?
Zack Macomber has a point here. Don't enable your app/service to look up its settings dynamically.
Make your build process dynamic instead.
Maven, Gradle and friends all provide simple ways to modify output depending on build parameters and or tasks/profiles.
In your code always link to the same file (name). The actual file will then be included based on your task and/or build environment. Test config for tests. Production config for production.
In many cases a complete recompilation is not necessary and will therefore be skipped (this depends on your tool, of course).
No code changes at all. Moreover the code will be dumb as hell as it does not need to know anything about context.
Especially when working on something with multiple people this approach provides the most stable long-term-solution. Customizable for those who need some special, local config and most important transparent for all who don't need or don't want to know about runtime environment requirements!
We have a similar case. We have created a second web service on the same endpoint (/admin) which we call to set a few configuration parameters. We also have a DB for persisting the configuration once set. To make life easier, we also created a simple UI to set these values. The user configures the values in the UI, the UI calls the /admin web service, and the /admin service sets the configuration in memory (as properties) as well as in the DB. The main web service uses the properties as dynamic configuration.
Note: we use JWT based authorization to prevent unauthorized access to /admin. But depending upon your need you can keep it unsecure, use basic HTTP auth or go with something more detailed.
Not sure if in this particular case it is wise, but it is possible indeed to create a .properties file anywhere on the filesystem - and link it into your application by means of a Resources element.
https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html
The Resources element represents all the resources available to the web application. This includes classes, JAR files, HTML, JSPs and any other files that contribute to the web application. Implementations are provided to use directories, JAR files and WARs as the source of these resources and the resources implementation may be extended to provide support for files stored in other forms such as in a database or a versioned repository.
You would need a PreResources element here, linking to a folder, the contents of which will be made available to the application at /WEB-INF/classes.
<Context antiResourceLocking="false" privileged="true" docBase="${catalina.home}/webapps/myapp">
<Resources className="org.apache.catalina.webresources.StandardRoot">
<!-- external res folder (contains settings.properties) -->
<PreResources className="org.apache.catalina.webresources.DirResourceSet"
base="/home/whatever/path/config/"
webAppMount="/WEB-INF/classes" />
</Resources>
</Context>
Your application now 'sees' the files in /home/whatever/path/config/ as if they were located at /WEB-INF/classes.
Typically, the Resources element is put inside a Context element. The Context element must be put in a file located at:
$CATALINA_BASE/conf/[enginename]/[hostname]/ROOT.xml
See https://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Defining_a_context
I'm a longtime desktop developer (C/C++) that's been doing web development with Rails since ~2005. I've now been thrust onto a Java web application at work and just do not understand how any developer can grok where all of the URI's are being directed.
I'm working in IntelliJ, and there are six different projects that contribute artifacts to the war. I know that the mappings are defined in web.xml, but it's impossible to tell from there which URI's are directed to which beans or whatever.
As I write this I already have a sinking feeling that there's no answer, but is there some ability to get a straight answer of which routes are exposed by the application and where they point to in source code a la rake routes?
UPDATE
#Dave: It's a mix of Jersey REST and Icefaces. I only vaguely understand what Icefaces is.
Is there an ant script or some other script anywhere that contains details to how the projects are pulled together and built/packaged into the war?
Ultimately everything is constructed into a base directory containing files, directories and a /WEB-INF directory. /WEB-INF is protected and it's contents are only accessible via URI's via the web.xml. Where everything outside of the /WEB-INF in the root directory is accessible via URI's (relative to the root directory) or URL's.
I'm not completely confident in what is all entitled with a rake route, but I believe your sinking feeling is correct - what you see in the web.xml is what you have to work with in java web-apps. The <servlet-class> tag maps the package.diectory.to.JavaClass to a given <servlet-name> and else where in the deployment descriptor, the is a <servlet-mapping> and <url-pattern> that maps the given url to a servlet-name.
I understand that Servlet 3.0's enhancements have made it possible to display a .jsp from a .jar, based on Can I serve JSPs from inside a JAR in lib, or is there a workaround?
However, I don't seem to be able to connect my View (jsp in jar WEB-INF/lib Tomcat 7 and classic spring MVC context configuration in a War) with the Model and the Controller of my Web App.
Is there a good way to share the dispatcher Servlet, or perhaps create a CustomViewResolver which could scan .jsps included in external JARs, and actually plug my jar into a unique spring context?
With JSP you have the problem of compilation.
So you at least need to precompile them, to have them included. Then it should be possible, since after compilation a JSP is basically a Servlet.
If you would use another view technology like Velocity, Freemarker or JSF based on Facelets, you can very easily use a classpath based ViewResolver.
I am in the process of migrating an old model 1 java based website, to use an under development restful-api (with the long term goal of providing a PaaS and any other buzzwords I can find).
I want to use multiple different WAR files for different modules of functionality. I know how to do this
www.myLegacy.com/myWarFile/myFirstMethod
www.myLegacy.com/myWarFile/mySecondMethod
www.myLegacy.com/mySecondWarFile/ThirdMethod (in different war file, and consequently diff url)
However I want to be able to deploy multiple war files to the same url like :
www.myLegacy.com/myRest/myFirstMethod
www.myLegacy.com/myRest/mySecondMethod
www.myLegacy.com/myRest/ThirdMethod (this is in different war file to other methods)
This is would use the full spring stack (inc spring-mvc) with tomcat.
Any pointers please ?
You could use an Apache httpd, nginx or the like, and route URLs accordingly.
I dont think it is possible straight away as Tomcat starts different war files in different context paths. Only thing I can think of is deploying myRest.war and mySecondWarFile.war and adding a mapping for /ThirdMethod in myRest application itself and routing the request to /mySecondWar/ThirdMethod .