Matt RaibleMatt Raible is a writer with a passion for software. Connect with him on LinkedIn.

The Angular Mini-Book 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 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.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.
You searched this site for "java web frameworks comparison". 2,229 entries found.

You can also try this same search on Google.

[ANN] Cargo 0.1 Released

Vincent Massol has released Cargo 0.1 - an open source project to start/stop and configure Java containers. I'm using its Ant tasks in Spring Live's sample app in conjuction with jWebUnit and Canoo's WebTest and it works great. Here's some sample code:

    <target name="test-web" depends="war"
        description="Runs tests that required a running server">
        <taskdef resource="cargo.tasks" classpathref="classpath"/>
        <cargo-tomcat5x homeDir="${tomcat.home}"
            output="${test.dir}/cargo.log"
            workingDir="${test.dir}/tomcat5x" action="start">
            <war warFile="${dist.dir}/${webapp.name}.war"/>
        </cargo-tomcat5x>
        <property name="testcase" value="WebTest"/>
        <antcall target="test"/>
    </target>

Read more about Cargo's beginnings on TheServerSide.com. This initial version provides:

  • A Java API to:
    • Start containers
    • Stop containers
    • Configure containers for deployment in any user-specified directory
    • Wait for containers to be started
    • Wait for containers to be stopped
    • Supports WAR and EAR static deployments
  • Ant tasks that wraps the Java API

Good stuff - thanks Vincent!

Posted in Java at Sep 11 2004, 08:47:17 PM MDT Add a Comment

[DJUG] JMX and JDO 2.0

Last night I attended the local Denver JUG meeting. Chris Huston gave a presentation on JMX and Dion gave a presentation on JDO 2.0. Below are my notes from the event.
-----------------------------

Java Management Extensions one of the first JSRs and now included in to JDK 5. Monitors health of the system. Alter sys-admin of error conditions. Provides capability of to view and modify runtime parameters.

MBeans are deployed in an MBeanServer and their capabilities are exposed through Connectors. Then tools talk to these connectors to get their information.

JMX is covered by two separate specifications: JSR-3 (MBeans) and JSR-160 (Connectors). BTW, Chris has some good slide-making capabilities - I'll have to get some tips from him for my next preso. For example, he shows an entire class and its methods, then he fades it and zooms in on certain methods and highlights them to explain what they do.

Four types of MBeans: Standard MBeans, Dynamic MBeans, Model MBeans and Open MBeans. More info on these Mbeans can be found at http://docs.sun.com.

Standard MBean: All you need to do create an interface for your class your class name with "MBean" appended to it.

In order to deploy, you need to create and configure an MBeanServer. You can create an MBeanServer using javax.management.MBeanServerFactory.createMBeanServer(). MBeanServers keep track of MBeans using a javax.management.ObjectName. After creating and configuring an MBeanServer, you simply need to register your MBean using an Agent. All pretty simple so far, right? Now you have to use a Connector to expose your MBean to the outside world.

"Connectors are the fly in the ointment." MX4J is an open source project that has good Connectors: i.e. RMIAdaptor and HTTPAdaptor. There's also SNMP Adapters from a number of commercial vendors. In order to solve the current lack of good Connectors we have JSR-160: Distributed Services Specification. This JSR defines one connector: JMXConnector (part of JDK 5).

Chris is now showing us a counter widget deployed as a Swing app and managed using MX4J's web interfaces. Very cool stuff - the ability manipulate runtime parameters. As Chris stated - the real power of JMX will come from the tools. I wonder if there's MBeans available for monitoring webapps - seems like there'd be quite a market for management beans you could just drop in and deploy.

Notifications are another feature of MBeans and can be sent by an MBean. Two important interfaces: NotificationEmitter and NotificationListener.

Chris gave a good introduction to JMX, but I don't see myself using it anytime soon. It seems to be something that framework and container developers might use, but not many application developers. Maybe I'm wrong - are you deploying MBeans as part of your web applications? Chris mentioned that Hibernate and Spring have MBeans as part of their distribution - anyone using these? If nothing else, it's great to know that JMX is available if I ever do need to monitor and control applications.

