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.
Easy Struts 0.5.0 just released. This is a code generator that seems like a nice product - I've installed it, but never used. I think these types of tools are great for developers that love to use an IDE. If you're like me and you prefer a good ol' text editor - this tool won't help you.
is now available.
http://www.jamesholmes.com/struts/
Struts Console is FREE software. This release adds support for the IntelliJ IDEA IDE, one of the favorites of many developers.
Changes with Struts Console v2.1
I don't use the Struts Console, but it does look like a nice product. I DO like IDEA, so it's nice to see the compatibility. I have installed it with Forte4J (now Sun ONE Studio 4) and it seemed to install and work pretty well. On my current project, I don't modify the struts-config.xml enough to really use a visual editor. I usually just use Homesite or XML Spy - of course, it helps that I know the struts-config DTD.
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>
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.
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.
You might try adding autoReconnect=true to your JDBC URL. Hat tip to Stephen Chambers, who seemed to offer the solution on the Struts User List today.
If you're a CVS/Windows user, and you're not using Tortoise CVS, you might want to look into it. It integrates nicely with Explorer and has recently had a 1.0 release. Thanks Francis Irving! Once you've installed it, try Timo's icons. They're my favorite out of the choices listed.
I missed this one by a long shot (released 7.17.02), but I'll tell you anyway. StrutTestCase is a shortcut to using cactus to test your Struts Actions. Use it, it will descrease your development time.
I also am a little partial to this release since I helped Deryl get it working with LookupDispatchAction and Tiles. He did a great job in getting it all to work after I sent him the bugs. I had the easy job ;)
StrutsTestCase for JUnit - release 1.8 -------------------------------------- This release introduces improved support for Struts 1.1, provides several requested enhancements, and fixes many reported defects. The StrutsTestCase library is now available as four distinct releases supporting both the 2.2 and 2.3 versions of the Servlet specification, and both the 1.0.x and 1.1 versions of the Struts Framework. The StrutsTestCase library supports Struts 1.1b1 and the latest nightly builds, as well as Cactus v1.3 and JUnit v3.7.