Wazi » Kimberly McClintock

Open Source Database Applications Comparison Matrix

Kimberly McClintock — Wed, 07 Jan 2009 16:15:48 +0000

Use this comparison matrix to learn about the differences between – and relative benefits of – the popular open source databases MySQL, PostgreSQL, Derby and H2 Database Engine (H2DB).

Over the years, offerings in the sphere of Databases available from the open source community have become faster and more reliable and, with that, increasingly popular choices for enterprises globally and across a broad swath of industries. As with a number of other categories of project, open source databases now compete on equal footing with established proprietary offerings such as SQL Server and Oracle. In fact, studies and polls executed in the last few years consistently indicate that MySQL and PostgreSQL both rank in the top ten databases used by enterprises; MySQL frequently appears in the top three along with SQL Server and Oracle.

The following tables represent research completed in the fall of 2007 by OpenLogic. We went to the experts — members of the OpenLogic Expert Community who are committers and expert users of the projects — and asked them to answer a set of questions. Experts in MySQL, PostgreSQL, Derby and H2DB responded. Use the resulting information as a tool to plan your projects.

The five questions we asked the experts appear below. To view the detail on the projects* compared across each question, click the question.

What’s the ’sweet spot’ of your project? For what type of projects should users strongly consider it?
What type of scenarios does your project not fit into as well? Would you recommend another project in this scenario? If so, which one?
Of the projects included here, which have you tried? Of those, which ones did you like or dislike, and why?
What is the future of this project? What’s coming that will ease development?
Are there myths about this project that you’d like to challenge?

For comprehensive information on each project, search the OLEX Open Source Library. For a list of the open source developers we interviewed, click here.

*While no version of the projects is specified, you can assume that the information relates to the latest version in our library at the time of the last update.

Summarized Response

What’s your project’s ’sweet spot’? For what type of projects should users strongly consider it?

This is a summary of the responses. For full detail, click here.

Project	Summarized Response
MySQL	It supports replication of primary-secondary out of the box. It provides good handling of national languages (you can set collation and encoding per database, table, column). It executes simple commands (select/insert/update/delete) quickly. It is multiplatform.
PostgreSQL	It’s great for Web based applications doing either ‘daily chores’ or research projects. It’s fast and easy to use. Updating is easy. Update and replication can be automated with tools. Good documentation.
Derby	Operates in both embedded mode and on a network server. Supports Java based stored procedures, and provides a good deal of flexibility in data manipulation. Tight security features distinguish it from other open source offerings. Good for CDC devices.
H2 Database Engine (H2DB)	A fast SQL database. It’s good in Java unit test scenarios requiring a SQL database and accessing any SQL database with the JDBC API (using the H2 Console tool). Great documentation.

Return to the questions list.

What type of scenarios does your project not fit into as well? Would you recommend another project in this scenario? If so, which one?

This is a summary of the responses. For full detail, click here.

Project	Summarized Response
MySQL	Any scenario requiring logic in the database. Not so good for complicated queries. MySQL is not the best choice if the administrator needs to give hints to internal query planner (basically only USE INDEX). Triggers and stored routines have many restrictions (for example one cannot use transactions inside routines or use statements which returns resultsets).
PostgreSQL	One requiring a full journaling system. Use a lighter database system (like dbm) if all you need are very simple key/data pairs.
Derby	High availability and replication are not supported. It’s not suitable for applications with hundreds of transactions per second or databases larger than 10 gigabytes. Not suitable for any kind of warehousing scenario, or a scenario which involves the manipulation of spatial data.
H2 Database Engine (H2DB)	Applications that need a large database. Scenarios in which many (3 or more) connections concurrently access the same database.

Return to the questions list.

Of the projects included here, which have you tried? Of those, which ones did you like or dislike, and why?

This is a summary of the responses. For full detail, click here.

Project	Response
MySQL	PostgreSQL: liked In my opinion Postgresql is most the mature open source database engine. It’s powerful, full-featured, efficient and robust. Of particular note are the following features: Procedural languages: postgresql makes it possible to write database functions in many languages like java, perl, python, php. It’s very useful to explain analyze command, and it shows and measures queries via query planner. A query optimizer with a couple of optimization algorithms. A rich SQL dialect: foreign keys, views, procedures, triggers. Contrib package – extensions which are developed outside postgresql.
PostgreSQL	MySQL: didn’t like I found it cumbersome. It lacks concise documentation. It may be faster than PostgreSQL in some circumstances, but if a developer needs to spend twice the time to make it all work, it is not worth it. From the tests I have seen, MySQL and PostgreSQL are pretty much equal in access speed. (Speed issues may arise depending on how you use the database and all systems have advantages and disadvantages in that area.) Especially annoying in MySQL are the documents that indicate functionality that doesn’t exist or doesn’t work as described. It’s possible that the docs referred to a different version, but the appropriate version was not made clear. This made the docs unusable. Outside of that, the SQL commands are in general similar, though PostgreSQL has more functionality. This allows more granularity in your day to day programming of the database.
Derby	PostgreSQL: liked I vote for PostgreSQL when enterprise level features like clustering and high availability are required. Migration from PostgreSQL to ORACLE is very easy and it makes PostgreSQL a good choice for projects that may need to be ported to an ORACLE database.
H2 Database Engine (H2DB)	MySQL: liked Easy to use, very stable, fast. The licensing could be clearer and it’s not Java. PostgreSQL: liked Easy to use, very stable, quite fast, clear license. Not Java. Derby: disliked Wish it were easier to use. Wish documentation were better. It was not as stable as others I have used and as its reputation led me to believe.

Return to the questions list.

What is the future of this project? What’s coming that will ease development?

This is a summary of the responses. For full detail, click here.

Project	Summarized Response
MySQL	Falcon, a new storage engine.
PostgreSQL	Adherence to SQL standards. Faster queries. Simplified upgrades.
Derby	More efficient replication. Higher availability. Greater support for XML.
H2 Database Engine (H2DB)	Performance enhancements. Better documentation.

Return to the questions list.

Are there myths about this project that you’d like to challenge?

This is a summary of the responses. For full detail, click here.

Project	Summarized Response
MySQL	That it is dual licensed.
PostgreSQL	Because it is free, it must not be any good.
Derby	That it doesn’t perform as well as other open source alternatives.
H2 Database Engine (H2DB)	That Java is slow. That transactions lack durability.

Return to the questions list.

Complete Responses

What’s your project’s ’sweet spot’?

This is the full response. For a summary of the response, click here.

Project	Response
MySQL	MySQL has the following strengths: It supports primary-secondary replication out of the box. It handles national languages well (you can set collation and encoding per database, table, column). It executes simple commands (select/insert/update/delete) quickly. It is multi-platform. Given these strengths, it’s the best platform for use developing Web sites because these kinds of projects demand a database that can respond quickly. In Web environments, more than half of the operations required of the database involve reading data. Given that MySQL supports database replication out of the box, it makes scaling sites and Web services easier. The primary advantage of multi-platform support is scalability. I’ve worked in environments that began by installing MySQL on a single PC, then two, then a SUN SPARC server followed by several Intel IA-64 (Itanium) servers, and eventually two IBM PowerPCs with AIX; with all of them running MySQL as the database server. Additionally, some of the developers had a local copy of MySQL installed on theirs laptops/desktops. Very convenient.
PostgreSQL	Postgresql is also very well documented, with easy to read chapters, many examples that work, and information properly organized by version (7.4, 8.0, 8.2…).
Derby	Apache Derby is a pure Java RDBMS (Relational Database Management System). It can operate both in embedded mode, and as a network server. Derby supports Java based stored procedures, and provides a good deal of flexibility in data manipulation. The tight security features of Derby make it a unique open source database. In addition to regular SQL grant and revoke mechanisms, Derby allows you to configure several options to a determine connection authentication source (LDAP, Built-in, etc.), and also to utilize database encryption using JCE facilities. Derby supports four common isolation levels, and it operates by default in READ_COMMITED mode. In addition, it supports backup/ restore operations and crash recovery for transactions not committed, if for any reason the database crashes. Derby can be used on any J2ME enabled device with support for CDC/Foundation 1.1. Having different versions and modes makes Derby the most suitable database for many projects. For example: those designed for CDC devices, desktop applications which can use embedded mode, and server side applications with multi gigabytes databases that can utilize network server mode. All of these modes and versions have the same functionality, which makes the development cycle less complex.
H2 Database Engine (H2DB)	H2 Database Engine’s sweet spot is Java applications requiring a fast or embedded (or both) SQL database. Another strength is Java unit test scenarios requiring a SQL database and accessing any SQL database with the JDBC API (using the H2 Console tool). Finally, the terrifc documentation makes it a good choice for developers unfamiliar with SQL.

Return to the questions list.

What scenarios does this project not work as well in?

This is the full response. For a summary of the response, click here.

