I am working on a full-stack spring-java based web app. The app is current divided between two projects each of which produce a war file on build. One project (call it UI) serves as the front-end of the app. UI doesn't have much business logic in it. Mostly HTML templates, and JS/CSS and other resources. The other project (call it Server) carries a whole lot of weight in terms of providing auth, business logic, DB services, REST API for external world etc.
I am running into quite a few problems especially while making security work throughout the app given UI project has no direct way to authenticate a user or checking user roles etc. UI relies on invoking a REST OAuth2 password flow to Server to authenticate. So authentication itself works fine but I am having a tough time checking user access roles or any other fine grained permissions within any code in UI project.
Before I dig a whole lot deeper and try to make this all work, a couple of questions for the gurus here:
a) Is this design one of the acceptable ways to build web apps?
b) Are there any gotchas that I should be aware of if I attempt to bundle the two projects within one war?
I hope this is to the point but let me know if you need any more details, and I will be happy to add color.
Try another concept for separation:
Module 1 = core business logic -> produces jar file on build
Module 2 = web -> produces war file on build
Module 2 depends on module 1. All security stuff goes to module 2.
Hope it helps.
Related
I have the current configuration:
a GUI team develops the Angular app in a separate project and builds all TypeScript stuff to produce the final UI app.
another team has Vert.x java library in the server app to do REST service and produces a final fat jar.
I wonder what's the best approach to deliver GUI and backend in one shot:
Is is ok to have 1 jar for backend and Gui (say a directory call "app") both in the same folder? Can vert.x access resources outside its jar?
Do I have to put GUI in the same maven project where my vert.x REST services are developped, run the "ng build" commands from maven, and package all in one jar?
I'm a bit confused here.
Any of you are in the same situation, what's your advice on this?
Thanks
All it's upto you how do you wanna deploy it on production ;)
First approach
You can create one fat.jar to deliver everything in it -> so it will include angular static build files (under webroot) and then all your vert.x related code.
Second approach
You can create one fat.jar just with angular static files exposed using vert.x and also you can integrate authentication (cas/saml) in the same and another fat.jar will have rest implementation (connecting to database or WebService consumption ). So you will have two fat.jar and it will be best if you are planning for clustering and for hazel cast structure.
We have already tested both approaches and both are working great but Right now we are following second approach !!
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.
My understanding of a GWT module is that it is a "unit of reusability".
My understanding of an EntryPoint is that it is a module that is mean to interact with a client browser. Thus, I think of an EntryPoint as sort of an "executable JAR", and a module as a library JAR or DLL.
My understanding of a fragment is that it is a sub-component of a module used for the purposes of deferred binding and codesplitting.
So first, if I am incorrect on any of these assertions, please begin by correcting me or clarifying things for me!
If I am correct, then it is obvious that you decompose a module into fragment based on need. You write your module, you test it every which way, you review your soyc compiler reports, and if you see bottlenecks, you begin to fragment and codesplit as necessary, yes?
But how do you decompose an app into modules and entry points?!? Again, I'm sure it all comes down to need and is application-specific. I just read this article on structuring a GWT app, and although it was quite helpful, it still didn't provide any litmus or set of guidelines for decomposing an app into modules/entry points.
I am already planning on splitting my app into two modules: a WebModule and an AppModule. The WebModule would be the "public" portion of the app (the website, if you will), and the AppModule will be downloaded after the user successfully logs in (I do this for security purposes).
But beyond that, I'm not really sure as to how to break my AppModule out into other modules, and how to determine whether or not those modules need entry points. So I ask: if you fragment a module to circumvent network latency issues with the code download, when/why do you modularize an app, and when does a module need an entry point?
EntryPoint is not a seperate module. It is part of a module and has a function which will be invoked when the application is started.
The point of modules is to group logical functionality so you can share code between different projects. Nothing else. GWT already comes with a bunch of modules (HTTP, Activity, Places, Debug). You may have a COMMENT or a USER module in your application if you decide to group it like that.
Codesplitting should only be used where needed. It can be a major annoyance that you can only reference code beyond fragment boundaries through the GWT.runAsync(). I suggest you only take this step if you experience your application being slow to load.
We have a couple of Java Web applications that serve different purposes (one for the public and one for internal administration) but work on the same database. We keep most of our business and database logic in a project a third project that is included in the two projects and this works well.
However, now we want to share presentation logic between the applications. (In other words we want to have the same pages controlled by the same action classes appearing in each application.)
What is the best way to accomplish this goal? Can JSPs be stored in in jars and used? Can two web apps refer to common jsps? Are there good ways for the two applications to share session data so users can go back and forth between applications?
Following can be done to achieve what you are planning:
Create a common EAR having multiple Web/EJB projects for your application. Thus all the WebApps can reside inside a common EAR file and can use common JARs kept at EAR level.
Just like a java project can depend upon another Java project, a Web Project can also depend upon other Web Projects. Hence create a common Web Project with JSPs and Utility Classes. Add this common Web Project to the Build Path of other Web Projects. They would inherit the JSPs and Java classes, and can have their custom JSPs as well.
The above would provide you the basic framework. There is no standard way for Web Apps to share data. If you want users to use common session you can use SSL or token based session maintenance. Session data from one App cannot be replicated to the other, but you can put some logic inside an EJB which can be called from both Apps there by linking them in a clean way.
The fact that you want to share presentation logic and session data betwen both application shows that these two apps should be merged in a single one, where administrators simply have more privileges than simple users.
We had similar problem. We wanted to share JSPs between several projects. JSPs can be stored in one base web project in maven war package. Then you can share this resources from base project (JSPs, CSS, Javasripts, etc.) as a maven dependency and you can override particular JSPs, CSS etc. in dependent project. It works very well for us and we don't need to e.g. repair one same JSP in many projects.
For detailed information, see: maven overlays
I have an application which is a portal application and I want to allow other users add their applications to it. In order to do this I need some way to be able to access their applications in mine. Is this possible?
You cannot put WARs inside of other WARs. You need an EAR file to contain WARs, EJBs, etc. One way to implement inter-WAR communication is to package that logic directly in the EAR. It all depends on what you're trying to do.
the way to do inter .WAR communication is by the method
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletContext.html#getContext(java.lang.String)
ServletContext.getContext(URIOfOtherWAR_resource)
I've used this succesfully for doing what you're talking about.
Maybe you need a plugin system or portlet, so your user will not develop a war application but include their portlet inside your application (war). There's a standard : JSR 168 and several implementations :
http://developers.sun.com/portalserver/reference/techart/jsr168/
As others have pointed out, embedding WARs inside WARs is not an option. However, I may have a workaround for you.
Most Web containers I'm familiar with have a "test deployment / auto deploy" mode / capability, where they will automatically deploy an application if the WAR is copied into the right directory.
Your portal application could certainly allow uploading WARs, and it could store the uploaded bytes in a given directory under a given file name. Your Web container could do the rest. You could then link to the new application from your portal, or whatever. All this is relatively easy to do.
However, be advised that this is a horrible idea if there is any security concern whatsoever. You are essentially allowing your users to execute arbitrary code on your server. Unless you completely trust all potential users to be both non-malicious and perfectly competent (think infinite loops), you are asking for a lot of trouble here.