-----------------------------
Now Dion's up after a 1/2 hour break with announcements. Dion is talking about JDO 2.0. I think JDO would be a lot more popular if it wasn't for Hibernate. Hibernate seems to have done JDO better and faster.

What is JDO?

  • Allows for object persistence
  • "I have objects, some need to be persisted"
  • "Keep state and behavior together. That is the OO way."

JDO Main Objectives:

  • To enable pluggable implemenentations of data stores into application servers
  • To provide applicaiton programmers a Java-centric view of persistent information, including enterprise data and locally stored data.

Other Objectives:

  • Transparent Persistence
  • Persistence-by-Reachability
  • OO framework on top of potentially non-OO stores.
    • RDBMS (98% of the time)
    • Files
    • TP Monitors
    • Legacy
    • Properietary
  • Integrate with existing technologies
  • Java compatible - no need to learn new language
  • Usable in managed and non-managed environments
  • Define easy semantics for caching objects
  • Ability to run in all Java platforms (J2SE, J2EE, J2ME)

When JDO first started, a bad thing happened - the object database guys were heavily involved. JDO 1.0 had 80% of its Expert Group from object database vendors. JDO 2.0 got object guys off the committee and real-world (relational) folks onto it.

JDO 1.0: Most of it is not very new - just a standard way of implementing persistence. Other proprietary tools already accomplish most of what JDO is.

JDO 2.0 Strategic Goals:

  • Easy to Use
    • natural programming model
    • configuration and deployment
  • In a Wide Variety of Environments
    • J2SE (rich clients)
    • application, web servers

JDO 2 Status: First Early Draft Review is out there. Soon there's going to be a Community Review - then things will start rolling after that.

JDO 2.0 Goals:

  • Maintain JDO 1.0 Compatibility (big thing with Sun)
  • Standardize Mapping to Relational DB (was vendor extension in 1.0)
  • Multi-tier Development Improvements
  • Usability Improvement
  • Better Object Modelling
  • Richer Queries - JDOQL, SQL and Named Queries
  • More Vendor Support - try to get Hibernate and Oracle on the bandwagon for political reasons

Dion's take on politics between EJB 3 and JDO 2

  • Let's get a standard around transpanent persistence first
  • Let's have a standard that can be shared between various groups: J2EE, J2SE, J2ME
  • Why have more than one O/R mapping specification?
  • Specifications such as EJB could be an umbrella spec for the cross cutting concerns

Why are people even arguing about it? Money. Because companies have invested a lot of time and money into X technology and therefore they bash the other. This problem might be solved by an O/R Mapping JSR that both EJB and JDO have to adhere to.

JDBC vs. JDO

JDBC JDO
SQL-oriented Object-oriented
Explicit intrusive code Fully transparent
Manual mapping Automatic mapping (automatic == create XML file)
RDBMS-centric Universal

JDO will use all J2EE services inside a container.

Deployment time scalability - database becomes bottleneck as number of users increases. JDO middle tier can relieve this load on the databse. JDO's configuration can be altered at deploy time to handle better scalability through caching.

JDO 2.0 Multi-tier Development - big thing is disconnected objects through attach/detach. Very simple API for detaching and re-attaching objects. Internally there's a version that's used to determine if the object is the same one.

JDO and EJB
As opposed to Entity bean, JDO instances...

  • May have subclasses
  • May exist outside a container
  • Has 1 optional interface to implement
  • Accessible as transient objects

And as of JDO 2 (new and improved object modeling!)

  • Persistent Abstract Class Support
    • map abstract classes to tables
    • map properties, fields to columns
    • create new implementation instances
  • Persistence Interface Support
    • map interfaces to tables
    • map properties to columns
    • more, but I missed them

Some argue that JDO is what Entity Beans should have been!

  • JDO is "purer" way to use OO
  • Since Entities should be used via local interfaces, why not just do Session Facade -> JDO objects
  • CMP in Sun AppServer uses JDO

Some argue that JDO complements Entity Beans because Entity beans can use JDO.

EJB3 is totally moving directorys with regards to Entity Beans, and they are much more like JDO.

EJB3 EntityManager == JDO PersistenceManager == Hibernate Session