Project	Response
MySQL	One which demands putting logic into a database (complicated stored procedures, triggers). For this kind of projects PostgreSQL or Oracle are a better fit. As mentioned before, MySQL is good for simple queries, but not so good for complicated ones (for example, a project with joins from many tables, sub-queries, grouping etc). This is especially true when the tables contain a large amount of data. In my opinion, it doesn’t fit in environments like Data Warehouses or Data Mart. Some other MySQL drawbacks include: The administrator can’t give hints to internal query planner (basically only USE INDEX). Triggers and stored routines have many restrictions (for example, one cannot use transactions inside routines or use statements which return resultsets). Higher level languages like plpsql or script languages like Perl or Python can not be used to program logic in a database.
PostgreSQL	Even really large projects can use PostgreSQL without much of a problem. The one thing that Postgresql itself does not offer is a full journaling system. Instead, it relies on your file system to ensure data integrity. This means PostgreSQL needs to run with ext3, NTFS or an equivalent file system. I do not know of a database system that replicates a full working journal. Yet if you need to use ext2, FAT or some other non-journaling file system, you would need such a system. On the other hand, these days you should not be using ext2 or FAT or any similar file system anyway. Again, I would recommend a much lighter database system (like dbm) if all you need are very simple key/data pairs. Thus, very small projects should use their own system.
Derby	The current version of Derby does not support high availability and replication, although in the next major version there will be out of the box support for replication and high availability. Derby is not suitable for applications with hundreds of transactions per second, or for databases larger than 10 gigabytes. Additionally, Derby is not suitable for any kind of warehousing scenario, or for any scenario which involves the manipulation of spatial data. That said, there are workarounds for some of these issues. Using Sequoia can resolve high availability and replication issues, for example. For all of the above scenarios, PostgreSQL is the most suitable project because of its stable engine, enterprise level features like clustering and high availability, and supports for spatial data.
H2 Database Engine (H2DB)	Applications that need a large database or scenarios in which many (3 or more) connections concurrently access the same database. Non-Java applications, of course, and instances when the processing of XML documents is required.

Return to the questions list.

Of the projects included here, which have you tried? Of those, which ones did you like or dislike, and why?

This is the full response. For a summary of the response, click here.

Project	Response
MySQL	PostgreSQL: liked In my opinion, Postgresql is the most mature open source database engine. It’s powerful, full-featured, efficient and robust. Of particular note are the following features: Procedural languages: postgresql makes it possible to write database functions in many languages like java, perl, python, or php. It’s very useful for explaining analyze command, shows and measure query via query planner. A query optimizer with couple optimization algorithms. Rich SQL dialect: foreign keys, views, procedures, triggers. Contrib package – extensions which are developed outside postgresql.
PostgreSQL	MySQL: didn’t like I found it cumbersome. It lacks concise documentation. It may be faster than PostgreSQL in some circumstances, but it’s not worth it if a developer needs to spend twice the time to make it all work. From the tests I have seen, MySQL and PostgreSQL are pretty much equal in access speed. (Speed issues may arise depending on how you use the database, and all systems have advantages and disadvantages in that area.) Especially annoying in MySQL are the documents that indicate functionality that doesn’t exist or doesn’t work as described. It’s possible that the documents referred to a different version, but the appropriate version was not made clear, therefore the documents were unusable. Other than that, the SQL commands are similar, though PostgreSQL has more functionality. This allows more granularity in your day-to-day programming of the database.
Derby	PostgreSQL: liked I vote for PostgreSQL when enterprise level features like clustering and high availability are required. Migration from PostgreSQL to ORACLE is very easy and it makes PostgreSQL a good choice for projects that may need to be ported to an ORACLE database.
H2 Database Engine (H2DB)	MySQL: liked Easy to use, very stable, fast. The licensing could be clearer and it’s not Java. PostgreSQL: liked Easy to use, very stable, quite fast, clear license. Not Java. Derby: disliked Wish it were easier to use. Wish documentation were better. It was not as stable as others I have used, and as its reputation led me to believe it would be.

Return to the questions list.

What is the future of this project? What’s coming that will ease development?

This is the full response. For a summary of the response, click here.

Project	Response
MySQL	The most significant plans for MySQL involve a new storage engine called Falcon. This engine will likely replace innodb/myisqm. It’s in an early stage of development, but it looks promising. If you’re interested in why such a move is necessary, here’s some background. Currently, MySQL version 5.1 supports several storage engines, or methods of storing data on disc drives. But usually only two types are used: MyISAM and InnoDB. MyISAM is the default engine. It’s fast, architecture independent, and has full text search indexes. However, since it’s not transactional, it’s not ACID compliant. This disqualifies MyISAM in scenarios which demand data consistency. Also, it doesn’t allow foreign keys. Every table in MyISAM is stored in separate files. This issue opens the possibility of data corruption. InnoDB is a transaction safe (ACID compliant) engine. It allows locking data on row level, foreign keys, constraints, etc. Tables and indexes are stored in tablespaces which can be partitioned. But InnoDB has drawbacks. It is slower than the MyISAM engine, it doesn’t have full-text-search indexes, and there are some problems with AUTO_INCREMENT indexes. Possibly the biggest issue, however, is that InnoDB was developed by InnoBase, and InnoBase was acquired in 2005 by Oracle. Needless to say, the future of InnoDB in MySQL was uncertain. Hence the development of Falcon, a new storage engine developed by MySQL AB. The Falcon Storage Engine has been designed with modern database requirements in mind, and particularly for use within high volume Web serving, or other environments that require high performance. It’s still in the alpha stage and still taking shape, but plans are in place for features such as: Optimizations for multiple CPU environments (multithreading). True Multi Version Concurrency Control (reading/storing data with efficient locking). Advanced indexes. Data compression stores. Intelligent tablespaces (disk management). Implicit save points (for keeping data integrity). From a legal and business perspective, MySQL is in no way obligated to Oracle if it switches to the Falcon project.
PostgreSQL	Postgresql is already in use by companies with databases of about 32 Tb with tables having million of rows; and it just works. What else do you need?! Seriously, like any complex system, it still has some gray areas. For instance, the project is investing energy into improving adherence to SQL standards. Another area of focus is the continued improvement of compatibility, and the filling in of holes in functionality. Still another is improvement of the search algorithm in order to speed up queries. Finally, we are working to ameliorate some issues with the update process. Right now it is classic, but cumbersome, particularly for large databases. The user must dump the database, stop the old system, start the new system and then restore the database in the new system. We are working on a tool named pg_update that would “simply” update an existing set of tables to a newer version of PostgreSQL.
Derby	There are several plans for further development of Derby. One of the most important features, which will make it easier to use and more efficient, is primary/secondary replication, and improvements to availability. Another area of development involves working on new XML processing features and enhanced support for XPath and XQuery over Derby XML type. Security enhancements are also on the way, as well as the implementation of more features defined in SQL 2003 mandatory and SQL 99 core. The latter will make it easier to write complex SQL statements for Derby.
H2 Database Engine (H2DB)	Project developers are enhancing Derby and adding new features. Some of these are: Optimization for improved performance in larger databases. Improved concurrency. Various ease-of-use features. Documentation improvements. Improvements to extensibility.

Return to the questions list.

Are there myths about this project that you’d like to challenge?

This is the full response. For a summary of the response, click here.

Project	Response
MySQL	People tend to believe that MySQL is dual-licensed because it can be used as GPL software or as commercial software. MySQL is not dual licensed. Additionally, people sometimes misunderstand the GPL, and that frightens them off; but that’s a separate topic.
PostgreSQL	Since PostgreSQL is free software, many people believe that it can’t possibly be reliable, fast, fully featured etc. In fact, PostgreSQL has most of the features you can find in other DBMSs like Oracle and Microsoft SQL. Not only that, it also includes many very useful features that are specific to PostgreSQL, such as user defined types (not just a record… a full user defined type! With functions to execute when operators are used against variables of that type, etc.). In terms of security, Postgresql is one of the best databases I have seen. First of all, it runs as postgresql (not root as some others do). Next, by default, the administrator user is not root or admin, but rather a common user of your choice and postgres. Once chosen, that user can do all the things you need a database administrator to do: create other users, databases, and tables; and assign rights, roles, and groups to other users. The database system is reliable because the entire system is thoroughly tested for at least one month before any given release. As a result, we have only rarely encountered issues with reliability.
Derby	Derby’s performance compared to other open source databases is much discussed, and was the subject of a talk at ApacheCON 2005. Viewing that – available on the project wiki – should put any questions to rest.
H2 Database Engine (H2DB)	That it is slow because Java is slow. That transactions in H2 are less durable than other in databases. In my view, this is not true.

Return to the questions list.

Acknowledgments

OpenLogic would like to thank the following members of the OpenLogic Expert Community for their contributions to this effort and invite the community to email us (docs-at-openlogic-dot-com) if they’d like to augment, correct, update, refute or dispute any of the information included herein.

Project	Contributer
MySQL	Krzysztof Krzyzaniak
PostgreSQL	Alexis Wilke
Derby	Masoud Kalali
HQ2DB	Thomas Mueller

The Six Elements of Open Source Governance

Kimberly McClintock — Fri, 19 Dec 2008 18:03:09 +0000

There’s a rumor going around that the be-all-end-all of open source governance is scanning. Scanning an effective CYA on governance? Bollocks, we say. One component, but not the whole story. Scanning will help you figure out what you’ve got, alright, but then what? How do you know if what you’ve got and what you’re doing with it are copacetic without a policy or two? And once you’ve done the work of figuring out what you’ve got, how you’re using it, and you’ve got those policies in place, how do you keep that information current?

Each of these questions scratches the surface of concerns we think are urgent, and they’re not addressed by scanning alone.

The rumor mongers have an agenda, and you’d be right to suspect that we do, too. We are, after all, the company behind OpenLogic Exchange (OLEX), which comes in an Enterprise Edition that’s designed to cover all the bases of open source governance. However, rest assured that the point of this article is not to push our solution so much as to share the thinking behind our solution. If you can put together another stack that covers the bases we lay out for you here, more power to you.

