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.
From the Struts download page:
Log4J Users Please Note - A packaging error has been
uncovered that caused the copy of commons-logging.jar included
in the Struts 1.1 Beta 2 release to be built incorrectly. If you are using
Log4J for your logging needs, you will need to download the Commons Logging
1.0.1 release (convenient links are provided in the
logging directory) and replace your copy of
commons-logging.jar with the one found in the 1.0.1 release.
is released! Your 1.0.x application should work just fine with this latest release - if they don't, post a question to the Struts User List. One reason to upgrade (in my opinion) is that my favorite features, Validator and Tiles, are now part of the core package. And they are now easily configured as "plug-ins" in your struts-config.xml file. Here is how I configure them in my application:
<!-- ========== Plug Ins Configuration ================================== -->
<!-- Validator Plug-In Configuration -->
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property property="pathnames" value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>
</plug-in>
<!-- Tiles Plug-In Configuration -->
<plug-in className="org.apache.struts.tiles.TilesPlugin">
<set-property property="definitions-config" value="/WEB-INF/tiles-config.xml" />
<set-property property="definitions-debug" value="0" />
<set-property property="definitions-parser-details" value="1" />
<set-property property="definitions-parser-validate"
value="true" />
</plug-in>
There is also DynaBeans which make it easy to configure a FormBean in your struts-config.xml file without creating a concrete .java file. Here's an example:
<form-bean name="messageForm" type="org.apache.struts.action.DynaActionForm">
<form-property name="toName" type="java.lang.String"/>
<form-property name="toEmail" type="java.lang.String"/>
<form-property name="subject" type="java.lang.String"/>
<form-property name="content" type="java.lang.String"/>
</form-bean>
Sam Ruby explains how he creates a theme switcher for his site. For some reason, my little bit of DHTML (javascript and CSS) seems much simpler than a perl script.
Did you know that XHTML 2.0 is already in the works? As you all throw up your hands and say, "Geez we were just getting to know XHTML 1.0 (and 1.1)," I'm here to tell you that there haven't been many changes since XHMTL 1.1. 
Here is an example XHTML 2.0 page.
I expect the Struts 1.1 Beta 2 to be released in the next day or two, and the final 1.1 release to be somewhere around the end of August. Apparently, if you're using XDoclet to generate your struts-config.xml file, you'll have to wait for the next XDoclet release to add the new message-resource and plugins xml files to your merge directory. I checked out the latest xdoclet source from CVS tonight and found the new documentation to be very clean and impressive. A very nice UI.
Have you ever heard of antville? I hadn't, but sounds cool:
antville is entirely written in JavaScript and based on Helma, a powerful and fast scriptable open source web application server (which itself is written in Java)
Hmmm, interesting. I don't know about "entirely written in JavaScript" though - sounds kinda fishy to me.
a couple of days ago, and I love it! It's a GSM phone, and I don't know if they're all this way, but it sounds clearer than my home phone. It almost sounds like I'm in the same room as someone when I'm talking to them. This is a big plus for me as I've always been annoyed by the bad sound of my previous phones.
I can check my raibledesigns.com e-mail using the IMAP4 protocol, and I can also check my Yahoo! Mail anywhere I can get a signal. Very cool - helps to cure my e-mail addiction. I hooked it up to my Powerbook G4 via infrared with GSM Remote and was able to have all my contact's numbers in almost no time.
from the Chief Developer of Tomcat and Struts:
> On Fri, 9 Aug 2002, Matt Raible wrote:
>
> Struts Dev Team - please verify my hypothesis below.
>
> I believe the Struts JARs and the DBCP JARs from common should be the
> same. After all, Struts does use the DBCP in it's distribution. You
> might want to upgrade to the latest build of Struts (which includes
> DBCP and Logging, among others). I know they're planning on releasing
> 1.1 Beta 2 this weekend.
>
The story is somewhat convoluted (I *hate* class loaders :-), but it goes
like this:
If you are going to use a JNDI datasource, then both your webapp AND
Tomcat need to see the same copy of the JDBC driver and the dbcp classes
(for 4.1.x) -- and the way to make that happen is to put the driver into
common/lib.
Because commons-dbcp.jar is there, it's dependent jars (such as
commons-collections.jar, jdbc2_0-stdext.jar, and (recently added)
commons-lang.jar) need to be in common/lib as well. Plus, of course,
jndi.jar if you're on a 1.2 system.
Having any of these JARs duplicated inside the webapp causes a problem
in 4.x based systems, because they try to use the local copy first -- and a
copy if foo.bar.MyClass loaded from the webapp is *not* the same class
as a copy of foo.bar.MyClass loaded from common/lib. This is a place where
Tomcat's modified class loader model causes grief (but only because you're
trying to use the same classes that Tomcat internally is trying to use -- if you
were using something like GenericDataSource with your own copy of the
connection pool, it would not be a problem).
One workaround for this would be to try turning off the modified loader
delegation model, by putting something like this in your server.xml file (or in
a context configuration file on Tomcat 4.1.x.):
<Context path="/myapp" ...>
<Loader delegate="false"/>
</Context>
This *should* let you have a copy of all the JAR files inside your webapp,
as well as in common/lib, but not cause any conflicts.
Please let me know, one way or the other, if this works -- it's clearly a
desireable goal that you can ship a WAR file with all the included commons
JARs but not have problems like this. I want to review how Tomcat's default
configuration can make this easier. And, from a Struts application perspective
(not just for Roller), this is a pretty serious usability issue.
> HTH,
>
> Matt
>
Craig McClanahan
PS: In Tomcat 4.1.x, the "deploy" command of the manager app lets you include
a context configuration file in the WAR, at location "META-INF/context.xml". So it
might still be possible to configure a single WAR that works correctly in Tomcat
4.1.x and still works in other servers (that would obviously ignore such a file).
Thanks for the clear and concise definition of how this all works Craig. So basically, in Tomcat 4.x, don't keep duplicates of your JARs in $CATALINA_HOME/common/lib AND in yourApp/WEB-INF/lib, OR turn off the modified loader delegation as specified above. Tomcat 4.1.x looks very cool, I'm just curious to know why they're on a Beta Release of 4.1.8, but still no official release?
ever get fixed? I submitted the patch on November 28, 2001. Granted, I submitted it wrong, but the newest standards in Struts seem to be a low priority.