JDO and Connector Architecture - JDO is NOT a framework, but plays well with others!

The JDO architecture uses the J2EE Connector architecture for application servers. The JDO PersistenceManager is a caching manager as defined by the J2EE Connector architecture.

A PersistenceManager may define the following Connector components:

  • ResourceAdapter
  • ConnectionManager
  • ManagedConnectionFactory
  • ManagedConnection
  • LocalTransaction

Persistence Contract (behind the scenes)
- To achieve transparence, JDO:

  • Defines a PersistenceCapable interface
  • Used too mandate binary compatibility among all vendors (optional in JDO 2)
  • Uses tools to make a class persistence capable

- Declares any fields available for persistence storeage

- Defines methods that allow JDO instance management

  • jdoIsDirty()
  • jdoIsDeleted()
  • jdoMakeDirty()

JDO has a number of callbacks that you can implement: jdoPostLoad(), jdoPreStore(), jdoPreClear(), jdoPreDelete().

In JDO 1: one interface: InstanceCallbacks
In JDO 2: InstanceCallbacks purely extend interfaces: LoadCallback, StoreCallback, etc.

Ways to make classes persistence capable: byte code enhancement, annotations (maybe for JDO 2.1).

JDO Interfaces: PersistenceManagerFactory, PersistenceManager, Transaction (new set/getRollbackOnly() in JDO 2) and JDOHelper (class with static methods, for use by persistence-aware classes), Query, Extent. You'll probably never use an Extent; like "select * from table". Represents all instances of a class or subclasses.

A persistence cabable class is just a POJO - you could use the same class for JDO and/or Hibernate. A default contructor is required in JDO 1, but not in 2.

JDO 2.0 has "use cases" for lazy-loading. This enables you to configure fetching based on certain situations. Sounds pretty cool.

Extent is usually optimized for better performance. If you're selecting all records from a table, you're probably better of using Extent vs. Query in order to avoid OutOfMemory errors.

New in JDO 2: ability to specify query filters in other languages - i.e. SQL or HQL or user-defined. These languages are up to the JDO vendor to implement.
JDO can use stored procedures if you map it in your metadata.

JDO 2.0's Query API looks very rich. It allows you to limit your results to certain properties/columns, as well as set what type of to return.

JDO 2.0 supports obtaining a java.sql.Connection from PersistenceManager. However, this may reduce portability since not all SQL is portable b/w databases.

Overall, I thought this was a great talk by Dion. If you're looking to start working with JDO 2.0, I'd recommend JPOX (also see JPOX with Spring or Tapestry). Unfortunately, their implementation still requires you to "enhance" your classes at build-time, but hopefully they'll have a transparent mechanism for manipulation (i.e. cglib) soon.

Posted in Java at Sep 09 2004, 10:06:42 AM MDT 6 Comments

CSSBeauty.com

From the Aspect Log (which is mighty nice BTW), I found CSS Beauty. Very cool - CSS is the bomb. Subscribed.

Posted in The Web at Sep 04 2004, 10:05:14 PM MDT 2 Comments

Commons Validator with WebWork?

I'm in the midst of integrating WebWork into AppFuse. I started wiring validation last night. This morning, I realized that I could probably use Commons Validator to make validation a lot easier. Here's why:

  • WebWork validation rules are defined per-action, rather than per-object. This makes it difficult to define the validation rules with XDoclet. I can't just put tags in the model object to generate the validation rules. This works with Struts and Spring quite nicely.
  • Using a custom LabelTag, I've been able to hook into Commons Validator and mark fields as required. With WebWork's validation, it seems that this can only be accomplished by adding a required="true" attribute to my <ww:textfield>. I prefer the transparency of the custom tag.
  • I've never been able to get WebWork's client-side validation working. Commons Validator has excellent client-side validation support.
  • Spring has support classes for Commons Validator - leading me to believe that I can configure validation in Spring and re-use its JavascriptValidatorTag.

Now I just need to figure out 1) how to hook WebWork custom tags (or my own custom tag) into the validator to mark fields required and 2) how to write a validation interceptor that uses Commons Validator. Whaddya think? Are there advantages to using WW's validation over Commons Validator? Any tips for writing an interceptor or modifying the custom tags?