Governance of Open Source in the Enterprise - Six Elements

What you really want is open source governance that’s so easy you (and your users) will barely know it’s there. We’ve done this a gazillion times, and we’ve boiled it down to Six Elements:

Policies – First, decide what Is OK and what Is Not OK
Inventory – Figure out what you got
Provisioning – Figure out how you’re gonna get more…
Managing – …while following the rules from #1
Auditing – Circle back and confirm that everything’s still going ok
Reporting – Gift-wrap that “OK” to show you care (and give them sparkle for the board slides)

Approach these elements roughly as steps and they’ll lead you through a set of exercises that determine comfort level and current usage, establish monitoring and control of what’s used and where going forward, and result in the creation of a sustainable system going forward.

You’ll notice ’scanning’ is not mentioned at all here. That’s because we believe scanning is a means, not an end.

Policies

Scan to your heart’s content, but unless you’ve got a policy or policies in place, how in the world do you know if the open source you find in use in your enterprise is “okay”, or not? What’s “okay”?

To answer that question, you need to know some stuff, and then you need to create an open source policy. The questions below include the basic questions you and your organization need to be able to answer. A comprehensive open source policy includes bits of items #2 through #6 in this list, and we’ll get you more detail on each of those later.

1. Legal Stuff: How and why are you using open source software? Policies should reflect a broader strategy — do you have one? Has your legal team vetted open source licenses? Which open sources licenses are considered enterprise friendly for your use case? Are different licenses acceptable for open source packages that are used in-house versus packages that are embedded in distributed products (e.g., products given to partners or offered for sale)? Distribution is the key concept here, as many open source licenses contain special clauses invoked only in situations where code is distributed downstream.

2. Getting It: How is open source currently evaluated and approved in your organization? Where do users get the source once a package has been approved for use? Is there an open source review board that defines the request and approval process, or are requests submitted to department managers, each with a different review process and risk tolerance threshold? Is there a repository where users can find and download approved packages, or do employees download open source from the Internet whenever they want? Where is all this usage information tracked? Who is the responsible party within the organization? The goal of these questions is to determine what the standards are across the enterprise. Key to governance is ensuring that users all follow same process by making it policy.

3. Using It: Are employees allowed to modify open source code, and can they contribute code changes back to open source communities? If code contributions are allowed, can employees use company email addresses when posting changes? Are employees allowed to participate in online discussions using their corporate email address? How do any of these policies apply to contractors, offshore resources, or partners?

4. Updating It: What are the guidelines for managing version updates? Open source projects typically release more often than commercial software companies, and most CIOs don’t want 30 different versions of a particular package deployed throughout the enterprise. Do new version releases need to go back through the evaluation and approval process before they can be deployed? Version upgrades are often necessary for security reasons, but multiple versions can also present problems when it comes to support. Which brings us to…

5. Supporting It: Is open source support required for some of the packages you use, all packages, or just specific ones? Can employees get support from the open source community mailing lists, and, if so, can they post questions using company email addresses? Or do some/all/specific packages require commercial-grade technical support (which, by the way, you can get from OpenLogic — just an FYI because, seriously, we’re in this for money as well as the glory).

6. Communicating: How does the organization track and audit all of the above (or at least the most relevant parts), and how are results reported? Also, how often are audits conducted, and who’s responsible for auditing and reporting? How does your policy apply to software already in use vs. software currently in development?

Not to toot our own horn, but we know a thing or two about this stuff. We’ve been teaching Fortune 500 companies how to realize the benefits of open source software for ten years. We offer open source policy workshops as well as one-on-one guidance for organizations looking to create or improve their open source policy. We also help organizations evaluate and select the open source packages that best fit their needs. Just sayin’.

Ok, so once you’ve got your policies in place, it’s time for a scan.

Inventory

All an inventory does is tell you open source software you got, and where you are using it.

Not to get all existential on you, but before you go crazy with an inventory, we suggest you first ask WHY. Why do you, X guy at Y company, why do YOU want or need an inventory of your open source? Here are some of the reasons we’ve heard in our work:

kickstart an open source policy
establish a baseline for ongoing auditing efforts
plan for support
manage security updates
manage risk
prepare to distribute, divest, or donate software
prepare for a merger or acquisition
comply with internal policies
comply with regulations
comply with open source licenses
manage intellectual property issues

The significance of these issues is weighted differently if the open source is intended for use internally, or it will be distributed. For example, your company may not have to worry too much about “intellectual property” issues if you only use open source internally. Generally speaking, it’s more important to scan for licenses or code snippets when it comes to open source that is distributed outside the enterprise, and concerns around technical support are more relevant to scanning for open source software used internally.

WHY simplifies HOW. There are two main approaches to how: ask people or scan. Asking people to tell you which open source packages, licenses, and/or code snippets they’ve got in use has obvious limitations. Scanning tools are more reliable, but there are a bunch of options available with varying levels of cost and complexity. With your “why” information in hand, you can select the scanning tools that give you the information you need that fit in the context of the resources (both time and dollars) you’ve got. There are several open source scanning tools you can use, but the options listed below are usually a good place to start if you are just a normal user of open source — since you can’t beat the price (FREE).

To scan for installed open source packages on a server or desktop, your best option is to go with OSS Discovery, a scanning application developed by OpenLogic that is both free and open source. OSS Discovery will tell you what’s installed on your machines, or what libraries your application is composed of, and it’s easy to download and run. OpenLogic also offers a free open source inventory analysis for up to 500 systems using OSS Discovery. Relatively painless.
To scan for open source licenses, you might want to try a solution like HP’s FOSSology. FOSSology finds open source licenses in source code or binaries and it’s a free and open source application. The learning curve on this one is a little high, but still well below planetary physics.

If you’re part of a software company or a company that distributes hardware that contains open source software, you may want to consider shelling out the bucks for a proprietary scanning tool. Keep in mind, though, that this option will also require some expert analysts to run the tools and sort through the results, so make sure you’ve got that in your budget.

The most complicated scanning options available look for open source code snippets in addition to installed open source packages and licenses. OpenLogic’s scanner, as well as scanners from Black Duck and Palamida, are the main options if you need this type of tool. Because the learning curve on these solutions is high, and the costs associated, you don’t want to go this route unless absolutely necessary. “Absolute necessity” might be, for example, if you need to be 100% sure that you won’t be obligated to release as open source the code in, say, the missile defense system your company is planning on selling to the government. If you need this level of coverage, there aren’t a lot of options, so be prepared to spend. Fortunately, most folks can get by with a more practicable level of diligence.

The important thing when picking a scanning solution is to start by defining your scanning goals. Once you do that, you can pick the right level of scanning that meets your needs. Be selective and avoid overkill, yet ensure you’ve covered all your bases — it’s quite possible that you could end up using different scanning tools to create the result desired in different realms of the organization. Also, keep in mind that creating an inventory won’t be a one time activity. Depending on your goals, you’ll want to inventory again in the future — for example when putting a new application into production or releasing a new product.

Next, you’ll want a place to report on and store your inventory results. You’ll also want to compare your inventory against your policy in order to see where you might have, let’s say, “circumvented” the policy. Once you’ve got your inventory cross-checked against your policies, you’ll need to do a little remediation, but then you’re caught up, up-to-date, and in the clear.

And what will you do with the results of cross-checking between policy and scan results? It would be best if there were a place to load the scan results that would log usage. If this place applied your policies, or checked against your policies and provided you a report on infractions, that would be best. A central open source governace tool, say for instance OLEX, might be a good option, but we’ll get a little further into that in a minute.

Provisioning

As you’re taking inventory of the open source you’ve already got, consider establishing a go-forward process that will govern the use of any new open source users need. Presuming you’ve taken our advice and put your policies in place, what you need now is a comprehensive repository of open source that’s safe, secure, and ready for deployment in the enterprise.

Funnily enough, the OpenLogic Library of open source is just such a place. We provide a tidy one-stop-shop that’s freely accessible through OpenLogic Exchange (OLEX). The OpenLogic Library offers the most extensive repository of enterprise-ready open source software on the planet. And “enterprise-ready” is not just marketing buzz in this case. If you download a “certified” open source package from the OpenLogic Library, you know that it has passed our 42-point certification process and meets basic standards of quality, usability, and community backing. OLEX provides you all the information you need to determine whether or not a package fits into your policies, and we also check daily for security issues and provide patches as they are released for all business-critical projects. When we find such an issue, we notify you via OpenUpdate — an HTML newsletter available to subscribers of OLEX Enterprise Edition. We also sell support on open source in case you find yourself needing such services.

The Request and Approval mechanism in OLEX provides part of the go-forward audit trail governance requires. You can, by policy, decide if a particular project can be used with abandon, requires approval, or should be denied. Policies can be applied to specific open source packages, specific versions of packages, and/or licenses. Users simply submit online forms, which are routed to reviewers for approval (if necessary) and stored for future auditing purposes. End result: OLEX ensures that all open source in the enterprise comes from a single source, adheres to the same policy, and can be easily audited at any point in the future. Again, access to the library is free, but the additional governance features require a subscription.)

Managing

So, now:

you’ve got your open source policies in place
you’ve scanned all machines and applications for installed open source in your enterprise and cross-referenced the results against your policies
you’ve done some remediation and established accepted baselines of open source packages in use
you’ve got a go-forward solution in place and employees are using a system like OLEX to enter requests to use specific open source packages

