We Keep Coding

Separate Container and Shiro Sessions?

We use Apache Shiro to provide security for 4 applications running within one Tomcat instance. They are deployed as 4 WARs, with all the Shiro config and security in a 5th WAR.
In order to provide SSO across these applications, we've configured ehCache to share sessions between all 5 web apps (the original intention was to use multiple containers, but this never happened).
The problem we are facing is that in sharing the sessions across the apps, we are also sharing all object data placed into the session. This is a problem because the apps have different dependencies and hence different classpaths, leading to ClassNotFoundExceptions. I think I'm right in saying that by default in a Tomcat container each WAR would have a separate session and so this would not be problem, but then we would not be able to share the Shiro user data!
So my question is this: Is it possible to have separate Shiro and Container sessions? This would allow the desired outcome i.e. any login data that Shiro uses would be placed into the 'Shiro' session and shared across the multiple apps, while the Container sessions would be separate for each app and therefore no data would be shared between them.

Shiro needs to run in each container. Then those containers need to share the Shiro session. https://shiro.apache.org/session-management.html#session-storage
You could do this using the container's session sharing capabilities or with Shiro's.

Split spring boot app into multiple web apps

I want to split a large web app into different sections.
In my case there is a webshop, an api service, and then the main app.
and all of them should share a domain layer.
I'm trying to reproduce an ear layout without using a enterprise server, so the main app would be a war with a shared domain jar, and the admin app would have a contextPath /admin and also share the same domain.jar.
From start they would be deployed together but as the app grows I would simply start deploying the apps on there own ports and use nginx to glue them together.
I've implemented most of it in this demo github repo.
https://github.com/leon/springboot-multiproject
My question is:
How can I map the admin app to a sub directory of the main app?
/admin <- Admin app
/ <- Main app
and do I need to take any special considerations when it comes to the domain layer?
See https://github.com/leon/springboot-multiproject/blob/master/src/main/java/se/radley/main/Application.java#L23

I can't think of a particularly easy way to completely separate the parts of your application. One option might be to create two ApplicationContexts and spin-up two Tomcat servers, but then they will obviously need to run on different ports.
I would be tempted to keep things simple initially. You could create separate jars for your 'main' and 'admin' #Controllers, one for your domain and keep the application jar containing configuration. Component scanning will work withing nested jars so a single DispatcherServlet can happily server both the /admin and / controllers.
Either that, or perhaps just bite the bullet and break-up your applications from the start. At least that way you will be aware of any architectural issues early.

What are some techniques for deploying a single page application that depends on a rest api?

I'm building a Single Page Application (using AngularJS) that renders data from a REST API call it makes to a legacy system. This legacy system is very large, written in Java and takes minutes to deploy so we decided it would be more productive to develop the Single Page Application completely separate from the legacy system.
The problems occurred once we tried to communicate with the legacy system's REST API. Although both apps were deployed locally to the same host, they were deployed on different app servers so I needed to use different ports when communicating. But because the SPA was communicating to a REST API on a different port, the browsers prevented my requests to protect against Cross Site Scripting attacks.
We found this build tool name lineman (that leverages grunt) that made it easy to proxy http requests. This got us around the cross site scripting limitation but this was only suitable in development mode.
Now that we've got a proof of concept working, we want to know how we're supposed to deploy these apps together without the proxying. It's hard for me to find advice on how to do this because Angular doesn't assume you have a backend in the first place and most people that use Angular on the front end aren't using Java in the backend (if that even matters).
We're running into issues like, the context paths of the apps change depending on if they're deployed in prod mode vs dev mode so we've gotta think of clever ways to avoid broken links that work for both modes. I wonder if/where I took a wrong step here along the way. Should I avoid developing the SPA on a separate server from the backend?

We had the same issues. The URL situation is that you will have different URL paths to your java REST API because you are in different environments.
In order to make these paths cascade down to the angular application, we had to first externalize the base paths in the web app (the app that spawns Angular) to use values that are set during deployment depending on where it is deployed to. We have values in our app servers that link to XML values in config files that we then reference in the application.
Then we create a call from the Angular app to the webapp that spawns it (not the java REST API) that will return the URL that is correct for the environment.
In the angular application, we can then setup the resuorce with the correct base path (the rest of the URL should stay the same from environment to environment).
If you can get the first part working correctly with externalizing the environmental settings, the rest is not difficult.