Posted in Java at Sep 04 2004, 11:10:08 AM MDT 4 Comments

Fix Tab to drop-down in Firefox on OS X

Firefox is a great browser as most of you probably already know. I recently switched to using it as my default browser on OS X because Safari is flakey with GMail. One of the annoying things about Firefox on OS X is you can't tab to drop-downs in a web page. No longer my friends - in this month's Macworld there's a solution!

In Firefox (or Mozilla), type about:config in the address bar. Then search for "accessiblity.tabfocus". Change the value to "3" in order to allow tabbing to all form elements, or "7" if you want form elements + links.

Now if I could only get my two favorite Safari features in Firefox: auto-fillin of forms and spell-checking as you type.

Posted in Mac OS X at Sep 03 2004, 03:47:08 PM MDT 10 Comments

No G5 PowerBooks Anytime Soon

Mac Rumors: No G5 PowerBooks Anytime Soon. If I had a vote, I'd say it's time to give up on the G5 for the PowerBook and make OS X run on Intel or AMD chips - then produce an Intel/AMD version of the PowerBook. Apple makes great hardware, but their laptops are much slower than their Intel counterparts (for Java at least). All I want is a PowerBook that can keep up with an Intel-based laptop - is that too much to ask?

Posted in Mac OS X at Sep 01 2004, 04:18:34 PM MDT 16 Comments

Going to ApacheCon?

Are you heading to ApacheCon this year? I am.

Thank you for your recent session proposals for ApacheCon US 2004.

The following session has been accepted and scheduled.

  (1010) 'Comparing Web Frameworks: Struts, Spring MVC, WebWork, Tapestry & JSF'

You will receive more information about this soon,
if you haven't already.

Vegas baby. :-P

Posted in Java at Aug 27 2004, 03:48:48 PM MDT 5 Comments

MyEclipse VP is blogging

Wayne Parrott, the VP of Product Management at Genuitec (makers of MyEclipse) has started a blog.

For the past 3 years I have been involved with a great team at Genuitec (www.genuitec.com) of which I am a founder. While my title at Genuitec is VP, Product Management, I think of myself more as an Eclipse technologist and product delivery specialist. These days I spend most of my professional time working on Genuitec's MyEclipse Enterprise Workbench product. A quick fly by of my resume looks something like this: several startup failures, numerous consulting engagements, and some really cool work on the Human Genome Project and NASA's AI Section that dates back to the '80s.

Very cool! I love it when companies get closer to their customers via weblogs. Now we just need to get Wayne to start blogging some tips and tricks.

Posted in Roller at Aug 27 2004, 04:22:52 AM MDT 3 Comments

Eclipse tip o' the day

By default, Eclipse expects all its plugins to be in $ECLIPSE_HOME/plugins. This doesn't work too well for upgrading since you have to copy all of your installed plugins to Eclipse everytime you upgrade. To solve this, you can place all your plugins in an external direct and point to them using a link file. To do this, create a links directory in $ECLIPSE_HOME and create a file inside it that points to an alternate location. The name of this file doesn't seem to matter, but it must end with a ".link" extension. In this file, put a path:

path=C:\\Tools\\myplugins

Then in c:\Tools\myplugins, create an Eclipse-like directory structure so you end up with c:\Tools\myplugins\eclipse\plugins. Then drop your plugins in that directory. If you choose to use an alternate workspace as well, upgrading Eclipse will be as easy as copying in your links folder. BTW, here's more information on upgrading Eclipse.

Posted in Java at Aug 25 2004, 07:35:52 PM MDT 10 Comments

Tapestry and Hibernate Tutorial

Wanna use Hibernate with your Tapestry application? Or maybe learn about Tapestry for the first time? If so, Warner has a great set of tutorials. His first tutorial on creating a CRUD application with Tapestry was exactly what I needed - right when I needed it - thanks Warner! I'm looking forward to his next tutorials, especially Spring, Hivemind and Lucene. Integrating Spring with Tapestry is pretty simple - we'll have to see how Hivemind compares.

Posted in Java at Aug 24 2004, 09:40:49 PM MDT 2 Comments