This all takes you a long way toward effective management of open source usage in your company, and we can all agree that management is the key aspect of governance. But at this point you’ll also want to take a look at your build and development practices and pull the scanning option back in. Add a scan of source code to your practices, and also scan any third party source code if you’ll be distributing the project downstream.

This set of scans is really the only way to be certain you’re meeting all open source license obligations, which is a key element in the effective, legal use of open source. Different licenses require different actions on behalf of the user, from nothing at all to acknowledgment of the original author to the inclusion of modified source code. Establishing and maintaining a firm hold on your license obligations is key to successful use of open source in your enterprise.

Auditing

Policy? Check. Inventory? Check. Repository for provisioning? Check. Approval process? Check.

By now you should have a good handle on your open source usage. But, you’re going to still want to check up on yourself every now and then. An audit will tell you how well all of your policies and processes are working.

You may want to audit a software application or solution based on development milestones at the end-stage of the development process, just before a new application goes into production or gets released. You may also want to audit a sampling of systems on a regular basis, such as quarterly or annually.

Typically you’ll use one or more scanning tools to conduct the audit. All the results should get tracked, stored, and compared to what your policy says and what’s been approved. You can look for any red flags — where what’s being used is different than what you thought — so that you can work on improving your process (and maybe having a friendly little chat with the offender). OLEX Enterprise Edition lets you upload scan results and provides reports showing any place where open source usage doesn’t match your policy and approvals.

The point is, scanning should play a continued role in your go-forward strategy. You’ll want to establish a process by which scans are routinely (annually, or more often) run on machines and applications, and the results are compared against reports of what’s been approved. OLEX provides these reports based on the open source usage requests submitted and approved, and it will also give you a heads-up if any in-use packages violate your policies. Further, OLEX can help you to see if you are falling behind in terms of released versions, and alert you to any security vulnerabilities that exist in the open source packages you are using. Pretty cool, huh?

With this information in hand, you’ll also want a process in place to evaluate corrections to the results of infractions indicated by auditing results.

Reporting

One client we’ve worked with has 4,000 machines in play — definitely not information that the most competent systems administrator can keep in her head. That’s why, whatever solution you choose for your governance needs, you’ll want a stack that includes reports. Lots of reports. For instance, you’ll want:

1. Inventory Reports: What open source packages are used, on which machines, as part of which internal development project. This will enable you to

Assess technical support needs
Manage security patches and version updates
Assess potential risks
Assess version aging and proliferation

2. Policy Compliance Reports: Where am I out of compliance with internal policy?

3. License Compliance Reports: Where am I out of compliance with open source licenses?

And that’s just a start. OLEX Enterprise Edition can provide these reports for you, so you can keep the “suits” happy and the developers developing.

Conclusion

What more can we say? We’ve given this a lot of thought. It’s our business.

Web Framework Project Comparison Matrix

Kimberly McClintock — Sat, 04 Oct 2008 23:57:17 +0000

A Web Framework speeds development by providing libraries to satisfy the common development needs of Web applications, and by promoting code reuse among engineers and over projects. For example, many frameworks provide libraries for establishing database access and managing user sessions. We’ve developed this comparison matrix to help you learn about the differences between – and relative benefits of – the most popular open source Web frameworks: Shale, Struts, Wicket, WebWork, Rails, JBossSeam, MyFaces and Spring. Although Rails is not a Java project, we included it given its popularity.

To help you make a decision about which Web Framework to use, we went to the experts — members of the OpenLogic Expert Community who are committers and expert users of the projects — and asked them to answer a bunch of questions about each project.

The Five Questions

The five questions we asked the experts appear below. To view more detail on the projects* compared across each question, click the question.

What’s the ’sweet spot’ of your project? For what type of projects should users strongly consider it?
What type of scenarios does your project not fit into as well? Would you recommend another project in this scenario? If so, which one?
Of the projects included here, which have you tried? Of those, which ones did you like or dislike, and why?
What is the future of this project? What’s coming that will ease development?
Are there myths about this project that you’d like to challenge?

For comprehensive information on each project, search the OLEX Open Source Library. For a list of the open source developers we interviewed, click here.

*While no version of the projects is specified, you can assume that the information relates to the latest version in our library at the time of the last update.

Summarized Responses

What’s your project’s ’sweet spot’?

This is a summary of the responses. For full detail, click here.

Project	Summarized Response
MyFaces	Separation of MVC layers reduces developer effort. Framework addresses every complex aspect of Web development. Developers can create new components or use existing ones. Many sources for additional components.
JBoss SEAM	Complex Web applications that need to integrate with other open source projects. Applications that have a long running business context. Complex applications Supports RESTful pages Supports AJAX functionality Uses new EJB 3.0 programming artifacts
Spring MVC	Projects that use – or intend to use – Spring Projects that need to expose business logic as HTTP addressable URLs Projects that must provides multiple view rendering techniques
Stripes	Projects in which developers must get productive fast Sensible defaults reduce the need for configuration Contains all basic components necessary for enterprise Web development tasks; avoids feature bloat Stable code base
Struts 1*	Struts 1 has essentially been replaced by Struts 2 and is not recommended for new projects unless the development team already has expertise
Struts 2* (WebWork)	Projects with developers familiar with Struts 1 Projects using Struts 1 who need productivity increase
Wicket	Projects that must create the typical stateful Web application that must track session state and perform services for the user. Ideal for developers who prefer a very clean separation of concerns and object-oriented programming New projects that need to get up and going fast Projects with teams that have UI members and programmers, working independently Single developer projects Projects requiring mailing list support
Shale*	Projects requiring exceptional JUnit /JMock based testing framework Projects requiring an XML-based alternative to JSP
Rails	Web applications depending on REST and/or AJAX Standalone Web sites

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

What sorts of projects does this package not work as well for?

This is a summary of the responses. For full detail, click here.

Project	Summarized Response
MyFaces	No native AJAX support No support for REStful pages Standard component set too limited for complex enterprise applications
JBoss SEAM	Stiff learning curve makes it a challenge for projects with junior developers Developers will need knowledge of JSF and some EJB 3.0 framework. Simple CRUD applications.
Spring MVC	Projects with a complex business model
Stripes	Projects that need to run in a context where Java5 is not available Established projects
Struts 1*	Struts 1 has essentially been replaced by Struts 2 and is not recommended for new projects. The following is included for purposes of comparison: Projects that will be deployed to a 1.5 JVM A lot of boilerplate code needs to be written for simple tasks A Struts application will always have more classes than an equivalent application written in a different framework
Struts 2* (WebWork)	Not recommended for any but new projects.
Wicket	Nearly completely static or completely stateless sites should avoid Wicket Projects with existing code
Shale*	Shale is “on-top-of-JSF” so can’t be used outside a JSF-app
Rails	Projects that require lots of enterprise integration

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

Of the projects we’re comparing, which have you tried?

These are summarized answers. For more detail, click here.

Project	Summarized Response
MyFaces	Seam: didn’t like Steep learning curve for the developer, including JSF + EJB 3.0. Its many libraries make it challenging to successfully deploy.
JBoss SEAM	No information available.
Spring MVC	Struts: liked A simple, mature web framework. Struts 1 is a bit heavy and tedious, but the newest version (Struts 2) blends the robustness of Struts with the benefits of WebWork and many lessons learned from the Rails framework. Webwork: liked A simple, mature, and lightweight framework. Configuration can be arduous. Development has merged with Struts and benefits from the experience and community of that project. Rails: liked Rails favors convention over configuration and goes a long way to making web application development simpler. However, it is still immature and lacks the breadth of features of Java web application frameworks.
Stripes	Spring: MVC: didn’t like Overly complex, too much configuration outside the code. Struts 1: didn’t like Hamstrung by the backward compatibility requirements. WebWork / Struts 2: didn’t like WebWork learned a lot from Struts 1, but still suffers from configuration pain.
Struts 1*	Spring MVC: didn’t like Overly complex, too much configuration outside the code. WebWork / Struts 2: didn’t like WebWork learned a lot from Struts 1, but still suffers from configuration pain. Stripes: liked Excellent framework, clean and simple, it simply keeps out of the way.
Struts 2* (WebWork)	Spring MVC: liked Respectable effort that no one should be ashamed of using. Stripes: liked Very compelling. Either would be a good choice for a project getting a fresh start. Wicket: liked Very compelling. Either would be a good choice for a project getting a fresh start. JSF: didn’t like is the EJB of web frameworks. Cool in theory. Hell in practice.
Wicket	Spring: liked I use it to configure my entire middle-tier, and it allows me to operate many similar sites by overriding pieces of configuration that may be different for that particular site. I’ve also used it for configuring custom back-office applications based on many components that I wrote, and wired together via Spring. Tapestry: didn’t like Worked with it for two years on an enterprise project at work. It had absolutely no transparency as to what was going on underneath the covers. It forced you to do things a certain way – the “HLS” way. Everyone involved with the project seemed religiously addicted to it, and only to doing it the “HLS” way, like he was a deity. It forced tons of configuration on you. Every release is a complete rewrite, and backwards-compatibility is constantly thrown out the window to suit the author’s current whims. The learning curve is extremely steep. I hear that version 4 is better, but I gave it up with version 3. Trails: didn’t like Didn’t try very hard. Couldn’t ever really get it to work well, although with more effort, that would’ve likely changed. Did not like Tapestry, so did not pursue further.
Shale*	Spring MVC: liked Cool, nice glue code, but there is a little overlap in Shale’s dialog and Spring Web-Flow (their JSF-version).
Rails	No information available. TODO

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