I would put apache in front and use mod_proxy as a reverse proxy to the apps.
Say your REST API is at http ://localhost:9000. If the angular app is only static assets you can deploy it directly under apache. If not you reverse proxy it as well.
For the REST api yoivsetup a reverse proxy for say /api to localhost:9000. So any request hitting the apache at http://some.host.name/api will now be forwarded to the legacy system. Now fix the angular app and you are done.
For local development you can use node-http-proxy which is ease to setup in a similar fashion

Should we use ApacheCXF or EJBs for communicating the logic and web modules?

We are currently developing a web application for college and we would like some advice from a more experienced developer.
We have a backend using Hibernate to operate on a MySQL database. Another project is the web UI that uses the API delivered by the backend (registering user, fetching data associated with certain profiles etc.). We use the JSF framework (RichFaces) for the UI. Everything is built using Maven.
The technology we can't decide on is for the communication between UI and logic modules. The first option is to use ApacheCXF to provide SOAP webservices that UI can be a client of. The second option is to use EJBs to invoke backend methods from the UI module.
What approach is more widely-used? As far as we read on the Web, using EJB is faster than SOAP webservices. On the other hand, we don't have any experience with EJBs using Tomcat (we would prefer using Tomcat since it seems to be a cheaper option, however we don't know what we would have to do in order to use EJBs with Tomcat). Additionally, working with webservices since the beginning will allow us to add support for different platforms (for example, Android).
Another aspect which we are discussing is about how should the application be deployed. The alternatives we have considered right now are:
Deploy it as a single WAR project (which would solve the problem we have about communicating the UI with the backend of our application).
Deploy two WAR projects in the same server using webservices for communication between the projects. (We have a prototype using this approach deployed on a Tomcat server)
Deploy a WAR project and EJB project.
Deploy an EAR project which would contain the references to the WAR and EJB projects. (We have a prototype using this approach deployed on a Glassfish server)
The project right now is starting, so we will only be handling a couple hundreds of users right now. However, if the project succeeds we would need to deal with a couple million of users.
Any advice would be appreciated. Thanks.
Edit: So any advice about how the project should be deployed? Is it necessary to use EAR? Is there any advantage if we deploy the project as an EAR module?
Edit 2: We found the advice we needed on this thread: Deploying java applications (Tomcat/Glassfish)

First things first. I would avoid using Web Services if there's no need for it. If you feel that you might need to call this system from external programs and platforms, then go for it. Even then, I would only use the web service interface for external integration, and still have an internal EJB implementation.
EJBs are awesome for enterprise applications. I would highly recommend that you look into that. They provide support for EJB Pooling, Transactions, Aspect oriented programming, Security, Stateful sessions, Java Messaging, JNDI etc. And you can inject them directly inside a Managed Bean (JSF). You said that you will eventually handle millions of users, so I assume that you will want your application to run as fast as possible, I don't think SOAP web services will be a good fit. Remember that SOAP web services encode messages as text, so if your application will be sending binary files etc, then you'll suffer significant performance issues.
As far as deployment goes I would go with an EAR, or a WAR for the JSF and and EAR backend. you can use Injection to pull the classes you need, even remotely, from multiple web applications and other EAR apps.
I'm not sure why you say Tomcat is Cheaper. Glassfish open source edition is a fully functioning JavaEE6 Server and its free. JBoss is also JavaEE compliant and is free. both of them are used in lots of production environments. I find glassfish to be much more user friendly, and would recommend it to EJB noobs :)
I also started with Tomcat, but now I don't use it at all. why use the servlet container only, when you can have the whole shabang? hope this helps.

we use ApacheCXF at work and its has SOAP and Restful. Reliable and relatively easy to setup. I am not sure why you want to use glassfish maybe it's preference but you can implement your projects in eclipse too. It's really that is up to you and your team and the requirements and skill sets your team may have to build and support, that a side CXF webservice+apache + eclipse with maybe two war files would be a good path.

I wouldn't use web services in this case. You can use managed beans as controllers.
Put the logic into EJBs, views into rich faces and control the flow using managed beans.
If you use maven you can generate a project with the structure of EAR (war for web module and jar for ejbs). I don't remember the name of an archetype but you can find it easily.

Adding a web interface (Spring MVC) to existing Java application

I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.

If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.

It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.