The Angular Mini-Book is a
guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and
deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.
Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.
For book updates, follow @angular_book on Twitter.
The JHipster Mini-Book is a
guide to getting started with hip technologies today: Angular, Bootstrap, and Spring
Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.
This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.
For book updates, follow @jhipster-book on Twitter.
I'm writing about how to use the same login/error page with form-based authentication. Does anyone know which servlet containers this fails on? I guess it wouldn't hurt to know which ones it works on too. You can use this security.war (1.7MB) file to test. Since it's testing the failure page, you don't need to setup a user - but if you want, the role is tomcat. I know this works on Tomcat, so no need to test it.
I'm digging into JAAS this afternoon as I enjoy the vacancy of the Winter Break at DU's Penrose Library. Man, what a great school - I used to love it when we'd get off 6 weeks for Christmas Break - from Thanksgiving through January - how sweet is that!?
The reason I'm writing on this cold (32°F) afternon is to get some thoughts on JAAS in web applications. I'm giving it about a paragraph of coverage, explaining that it's mainly for declaring authentication and authorization in policy files. Furthermore, it's only invoked when running your application (or Tomcat) with a security manager. However, it's not really needed in web applications because 1) container-managed/web.xml is good enough, and 2) authentication mechanisms never really need to be that fine-grained. Whaddya think? Am I wrong, does it deserve more coverage? Don't most app servers use JAAS under the covers?
I've gotten approval from Wrox to use struts-xdoclet as my sample app for my chapters on Security and Struts. I've also received committer rights from Ted Husted on the Struts project at SourceForge. I haven't checked anything in yet, because I still don't have a good name. While I think struts-xdoclet is a good descriptive name, it doesn't have the pizzazz I'm looking for. So the naming discussion continues. I'm thinking of actually leaving "Struts" out of the name as it seems to make other names more difficult when combined. I like the idea of kindling, which we use to start fires at the cabin, but I don't know if that makes a good app name.
Back to the point of this post, what are your recommendations for a good open source license? I don't really care how people use struts-xdoclet, so do I even need to license it? What happens if I don't include a license?
A Struts WML Tag Library has been posted to the struts-dev mailing list. It's a "pre-release", which means the project is probably not stable, but I'm guessing the technology and tags are.
Struts-wml taglib, 'raw prerelease' is available here:
http://sourceforge.net/projects/struts-wml/
Here's the release notes:
This is a fully functional 'prerelease' which includes source code, sample
application, documentation, binary and libraries. It's still somewhat
unpolished (therefore raw prerelease). If you're willing to hack arround
with it a little bit, you're welcome to download it. Please don't forget to
contribute your changes back to the project! [Full Post]
Now it's your responsibility to get a WML project that you can implement this on!
The skiing was great at Vail today! I might not be able to walk tomorrow, but so goes the first day of the season.
There was all kinds of good info from the java.blogs community, and so I re-emphasize, for the heck of it. My favorites (thanks Erik and Dave):
I spent most of the day today in the library, pounding away on my keyboard trying to get a good start on my first chapter, Security in Web Applications. I put together suggested outlines for my two chapters over the weekend, and I'm posting them here for your review. I tried to convert them to PDF, but then decided to leave them as Word documents so you can 1) see the outline view, and 2) comment in-line if you'd like. I'll also post the PDF version (thanks to FastPDF).
It was difficult getting started today, but once I got moving, I found that the words just kinda flowed out and it was rather enjoyable. The bad news is that I have until Friday to complete some 40-odd pages and I'm going skiing tomorrow with Julie's uncle, Chris Voda. Actually, the skiing is the good part, it'll clear my head and get me ready to write like a coder in the zone.
Erik Hatcher has released his "much hyped and long awaited sample application" demonstrating how to generate some Struts goodness with XDoclet. You'll be happy to know that I've been swapping e-mails with Erik a lot in the past couple weeks - so my struts-xdoclet app is very similar. Here are the details:
It is a trimmed down version of the application Steve and I developed for our Java Development with Ant book. Relevant to Struts folks are these tidbits: - XDoclet is generating struts-config.xml, validation.xml, web.xml, and antbook.tld - LabelTag (currently mysteriously busted for required tagging) is included. This tag styles field labels differently if its in error, and (when its not busted, it works on my production app actually) it shows an asterisk by required fields. - strutsgen: a one-off starter generation for JSP's and ApplicationResources.properties snippets for cutting and pasting into the main application. It uses XDoclet to process a specified form bean and uses the fields it finds for generation. - Use of StrutsTestCase for Cactus testing. - Maybe some other Struts goodies lurking there that I've forgotten to mention. The application itself is a document search engine, based on Lucene, and should run out of the box in Tomcat or JBoss. It even has the ability to (at build time) toggle between whether to use a session bean or not (functionality is the same either way). By default, you can simply deploy the WAR that you've built and it will work without EJB, but if you are interested in exploring the session bean piece it can be turned on. I am in the process of creating much more detailed documentation, but I wanted to get this out sooner rather than later. If you find any problems or have any questions, please do not hesitate to let me know so I can refine it and post updates. The one documentation I need to provide now is to note that you'll need j2ee.jar to build. I include all other API's. To build, unzip the file (link below) and it will expand into JavaDevWithAnt directory. In that directory, run Ant. If you have J2EE_HOME set you shouldn't need to do anything... just "ant". You'll also need to build a site index, so run "ant build-site-index". This is intentionally two separate steps. If you don't have J2EE_HOME set, then you need to provide j2ee.jar to the build. Do it this way: ant -Dj2ee.jar=/path/to/my/j2ee.jar Where "/path/to/my/j2ee.jar" is the actual path to your j2ee.jar Post any questions/problems to me directly. E-mail me at [email protected]. Download: http://www.ehatchersolutions.com/downloads/ You will need JUnit 3.8(.1) as I take advantage of the new lack of required String-arg constructors. junit.jar should live in ANT_HOME/lib. Ant 1.5(.1) is required also. There will be updates in the next week or so as I polish the documentation and address any issues that turn up. Erik
I've decided that I need a new name for struts-xdoclet. "Struts-XDoclet" is just too hard to say - try it, you'll see. Four syllables is just too many. Since I intend for it to be a Struts/XDoclet Jumpstart Kit, I'd like something that tries to signify that, but then again, I like POGN - Plain Old Good Names. SXJK is just as hard to say as Struts-XDoclet. I was thinking SASSY (Struts App Start ... nothing for S and Y) might be a good one - but doesn't really explain much. It'd be cool to name it Abbie, after my daughter, but I don't think sxd (hey, that might be a good one) will be that earth-shattering, and if I'm going to name something after Abbie - it better be good! I just asked Julie and her idea is to name it "struggle" - that's not bad. It eliminates the struggle in building a new webapp. Please comment your suggestions if you have an opinion.
I'm going to record a few items from my JSP 2.0 and Servlet 2.4 research tonight. I hope you don't mind.
From JSR 152 (JSP 2.0):
We plan to incorporate two main new features into JSP, and a few incremental features. Additionally we expect to incorporate erratas and clarifications as well as opportunistic improvements.
The two key features are the use of JSP to author custom actions, and adding expression language support into the container. The main goal of this JSR is to deliver these new features into the JSP specification in a timely manner. This goal will likely limit what other features can be incorporated.
So (to me) this means that if you know JSTL, you already know half of JSP 2.0. And the best part of JSP 2.0? One main theme of this update of the JSP specification is that we want to simplify, not complicate, the view of a JSP that most users, specially page authors, have.
From JSR 154 (Servlet 2.4):
Servlet 2.4 will be a relatively small upgrade to the existing API. Since the technology is highly popular, we have a large number of small requests for enhancement to the API that we would like to be able to accommodate. Over and above that, Servlet 2.4 will address the following areas in a portable manner:-
* Modularization of the deployment format
The goal is to achieve a level of modularity with the deployment format which is not currently possible using the current DTD based deployment descriptor. The intent is to enable this modularity to manage the organization of deployment information of related technologies that use the web container as the underlying platform. These frameworks include dependencies on other J2EE components, JSP technology, JavaServer Faces, JAXM, JAX-RPC and other frameworks that build on servlet semantics.
Hmmm, this almost sounds like the module idea in Struts. Does this mean they want to allow sub-applications (or modules) within a web application? After a little research, it appears that the 2.4 spec will allow you to add new namespaces to your web.xml file, and therefore, you can extend the deployment descriptor for your own needs. Look for vendors to use this, as well as UI Frameworks like JSF. The top of your web.xml will resemble the following on 2.4 container:
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://
java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">
Also on the list:
* Enhancements to the security model
- Provide a facility for logging out of web applications portably
- Clarify, possibly by adding API or deployment syntax, the relationship between HTTP session state and authentication state
* Smallish enhancements to the filter and listener models
- Provision of deployment syntax for declaring API dependencies between elements in a filter chain
- Addition of request and response level listeners and event notifications.
Cool, sounds like good stuff. Logging out of web applications portably? You mean there's more we can do than invalidate the session? I wonder what else there is to logging out? Maybe it'll remember the last page the user was on? No such luck (but you can do that with Cookies). It appears that there's a strong effort to encourage vendors to implement single sign-on for webapps. Tomcat is the only one I know that does this now. HttpSession has a new logout method - if the servlet container implements single signon, the logout logs the client out of all web applications on the servlet container and invalidates all sessions associated with the same client. I guess this is cool if you have more than one webapp on your server. Now we just need an API to allow webapps to talk to each other on the same container. I guess you could call this HTTP, but I want something better than that. Another interesting item I found is that you'll be able to use a servlet as your welcome-file, which is currently not allowed in the 2.3 spec.
So how do these new specs influence how you write your webapps? It doesn't seem like there's much that's new, and certainly no ground-breaking features. So learn Struts, so you'll have a headstart on JSF, and learn JSTL, so you'll know the expression language used in JSP 2.0. If you've been put off by writing tag libraries, it'll be easier with JSP 2.0, as you'll be able to use JSP fragments as a type of tag library. Lastly, if you're not using container-managed authentication (i.e. BASIC, FORM), you might want to consider it. The thing I like most about container-managed authentication is that you can bookmark pages in an app, and then get right back to them by entering a login/password - this is how it should be vs. login -> main menu -> bookmarked page. You can use filters to restore any session or request information that is needed for the bookmarked page.
Pheww, boy am I lucky! I copy-pasted this post before I tried to submit it, and whaddya know, Chimera crashed after I hit the "Post to Weblog" button!
James Strachan has encouraged me to use Maven for my struts-xdoclet project. I should give Dave some credit too, as he has also suggested this through e-mail. Here's my delimma, it'll probably take me anywhere from 2-4 hours to figure it out and integrate it. Does it buy me that much functionality to make it worth it? And my biggest fear is that it seems to help you produce a "project website" - that has a Jakarta look to it. I'll end up spending hours and hours tweaking the look and feel of that sucker - which provides no real value at all. But I'll do it because that's how I am. So to answer your suggestion James, I'm afraid to integrate with Maven, as I'm scared to create too much more work for myself with my already tight deadlines. Volunteers are welcome ;-)