What is the future of this project?

This is a summary of the responses. For full detail, click here.

Project	Response
MyFaces	Community is writing the new JSR 314 Artifacts from Shale will probably make it into JSF 2.0
JBoss SEAM	Developers are simplifying this project by separating the add-on parts Project is related to the JSR Web Beans
Spring MVC	Easier configuration and better validation
Stripes	No major architectural changes Community has expanded to ensure response to requests
Struts 1*	Bug fixes
Struts 2* (WebWork)	No information available.
Wicket	Improvements to scalability Better support for stateless applications Full-featured Java 1.5 version planned More tightly-integrated support for Spring Role-based authorization
Shale*	Some artifacts from Shale will probably make it into JSF 2.0
Rails	Rails 2.0 is expected to be released by the end of 2007

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

What is the future of this project?

This is a summary of the responses. For full detail, click here.

Projecth	Response
MyFaces	No information available.
JBoss SEAM	Some developers think that JBoss SEAM is a J2EE standard, but it is not.
Spring MVC	Spring MVC and Spring WebFlow are not competing projects.
Stripes	Stripes has been dismissed as a “one man band” but it has a very helpful and constructive user and development community
Struts 1*	Struts has no support for AJAX. Developers also think that they will be required to use JSPs.
Struts 2* (WebWork)	No information available.
Wicket	URLs are ugly. That this framework is an infant version of Tapestry.
Shale*	That Shale is a JSF implementation
Rails	That Rails is all about code generation

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

Complete Responses

What’s your project’s ’sweet spot’?

This is the full response. For a summary of the response, click here.

Project	Response
MyFaces	The JSF/MyFaces Web Framework reduces developer effort by cleanly separating MVC layers. The framework addresses every complex aspect of Web development, including page flows, model validations, model conversions and page actions. Developers have the freedom to create new components from scratch, or launch development from existing components. Because JSF/MyFaces represents the standard implementation, developers have another resource for components: the many open source solutions available. The list include ICEFaces, Ajax4JSF, Apache Trinidad and Sun Sandbox.
JBoss SEAM	JBoss SEAM allows developers to code many types of complex, multi-window, transactional web applications more easily using EJB 3.0 as M(Model) layer and JSF as VC(View-Controller) layer part of the project. It supports RESTful pages, provides AJAX functionality, and eases the development life cycle by using the Java annotations heavily. It provides new EJB 3.0 programming artifacts easily, so while developers need to learn this functionality, they do not have to be experts to begin. This set of tools works well on projects aspiring to integration with other open source projects. Finally, SEAM extends the classical session, request, and application scope with new defined context. This makes it a good choice for applications that have a long running business context containing more than one request.
Spring MVC	Because the Spring MVC Web application framework is tightly integrated with the Spring application framework, it is best suited for projects that use – or intend to use – Spring as the basis. It provides a simple way of exposing business logic as HTTP addressable URLs and provides multiple view rendering techniques.
Stripes	Stripes, a Java servlet presentation framework, is an ideal fit for many Web based applications, large or small. Stripes offers a clean design with simple concepts that allow developers to get productive fast. Annotation based configuration was designed into the tool, and sensible defaults reduce the need for configuration to be explicitly stated. Finally, a carefully controlled code base keeps the tools from the feature-bloat that makes competitors unwieldy while not compromising on the basic components developers will need to do the classic enterprise Web development tasks.
Struts 1*	Although Struts 1 has essentially been replaced by Struts 2 (also in this list), and is not recommended for projects commencing today, it is still in use and extremely popular with enterprises so we’ve included it here. Struts 1 provided an excellent fit for projects that involved form submission. When Struts was first released developers migrated to it from home grown servlet frameworks. Struts gave the industry a defacto standard for developing browser-based applications. Two notable sites using Struts 1 are http://www.virgin-atlantic.com and https://www.21st.com/.
Struts 2 (WebWork)	Struts 2, WebWork renamed, is an excellent web application framework of the “action controller” family. Due to similarity of paradigm, those tens-of-thousands of developers out there that are familiar with Struts 1 can learn Struts 2/WebWork in a matter of a day, realizing huge productivity increases. At the time my team made that transition about 3 years ago, we estimated about a 40% productivity increase in work on the web application. This is due to the (what was at the time WebWork was built) “next generation” features that WebWork introduced upon the “action controller framework” paradigm. Validation, auto-form handling, type conversion, interceptors, etc. all add up to having a real usable tool set, without having to entirely change the way you “think”. If a team is coming from Struts 1 and looking for a quick worth while change, WebWork/Struts 2 is for you. It vastly improves upon Struts 1, and has features that are quite competitive against the newer frameworks.
Wicket	Wicket, out-of-the-box, provides everything teams need to create the typical stateful Web application that must track session state and perform services for the user. This Web framework is ideal for developers who prefer a very clean separation of concerns and object-oriented programming and need to get going fast. Developers can be productive in Wicket quickly. Teams that have UI members and programmers working independently of each other find Wicket exceptionally friendly. Since the HTML is all regular HTML, with no weird additional syntax, the UI designers can write the HTML / CSS and leave the implementation completely to the programmers. Although it sounds like the opposite of the previous point, Wicket is also great for one-man shops where one developer must program and write her own HTML. The developer can focus on object-oriented programming, and then add the basic HTML once she’s figured the implementation out. Projects that need or desire excellent mailing list support will find that the wicket-users mailing list first rate. If you just want to do object oriented programming and not worry about jumping through hoops to work with “the framework”, Wicket is for you. Once you understand a few basic concepts of how Wicket operates, you can start to figure out most of it on your own.
Shale*	The Shale Web framework offers an exceptional JUnit /JMock based testing framework that provides developers the possibility of testing their JSF-application. Other goodies include the view-controller which follows the common JSF-pattern of one ‘backing bean’ behind the page. For teams that need an XML-based alternative to JSP, Shale provides CLAY.
Rails	The sweet spot for Rails is any web application, especially ones that involve REST and/or AJAX. It should be strongly considered for stand-alone web sites.

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

What sorts of projects does this package not work as well for?

This is the full response. For a summary of the response, click here.

Project	Response
MyFaces	If developers need to create an application that requires static pages using HTML+ CSS + JavaScript, then JSF/MyFaces is not the best choice. It does not natively support AJAX functionality and developers will have to use one of the AJAX-enabled JSF components available in the community. JSF/MyFaces does not support REStful pages and the standard component set is probably not enough for implementing complex enterprise applications. Users say, JSF “is the EJB of web frameworks. Cool in theory. Hell in practice.”
JBoss SEAM	Although this project tries to address all the challenges of developing dynamic web projects, the stiff learning curve makes it a challenging set of tools for junior teams. Developers will need some knowledge of the JSF (it uses JSF as view) and some familiarity with the EJB 3.0 framework. Its dependence on libraries makes JBoss SEAM challenging to deploy. Suitable for very complex and transactional dynamic web projects, it should not be used in simple CRUD applications.
Spring MVC	A relatively new framework, Spring MVC is missing some of the features of more mature frameworks. If developers are building a project with an established, complex business model, it is somewhat arduous in Spring MVC to bind request parameters to a complex model. WebWork would be a better choice in this scenario because of its OGNL binding framework.
Stripes	Because Stripes requires Java 5, it will not work in any context where Java 5 is not available. Developers think this would be a great choice for brand new projects, not as good for those with existing code.
Struts 1*	Any projects that will be deployed to a 1.5 JVM should use Stripes instead. One of the biggest complaints about Struts 1.x is the amount of boilerplate code that needs to be written for simple tasks. For instance, there is configuration required in struts-config.xml, possibly a form class to be written, and action class, possibly a Tiles configuration, and the a JSP. None of these things can be changed without introducing backward-compatibility problems with earlier Struts releases and so Struts 1.x is not able to overcome these weaknesses. The lack of annotations can be mitigated with the use of tools such as XDoclet, and smart design can reduce the pain involved with adding new classes. However, the separation of form and action that many of the newer frameworks have avoided can only be handled, can’t be fixed. This means a Struts application will always have more classes than an equivalent application written in one of the other newer frameworks. Given all of this, Struts 1.x makes a poor choice for most projects commencing today, with one exception: if the team is already familiar with Struts 1.
Struts 2* (WebWork)	Not recommended for any but new projects.
Wicket	Nearly completely static or completely stateless sites should avoid Wicket. Wicket does perform well even for this sort of site, but it provides a lot of things that developers will not need in this situation. Wicket is a great choice for brand new projects, not as good for those with existing code.
Shale*	Requires JSF/MyFaces as it provides the runtime environment for Shale. Since Shale is “on-top-of-JSF”, the usage of Shale outside a JSF-application is pretty limited.
Rails	Rails does not particularly excel at projects that require lots of enterprise integration, such as performing a transaction across multiple databases or message queues. In these situations, Java-based Web application frameworks are probably the best choice. This may change in the future, however, as JRuby can already run Rails applications and also use Java’s high-end integration facilities.

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

Of the projects we’re comparing, which have you tried?

This is the full response. For a summary of the response, click here.

Project	Response
MyFaces	Seam: didn’t like Steep learning curve for the developer, including JSF + EJB 3.0. Its many libraries make it challenging to successfully deploy.
JBoss SEAM	No information available.
Spring MVC	Struts: liked A simple, mature web framework. Struts 1 is a bit heavy and tedious, but the newest version (Struts 2) blends the robustness of Struts with the benefits of WebWork and many lessons learned from the Rails framework. Webwork: liked A simple, mature, and lightweight framework. Configuration can be arduous. Development has merged with Struts and benefits from the experience and community of that project. Rails: liked Rails favors convention over configuration and goes a long way to making web application development simpler. However, it is still immature and lacks the breadth of features of Java web application frameworks.
Stripes	Spring: MVC: didn’t like Overly complex, too much configuration outside the code. Struts 1: didn’t like Hamstrung by the backward compatibility requirements. WebWork / Struts 2: didn’t like WebWork learned a lot from Struts 1, but still suffers from configuration pain.
Struts 1*	Spring MVC: didn’t like Overly complex, too much configuration outside the code. WebWork / Struts 2: didn’t like WebWork learned a lot from Struts 1, but still suffers from configuration pain. Stripes: liked Excellent framework, clean and simple, it simply keeps out of the way.
Struts 2* (WebWork)	Spring MVC: liked Respectable effort that no one should be ashamed of using. Stripes: liked Very compelling. Either would be a good choice for a project getting a fresh start. Wicket: liked Very compelling. Either would be a good choice for a project getting a fresh start. JSF: didn’t like is the EJB of web frameworks. Cool in theory. Hell in practice.
Wicket	Spring: liked I use it to configure my entire middle-tier, and it allows me to operate many similar sites by overriding pieces of configuration that may be different for that particular site. I’ve also used it for configuring custom back-office applications based on many components that I wrote, and wired together via Spring. Tapestry: didn’t like Worked with it for two years on an enterprise project at work. It had absolutely no transparency as to what was going on underneath the covers. It forced you to do things a certain way – the “HLS” way. Everyone involved with the project seemed religiously addicted to it, and only to doing it the “HLS” way, like he was a deity. It forced tons of configuration on you. Every release is a complete rewrite, and backwards-compatibility is constantly thrown out the window to suit the author’s current whims. The learning curve is extremely steep. I hear that version 4 is better, but I gave it up with version 3. Trails: didn’t like Didn’t try very hard. Couldn’t ever really get it to work well, although with more effort, that would’ve likely changed. Did not like Tapestry, so did not pursue further.
Shale*	Spring MVC: liked Cool, nice glue code, but there is a little overlap in Shale’s dialog and Spring Web-Flow (their JSF-version).
Rails	No information available.

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

What is the future of this project? What’s coming that will ease development?

This is the full response. For a summary of the response, click here.

Project	Response
MyFaces	The JSF 2.0 community is writing the new JSR 314. Interested parties can find it here: http://jcp.org/en/jsr/detail?id=314. This effort solves a number of the problems addressed in other questions. Some artifacts from Shale will probably make it into JSF 2.0. For instance, there are the Shale-Tiger extensions that allow the usage of annotations to register a managed bean.
JBoss SEAM	Developers are simplifying this project by separating the add-on parts. It is also related to the new JSR Web Beans. For more information, see http://jcp.org/en/jsr/detail?id=299.
Spring MVC	Spring MVC continues to benefit from the improvements made to the core Spring framework. Future improvements include easier configuration and better validation.
Stripes	There has been an expansion of the developer base recently to ensure that Stripes continues to be in a position to respond to the community’s requests. However, the community plans no major architectural changes. Users can adopt Stripes confident in the knowledge that the codebase has stabilized.
Struts 1*	Struts 1.x has a very limited future. Whilst officially new functionality is being added to the 1.x releases if backward compatibility can be maintained, in reality only very minor functionality improvements are being added. Having said this, bugfixes are still released. Thirdparty tools (eg XDoclet, IDE support) are mature and unlikely to offer any significant changes from the functionality offered today.
Struts 2* (WebWork)	No information available.
Wicket	The community plans to improve scalability, and provide better support for stateless applications. A full Java 1.5 version of Wicket is planned (current version works on 1.5, of course, but does not take advantage of 1.5 features so that 1.4 projects can still use it). Additionally, more tightly-integrated support for Spring and role-based authorization is in the works. Manning Early Access Program publishers released a Wicket-in-Action in July 2007.
Shale*	Some artifacts from Shale will probably make it into JSF 2.0. For instance, there are the Shale-Tiger extensions that allow the usage of annotations to register a managed bean.
Rails	Rails 2.0 is expected to be released by the end of 2007. It will make REST-based web application development even easier. It will also provide improvements in these areas: performance, security, formatting content for multiple clients (e.g., iPhone and Atom readers), testing, database schema migrations, XML handling, debugging, plug-in processing, and much more.

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

Are there myths about this project that you’d like to challenge?

This is the full response. For a summary of the response, click here.

Project	Response
MyFaces	No information available.
JBoss SEAM	Some developers think that JBoss SEAM is a J2EE standard, but it is not. It is developed on top of two important J2EE standards, namely, JSF and EJB 3.0.
Spring MVC	Spring MVC and Spring WebFlow are sometimes seen as competing projects. Spring WebFlow is actually complimentary in that it solves a particular problem with long web conversations.
Stripes	Stripes (like many other good frameworks) was started by one person, Tim Fennell, and concerns have been raised about it being a “one man band”. Earlier this year Tim stated that he wanted to open the framework up to more developers, his reasoning was so that Stripes could continue to grow. Stripes now has a very helpful and constructive user and development community.
Struts 1*	Developers think they need to use AJAX in their application and think that older frameworks like Struts have no support for AJAX. This is a myth, any framework can integrate with AJAX, see http://wiki.apache.org/struts/AjaxStruts for details on how AJAX interacts with a server side implementation based on Struts. It should be noted that existing applications written on Struts should not be ported to a newer framework purely in order to add AJAX using some AJAX support from another framework. Developers also think that they will be required to use JSPs. Struts, like all popular frameworks, uses JSP as the default templating engine. It is possible to use Struts tags with both Freemarker ( http://cwiki.apache.org/WW/freemarker-tags.html) and Velocity ( http://cwiki.apache.org/WW/velocity-tags.html).
Struts 2 (WebWork)	No information available.
Wicket	All of the URLs are ugly. This is easily configured. Developers can literally do whatever they want with the URLs to fit the project’s needs. That this framework is an infant version of Tapestry. Wicket supports so many things out-of-the-box, and is a very mature framework in that “it just works” and has few bugs. It has excellent AJAX support, again, out-of-the-box.
Shale*	Developers think that Shale is a JSF implementation, but it’s not. It is a lightweight framework on-top of JSF.
Rails	Some people think that Rails is all about code generation. Although code generation in Rails, called “scaffolding”, is convenient, that’s really just a tiny fraction of a very robust package. Code generation gets you started quickly and lets new Rails users learn how the basics work, but in most cases the generated code will be replaced by hand-written code one method at a time. This makes sure your application is always ready to run and test while you’re implementing it.

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

Struts, Shale and WebWork

In the early 2000’s, WebWork broke off from Apache Struts 1. In 2006, WebWork 2.2 was pulled back in to the Apache Struts project and became Struts 2. Shortly thereafter, development on WebWork ceased. All releases after after 2.2 consist of patches. Active development is taking place on the Struts 2 code base.

Shale also began life as an Apache Struts subproject. Based on the JSF standard (which did not exist when Struts 1 development commenced in 2000), the Shale project broke off on its own in late 2006.

A word about the relationship between Struts, WebWork and Shale in the OLEX Library. Although the entries in this table are organized into Struts 1 and Struts 2/Webwork, downloadable code in the OLEX library is organized differently. Under the Struts project, you will find Struts versions 1.0.2 through 2.0.9, and under the Webwork project you will find versions 2.1.7 through 2.2.4. OpenLogic policy is to offer all of a project’s versions – regardless of the significance of the changes – together. Project developers, when asked to answer our ‘Sweet Spot’ questions, found it more natural to talk about in terms of Struts 1 and WebWork/Struts 2 given that the code bases are so closely related.

For access to Struts 1 and Struts 2 code lines in the OLEX library, search for Struts. WebWork code is kept under the WebWork project.

Acknowledgments

Project	Contributer
JSF/MyFaces	Gurkan Erdogdu
JBoss SEAM	Gurkan Erdogdu
Spring MVC	Andres March
Stripes	Dmitri Colebatch
Struts 1	Dmitri Colebatch
Struts 2 (Webwork)	James House
Wicket	Jeremy Thompson
Shale	Mathias Wessendorf
Rails	Internal Expertise

Open Source Application Server Comparison Matrix

Kimberly McClintock — Mon, 29 Sep 2008 19:46:42 +0000

Use this comparison matrix to learn about the differences between and relative benefits of the popular open source application servers JBoss, Tomcat, Glassfish, and Jetty.

From the generally thin-featured offerings and questions of security of the early 2000’s, the Application Server category of open source project has matured to compete squarely with their commercial counterparts. Sometimes the terms ‘Application Server’ and ‘Web Application Framework’ are used interchangeably; we’ve distinguished between them for our research. By Application Server here we mean ’servers of Web based applications’. You’ll want to look to the Web Frameworks SweetSpot for more information on the web application frameworks developed by the open source community.

The following tables represent research completed in the fall of 2007 by OpenLogic. We went to the experts — members of the OpenLogic Expert Community who are committers and expert users of the projects — and asked them to answer a set of questions. Members of Tomcat, JBoss, Jetty and GlassFish responded. Use the resulting information as a tool to plan your projects.

For comprehensive information on each project compared, locate it in the OpenLogic Enterprise Exchange library by accessing the ‘Browse Open Source’ tab.

The five questions we asked the experts appear below. To view more detail on the projects* compared across each question, click the question.

What’s the ’sweet spot’ of your project? For what type of projects should users strongly consider it?
What type of scenarios does your project not fit into as well? Would you recommend another project in this scenario? If so, which one?
Of the projects included here, which have you tried? Of those, which ones did you like or dislike, and why?
What is the future of this project? What’s coming that will ease development?
Are there myths about this project that you’d like to challenge?

For comprehensive information on each project, search the OLEX Open Source Library. For a list of the open source developers we interviewed, click here.

*While no version of the projects is specified, you can assume that the information relates to the latest version in our library at the time of the last update.

Summarized Responses

What’s your project’s ’sweet spot’?

This is a summary of the responses. For full detail, click here.

Project	Summarized Response
GlassFish	Web services Enterprise level support for clustering Enterprise level administration console (CLI, Web based GUI and JMX) Installation profiles Tight integration with a wide variety of software packages
Tomcat	Extremely configurable and pluggable design Popularity results in large user base
JBoss	Ease of use Development environments
Jetty	Small size

Return to the questions list.

What sorts of projects does this package not work as well for?

This is a summary of the responses. For full detail, click here.

Project	Summarized Response
GlassFish	Any scenario requiring a full Java EE application server or Servlet container is good for GlassFish GlassFish does not fit in a scenario requiring a container embedded
Tomcat	Tomcat does not fit well into fullblown J2EE applications
JBoss	Will fit in any scenario
Jetty	Scenarios requiring J2EE support beyond servlets should be avoided Scenarios requiring business logic to housed in a separate EJB tier

Return to the questions list.

Of the projects we’re comparing, which have you tried?

This is a summary of the responses. For full detail, click here.

Project	Summarized Response
GlassFish	Tomcat: liked Tomcat is an optimized Servlet container with clustering capability and a very good http/https module implemented using non blocking NIO package. Tomcat is suitable if project is not going to host EJBs. Geronimo:liked Geronimo has all features that GlassFish has except that it does not provide any of those five features mentioned in question one. Although Geronimo has an administration interface, Web service support and very small level of clustering support (using Terracotta), it is far behind what GlassFish provides out of the box. Geronimo fits best in scenarios where there is no need for clustering and cluster management.
Tomcat	CauchoResin: didn’t like Commercial. Poor documentation. Jetty: liked Small and efficient, but has a smaller user base than some of the alternatives. GlassFish: disliked Worst configuration files ever Hard to work with. Geronimo: liked Wraps Tomcat inside a J2EE server. JBoss: liked Same as Geronimo Though I dislike the tyrant community of JBoss.
JBoss	Tomcat: liked Easy to install, although can be tricky to configure in some aspects. Jetty: liked A great option if what you need is a simple web container. It can be embedded (which makes deployment of the project as a whole easier). Very fast startup (useful during development). GlassFish: didn’t like Hard to use, and very slow to start (especially when integrated with NetBeans).
Jetty	Tomcat: liked Excellent community support. Solid Web server In my experience, the development community can be somewhat unhelpful and unfriendly. However, I have seen many many excellent examples of community support in Tomcat, both from users and developers. In particular, I have always found people such as Filip Hanik to be extremely helpful. JBoss: liked Strong community.

Return to the questions list.

What is the future of this project? What’s coming that will ease development?

This is a summary of the responses. For full detail, click here.

Project	Summarized Response
GlassFish	Support for AIX Faster startup High availability (JMS high availability, in particular) using HADB Enhancements to auto update feature
Tomcat	Faster and more stable
JBoss	No information available.
Jetty	Continuations and Async SSL

Return to the questions list.

Myths

This is a summary of the responses. For full detail, click here.

Project	Summarized Response
GlassFish	Poor performance.
Tomcat	Tomcat is great for development, but should not be used from production.
JBoss	Lack of support, and an inability to handle mission-critical projects. Neither of these are true.
Jetty	Jetty can only be run as part of JBoss or Geronimo.

Return to the questions list.

Complete Responses

What’s your project’s ’sweet spot’?

This is the full response. For a summary of the response, click here.

Project	Full Response
GlassFish	Web services: It has a well designed and implemented Web service stack which supports the latest WS-* standards like Reliable Messaging, Secure Conversation, Trust, Security, SecurityPolicy, MetadataExchange, Atomic Transaction, Coordination, etc. The GlassFish Web services stack is fully Interoperable with the .Net framework, and has been adopted by some other big players like IBM for its JDK version 6, BEA as Web service stack for BEA application server 10, JBoss WS 2.1.0, etc. Enterprise level support for clustering: GlassFish has a very well designed and implemented clustering and high availability mechanism which distinguishes it as an open source application server. GlassFish supports in-memory replication for http sessions, stateful EJB session states, single sign on states, and container states (Timer…). Although the default replication mechanism between instances is based on JXTA (in-memory replication), it is possible to use HADB (a high performance database optimized for high availability use cases)to achieve 99.99% uptime. Enterprise level administration console (CLI, Web based GUI and JMX): The GlassFish administration console allows full control over application server configuration and behavior from detailed configuration of an ORB listener to monitoring and diagnosis. Web based console can be used to manage and configure a cluster and deploy application or resource to entire cluster. Per-Web service, JDBC resource, web resource, etc monitoring provide detailed statistics about that resource usage. Installation profiles: GlassFish can be installed using one of several profiles: Developer, Cluster or Enterprise. Each profile has special features that make it suitable for a specific purpose.For example, the Developer profile will not carry modules that are required for clustered environments and this allows for faster database stops and starts. The Developer profile also uses an embedded broker to serve JMS requirements. It uses the JKS format rather than the CertDB used by the Enterprise profile. These and other differences between the profiles let each role in an enterprise to have an installation suited for its purpose. GlassFish is tightly integrated with a wide range of software, including: OpenESB – a first class JBI implementation with tens of binding components and service engines. OpenSSO – an open source version of Sun Java Access Manager. OpenDS – an open source version of the Sun Directory Server.
Tomcat	Tomcat’s sweet spot is it’s extremely configurable and pluggable design. This means that every component inside of Tomcat can be exchanged with one you or someone else has developed without changing Tomcat code. This is all managed via the configuration file. This ease of use has contributed to making Tomcat the most popular servlet engine today. This popularity results in a very large user base and access to lots of expertise. Additionally, and it’s easy to find developers with the Tomcat skill set.
JBoss	The biggest advantage of JBoss is ease of use. Installation is as simple as unzipping a file; deploying the application is as simple as copying a WAR/EAR. Support for expanded deployments makes development more productive. JBoss should be considered for any Java EE project. Even if the project officially uses another application server, developers could use JBoss during development to increase productivity.
Jetty	Whilst Jetty is an excellent servlet engine on any measure, it is extremely lightweight and so easy to embed into another application. We have a number of applications that require embedded HTTP servers in which we have used Jetty very successfully. The entire Jetty codebase is only a few hundred KB, and as such it is ideal for environments where memory is a premium. For example, many devices such as routers and modems have Web interfaces for managing the device. Jetty would be an ideal fit for this sort of deployment due to its compact footprint.

Return to the questions list.

What sorts of projects does this package not work as well for?

This is the full response. For a summary of the response, click here.

Project	Full Response
GlassFish	Generally speaking, GlassFish fits any type of scenario requiring a full Java EE application server or Servlet container. In older versions of GlassFish (Sun Java application servers), it was not suitable to replace a Servlet container like Tomcat or Jetty but the new Grizzly engine used in GlassFish allows it to operate as well as Tomcat and Jetty in place of a Servlet container. In addition, it has a very easy and reliable cluster management and failover recovery which make it a wise choice. The one scenario that current versions of GlassFish does not fit is any embedded use case where a container should be embedding in-process. For this scenario Tomcat fits well.
Tomcat	Any that is no java, of course. And, fullblown J2EE applications, for this you can use JBoss, Geronimo or Glassfish, all of which run a version of Tomcat inside.
JBoss	Technically speaking, I don’t know any scenario into which JBoss would not fit (that doesn’t mean such a scenario doesn’t exist, I’m just not familiar with any).
Jetty	If J2EE support beyond servlets is required, something like JBoss or Geronimo would be a better choice. It should be noted that technically speaking, neither of those are Servlet containers but instead include a Servlet container (typically Tomcat or Jetty) that is used to handle HTTP requests. Given that Jetty is only a servlet container, it does not support EJBs and other J2EE components except servlets. Some applications may require that business logic be housed in a separate EJB tier which Jetty does not support. In these cases something like JBoss or Geronimo would be a better choice. Note that even in this case Jetty would still be an excellent choice for the HTTP/Servlet component of the application. I do not believe there are any projects where Jetty would not be an excellent fit for the HTTP/Servlet layer if Java is a requirement.

Return to the questions list.

Of the projects included here, which have you tried? Of those, which ones did you like or dislike, and why?

This is the full response. For a summary of the response, click here.

Project	Full Response
GlassFish	Tomcat: liked Tomcat is an optimized Servlet container with clustering capability and a very good http/https module implemented using non blocking NIO package. Tomcat is suitable if project is not going to host EJBs. Geronimo:liked Geronimo has all features that GlassFish has except that it does not provide any of those five features mentioned in question one. Although Geronimo has an administration interface, Web service support and very small level of clustering support (using Terracotta), it is far behind what GlassFish provides out of the box. Geronimo fits best in scenarios where there is no need for clustering and cluster management.
Tomcat	CauchoResin: didn’t like Commercial. Poor documentation. Jetty: liked Small and efficient, but has a smaller user base than some of the alternatives. GlassFish: disliked Worst configuration files ever Hard to work with. Geronimo: liked Wraps Tomcat inside a J2EE server. JBoss: liked Same as Geronimo Though I dislike the tyrant community of JBoss.
JBoss	Tomcat: liked Easy to install, although can be tricky to configure in some aspects. Jetty: liked A great option if what you need is a simple web container. It can be embedded (which makes deployment of the project as a whole easier). Very fast startup (useful during development). GlassFish: didn’t like Hard to use, and very slow to start (especially when integrated with NetBeans).
Jetty	Tomcat: liked Excellent community support. Solid Web server In my experience, the development community can be somewhat unhelpful and unfriendly (see http://issues.apache.org/bugzilla/show_bug.cgi?id=37424 for an example). However, I have seen many many excellent examples of community support in Tomcat, both from users and developers. In particular, I have always found people such as Filip Hanik to be extremely helpful. JBoss: liked Strong community.

Return to the questions list.

What is the future of this project? What’s coming that will ease
development?

This is the full response. For a summary of the response, click here.

Project	Full Response
GlassFish	The GlassFish kernel is slated for redesign in version 3. The new kernel is based on an HK2 module sub-system which makes it possible to start GlassFish in a cell phone or embed it in-process. Other enhancements include some to performance: GlassFish will start within few seconds (less than 5) using a lazy loading mechanism for its module and sub systems. There will be an upgrade for GlassFish in early 2008 which make it possible to use GlassFish on AIX operating system. GlassFish version 3 will support Java EE 6 profiles in addition to support for scripting languages like JRuby, PHP, JavaScript (server side). Support for these languages will be available through containers which are already implemented to some degree. The next version will include improvements for high availability (JMS high availability, in particular) using HADB. GlassFish has an auto update mechanism that allows administrators to create an update center with new or updated application server artifacts and update all server instance from that update center. This feature allows the update of application servers or install of new modules on the server. In next version of GlassFish, it will be possible to update deployed applications using this update center.
Tomcat	Continue along the same path, it is now a commodity software, no revolutions inline but to make it better, more stable and faster. JSR-315 is next on the list, which is servlet 3.0.
JBoss	No information available.
Jetty	Jetty is still under active development and a number of new features are being added to fulfill today’s requirements of a servlet container, including Continuations and Async SSL.

Return to the questions list.

Are there myths about this project that you’d like to challenge?

This is the full response. For a summary of the response, click here.

Project	Full Response
GlassFish	The most insidious myths about GlassFish were allayed by SUN’s release of the SpecJ benchmark reports. SpecJ reports debunking myths about GlassFish performance are worth looking at – here and here.
Tomcat	There is one myth, and it was around for a long time: Tomcat is great for development, but should not be used from production. While this may persist in some companies, many have realized the cost benefit of Tomcat, and its maturity.
JBoss	Lack of support, and an inability to handle mission-critical projects. Neither of these are true.
Jetty	One is that Jetty can only be run as part of JBoss or Geronimo. This is not true, the only reason Jetty would need to run as part of JBoss or Geronimo is if EJB support is required. Jetty doesn’t have support for JNDI or LDAP integration. This is not true, JettyPlus (http://jetty.mortbay.org/jetty5/plus/index.html) has support for JTA, JNDI, JAAS and Javamail.

Return to the questions list.

Acknowledgments

OpenLogic would like to thank the following members of the OpenLogic Expert Community for their contributions to this effort and invite the community to email us if they’d like to augment, correct, update, refute or dispute any of the information included herein.

Project	Contributer
Glassfish	Masoud Kalalil
JBoss	Felipe Leme
Jetty	Dmitri Colebatch
Tomcat	Filip Hanik

The Touchier Points of Determining the License of an Open Source Project

Kimberly McClintock — Thu, 04 Sep 2008 16:47:32 +0000

Figuring out the licensing terms of the open source gadget you’d like to use in the widget you’re prototyping (and hope to offer for sale next quarter) is not as difficult as, say, absorbing the details of evolutionary biology, but neither is it a guaranteed walk in the park. In other words, it’s not dreadfully difficult, but often it’s not as easy as you might hope, either. As walks go, it’s closer to the legerdemain accomplished by a professional dog walker (picture all that threading and unthreading as the dogs fan out and weave grass patch to tree trunk). At its worst, it’s maybe just a bit more complex.

OpenLogic’s researchers work diligently to confirm the accuracy of licenses for the open source projects included in the OpenLogic Certified Library. They follow a process carefully crafted from many years experience, refined and sauced liberally with intuition, creativity and not-a-little tenacious detective work. As they’d be the first to tell you, this work is not for weenies and is best left to the professionals. However, if you insist on trying your hand, there are a few tricks they’re willing to share.

Where to look

About half the time, getting an initial sense of the licensing of an open source project is as simple as navigating to the project’s home page, and taking a gander at the menu options scrolled variously down the left or across the top. Much of the time, if ‘License’ is one of them, you can follow the link and, voila: license text.

Even this simplest case, though, is not always as simple as it seems. Our legal department issued the edict that ‘distribution is King’ which means that, regardless of what the Web site claims, the license found in the distribution is the license the project is released under. To be certain you’re using the correct license, you always want to locate and download the distribution to determine a match. Later in this article, we talk about typical filenames given to license files, and where in the distribution they’re most often found.

Projects that use a hosting site such as SourceForge will have a summary page that lists basic project information. This information typically includes the license. AcegiSecurity, for instance. Their Web site (www.acegisecurity.org) does not appear to include a link to the license information. But, notice in the upper right hand corner the link to Acegi on SourceForge:

A couple more clicks, and you’ve arrived at Acegi’s summary page which reports the license as Apache 2.0. In this case, this information is correct, however, sometimes the SourceForge information is out-of-date. If the project you’re researching will be modified and included in work for sale, you should confirm the license by checking the distribution.

If none of these paths result in license information, check the project documentation for a FAQ, for instance, the Mozilla License FAQ. If there is one, it will often have an intuitively titled entry covering license terms. If there’s no FAQ, search for ‘license’ first on the home page, and then by using the site’s search function if there is one. If none of this turns up information, follow with a general Google search (project name + version + ‘license’) and often the appropriate page on the project site will appear in the results.

Why you shouldn’t stop there

We mentioned quickly the possibility of downloading the distribution and confirming the licensing of a project by exploring it. You might think that, given all of this, downloading the distribution first would be the most reasonable approach. This is risky for a couple of reasons. In many instances the Web site and the distribution will conflict for one reason or another. While legal says the ‘distro is king’, there are situations in which a conflict between the two licenses could cause problems. If, for example, the distribution contained a permissive license like Apache 2.0, but the Web site included text that indicated commercial use of their work required the Gnu Public License (GPL) and they hadn’t included a FLOSS Exception like MySQL.

Additionally, some enterprises restrict the download of distributions based on licenses like the Gnu Public License (GPL). As an engineer or manager researching the licensing issues around using a certain project, you’ve got a textbook chicken/egg situation: in order to be certain on the license, you need a peek at the distro, in order to get access to the distro, you need to know if the license is safe.

What you’ll find

If you’re a developer of more than a little experience, you won’t be surprised at the range of organizational strategies at work inside the distributions. The rest of us have experienced symptoms such as cold sweats and dizziness and, in one instance, actually fainting dead away when faced with Yet Another variation on the theme. You can pad the room and go on alone, or you can make use of some of these set ups our researchers have seen.

Sometimes you’ll find the license information at the top level and sometimes you’ll have to dig. Some of the locations we have found license files:

Licenses directory
Copying directory
Legal directory
Docs directory
Lib directory
Project-name directory
License-name directory

Some of the file names that may contain license information:

License.txt
Copying.txt
Legal.txt
Readme.txt
Copyright.txt
Notices.txt
Specific License Name.txt

What you should do with what you find & how

So, say the Web site and the distribution of the project you’re interested in using both claim that the project uses Apache Software License version 1.1? Now you’ll need to eyeball the text and make sure that, in fact, they are the same license. It is not uncommon for projects to modify standard licenses to include custom text. Here, again, the Web site version and the distro version might differ. More likely, though, the Web site and distro will match, but the license will deviate from the standard version of the license. For examples of the standards, see the Open Source Initiative site and the Free Software Foundation.

For short and relatively uncomplicated licenses such as BSD and MIT, an eyeballing to make sure that the licenses match the standard is probably good enough. But, for more complex licenses like the MPL, you’ll want to use a ‘diff tool’ like KDiff to compare the text a project uses against the standard.

Other tools OpenLogic researchers leverage include Fossology and OhCount.

Other tidbits

You’ll also want to make sure to read carefully any text on the license page of the project Web site that specifies the versions of the project to which a particular license or license version applies.

And, finally

OpenLogic researchers perform all of this analysis, and more, on every version of every project in the Certified Library. We’re happy to do the heavy lifting on research, but if you’ve got access to a legal team, you should run what we’ve found by them, too. We rely heavily on our legal team to interpret anything remotely questionable. Look for ‘Special Notes’ on any package that qualifies as such.