How To Migrate JEE Applications to Apache Tomcat

posted by avanabs on July 7, 2010 05:42 AM

I’ve been sharing some thoughts about what’s become a significant trend in many IT organizations, and in particular with my clients…converting Java applications from JEE Application Servers to Tomcat, and more typically Tomcat+add-ons.

Many IT organizations are re-thinking their commitment to commercial JEE Application Servers, due to both challenging business environments that drive the need for more cost effective application architectures and the need to transition to more responsive/agile applications development. When IT organizations talk about “migrating” their applications, I’ve noted that they generally are focusing on one or more of three distinct situations. These are:

  • Moving existing applications (or slices of applications) off of JEE servers and onto lightweight, modular, horizontally scalable container infrastructures
  • Expanding access to existing JEE applications by adding services layers in lightweight containers.
  • Transitioning new development away from JEE application servers and focusing on light weight containers

I’ve been focusing on the migration of existing JEE applications to the most popular of the light weight containers, Tomcat. There are many excellent reasons to consider moving applications off of the commercial JEE servers sold by Oracle/BEA, IBM, etc. While we are focusing on the migration process, many of the business and technical decision factors apply equally well to the second and third situations.

This time, I will be discussing the technologies involved in migrating JEE application code from commercial JEE servers to Tomcat. I’d like to thank the kind (and very expert) folks at SpringSource, as well as a number of other friends around the industry, for their valuable insight regarding the technologies involved. Any errors (and opinions) are mine alone. Additionally, some of the material draws on information published by SpringSource and other open source materials found on the internet.

Java EE API Support

The Java EE specification is quite complex and it also includes a significant number of Java Optional Packages. For each package, the specification defines the version for environments that support a full-stack Java EE 5.0 environment…IE JEE Application Servers.

Note: I assert that Tomcat IS an application server, although it IS NOT a “JEE Application Server”. This is both a strength (by design, it leaves out tons of stuff we rarely use anyway and the needless cost/weight/complexity) and a weakness (it lacks some frequently used services and most administrative capabilities). That said, I’d much rather start with a rock solid, performant, base and then add what I need, rather than dealing with the cost/weight/cpomplexity of the JEE Application Servers..

A Tomcat environment provides access to most of these APIs as a standard capability, by enabling you to “drop in” standard implementation JARs to the Tomcat lib directory, or by bundling the standard implementation JARs with the deployed applications. In some cases, excellent commercial alternatives also exist. In my clients experience, a very large portion (80%+) of their applications require only Tomcat and a fairly small number of add-on’s/drop-in’s.

It is a definite advantage of the Tomcat environment that many of these JEE packages are not embedded out-of-the-box. This is because, as previously noted, most applications only utilize a small portion of the JEE standard and even less of the WLS/WAS proprietary functionality. You can add needed services to the environment fairly easily, in “drop-in” fashion, which means you run the latest version of the specifications and you significantly reduce server bloat (from nearly a GB to tens of MB) by bringing in only needed services and capabilities. Additionally, you can choose among multiple providers, and server operators and application deployers can decide whether to add a package as a standard server feature (by dropping it into the server lib directory), or to embed it in each application.

The following table summarizes the availability of the Java Optional Packages defined by Java EE 5.0 in the Tomcat environment. These are in the same order as Table EE.6-1 in the Java EE 5.0 specification document.

Java EE API Support


EJB 2.1 and 3.0

Client access only.

No support for running EJBs themselves.

Servlet 2.5


Java Server Pages (JSP) 2.1


JavaMail 1.4

Drop in standard JAR to Tomcat lib directory or embed in applications.

JMS 1.1

Client: Drop in standard JAR.

Server: No embedded implementation.

Multiple third-party (open-source or commercial) products available to run alongside or embedded.

JTA 1.1

No embedded implementation.

Plug-in external JTA provider if needed.

JAF 1.1

Drop in standard JAR to Tomcat lib directory or embed in applications.

Connector 1.5

Not supported.

Web Services 1.2

Drop in standard or third-party JAR.

Multiple open-source and commercial implementations available.

Add JARs to Tomcat lib directory or embed in applications.


Drop in standard or third-party JAR.

Multiple open-source and commercial implementations available.

Add JARs to Tomcat lib directory or embed in applications.

JAX-WS 2.0

Drop in standard or third-party JAR.

Multiple open-source and commercial implementations available.

Add JARs to Tomcat lib directory or embed in applications.

JAXB 2.0

Drop in standard JAR.

Add standard JAR to Tomcat lib directory or embed in applications.

SAAJ 1.3

Drop in standard JAR to Tomcat lib directory or embed in applications.

JAXR 1.0

Drop in standard JAR to Tomcat lib directory or embed in applications.

Java EE Management 1.1

Not supported.

Java EE Deployment 1.2

Not supported.

JACC 1.1

Not supported.

JSP Debugging 1.0


JSTL 1.2


Web Services Metadata 2.0

Drop in standard JAR to Tomcat lib directory or embed in applications.

JSF 1.2

Drop in standard or third-party JAR.

Multiple open-source and commercial implementations available.

Add JARs to Tomcat lib directory or embed in applications.

Common Annotations 1.0


Supported in Servlets per specification.

StAX 1.0

Drop in standard or third-party JAR.

Multiple open-source and commercial implementations available.

Add JARs to Tomcat lib directory or embed in applications.

Java Persistence 1.0

Standard or third-party drop-in, including updated 2.0 spec.

Multiple open-source and commercial implementations available.

Add JARs to Tomcat lib directory or embed in applications


Code Migration Strategies

In the sections that follow, I’ll take a look at various aspects of the code migration process, including layers, transactions, EJBs, remoting, data sources, security, messaging, and management.

Layering and Interfaces

A properly layered, interface-driven, and decoupled architecture that uses inversion of control and dependency injection patterns offers tangible benefits:

  • Reduced code coupling
  • Reduced complexity
  • Easier and enhanced testing
  • Increased agility

These benefits dramatically facilitate code refactoring, although care should also be taken to avoid un-necessary “creeping elegance”. It’s all too easy to get tangled up in what can amount to a complete re-write, while the objective (and budget) may be much more modest.

An existing architecture that is not adequately layered and interface-based requires additional refactoring to make it so. So, consider whether this additional refactoring, above and beyond what is immediately needed for the migration effort, will pay off in future ongoing maintenance and enhancement of the application.

Migrating Significant Code-Level Changes Piece-by-Piece

If you need to migrate code-level changes, consider refactoring and migrating piece-by- piece instead of in a “big bang” process, as this is generally less disruptive and more manageable. You can work in multiple iterations, possibly with working code between iterations, until all refactoring is completed.

Where migration involves refactoring away from technology that is not available in Tomcat, with the goal of working code at the end of each iteration, the migration effort should remain in the JEE Application Server until those technologies are completely refactored. For example, consider an existing application that implements business services as session EJBs, currently running in a full-stack Java EE environment, that are being refactored to execute in a Tomcat environment. Migration in pieces allows only a subset of the EJBs to be refactored in each iteration (to POJO implementations of those services, for example…or to an appropriate framework). Of course, if the goal is to test working code between each iteration (a VERY good practice, and particularly suited to agile development environments), this implies staying in the JEE Application Server until all the EJB’s are refactored.

Migration in pieces usually requires one of two strategies: migration by vertical slice, or migration by layer. In the migration by vertical slice approach, a complete “vertical slice” encompassing multiple layers (services, data access, domain, and so on) often representing a logical application component, is migrated in one iteration. Over multiple iterations, code gradually moves from legacy vertical slices to migrated vertical slices. In the migration by layer approach, code is migrated a layer (for example, certain application serevices) at a time. The decision to use a migration by vertical slice or migration by layer approach is application-specific and depends on existing architecture and existing code coupling. It also depends strongly on team preference and standard prqactices. In both cases, the idea is to perform refactoring in manageable chunks.

Service Layer Migration Strategy

Many larger JEE applications have a distinct set of functionality that implements a service or application layer. This code implements use cases, or functionality, specific to the particular application. In best-practice fashion, this layer typically is hidden behind use case-specific interfaces, and it often interacts with a data access layer (by interface), and with domain objects or data transfer objects. In those applications that do use EJBs, it is fairly typical for the service layer to be implemented as EJBs. Additionally, both transactions and method level security are usually implemented in the service layer.

Where a more than minimal refactoring effort is required in the service layer anyway, consider whether to expense potentially additional effort towards effecting a properly layered and interface based codebase. This effort may pay off in the migration effort itself and/or in subsequent maintenance costs.

Data Access Layer and Data Access Objects

Many larger Java applications have a distinct set of functionality that implements a data-access layer, to the extent that this code is responsible for persisting data transfer objects or domain objects to one or more datastores. Typically, code in this layer is hidden behind a set of interfaces that abstract the exact persistence technology in use.

However, in practice, it is not practical to try to abstract away the use of lower level persistence technology such as JDBC, as opposed to higher level technology such as object-relational mapping (ORM). Code in this layer is also often referred to as data-access objects (DAOs). Where data access functionality is implemented through entity EJBs, it is necessary to migrate this code.

Migrating Web and Presentation Layer Code

Migration from JEE Application Servers to Tomcat does not normally entail significant refactoring of web tier or presentation layer code, because Tomcat was the reference implementation for this portion of the JEE standard and/or is the actual implementation within some JEE Applications ervers. In many cases, web tier code can remain almost untouched.

Areas that may require refactoring are related to EJB access and to remoting. Where web tier code is a client of EJB services, and is directly performing EJB stub lookup, a straightforward conversion process to the use of plain Java services may be required. Where code is using EJB remoting, and continued use of remoting is actually necessary, refactoring to an alternate remoting technology is necessary.

Migrating Transactional Code

Before migrating existing transactional code to a Tomcat environment, it is important to understand the options available in a Tomcat environment for demarcating and driving transactions in application code.

  • Local resource transaction APIs: Transactions are driven through the appropriate local resource transaction APIs on local resources such as the JDBC Connection object, JPA's EntityManager, Hibernate's Session, or equivalent.
  • JTA (Java Transaction API): Tomcat out-of-the box does not include a transaction manager implementation that supports JTA APIs. However, you can plug in a third-party external JTA transaction manager (such as Atomikos) to the Tomcat environment to support JTA APIs. Because a third-party JTA transaction manager is an additional component that must be obtained, supported, and possibly licensed, examine the desirability of this approach against the alternative of refactoring code away from the use of JTA.

Although application-specific code may drive transactions toward using these APIs, it is also common for application code to utilize a third-party abstraction layer, which itself talks to these APIs. As an example, the Spring Framework offers transaction functionality, which allows both a declarative and programmatic approach to transaction demarcation, and which abstracts the distinction between JTA and local resource transactions.

JTA: Non-EJB and EJB Bean-Managed Transactions

Tomcat, out-of-the-box, does not include a transaction manager implementation that supports the JTA APIs. You can choose among several approaches to migrating application code that uses JTA, whether through POJO services or EJBs using bean-managed transactions:

  • The most direct migration approach, often requiring no code level refactoring, is to plug in an external JTA transaction manager (such as Atomikos). Because a third-party JTA transaction manager is an additional component that must be obtained, supported, and possibly licensed, examine the desirability of this approach against the alternative of refactoring code away from the use of JTA.
  • Eliminate JTA API usage by refactoring code to use corresponding local resource transaction APIs. This would include, for example, direct driving of transactions through the JDBC Connection object, JPA's EntityManager, Hibernate's Session, or equivalent. Application code that uses local resource APIs should essentially run as-is in a Tomcat environment.
  • Refactor to use the Spring Framework transaction management functionality and abstractions. With this approach, code is decoupled from the exact transaction management strategy, and works equally well with JTA and local DataSource transactions. It also provides integration with lower- level, data-access support infrastructure. Many large IT organizations using JEE Application Servers have already standardized on Spring, making the code both much more portable and more maintainable.
  • When moving code that drives transactions programmatically, refactor according to Spring's programmatic TransactionTemplate.
  • Alternatively, consider refactoring to the use of Spring's declarative transaction support. In this variant, transactions are demarcated via external (to the code) XML-based declarations, or internal annotations right in the source. While moving to this declarative approach will require additional work, transaction handling boilerplate will be removed from application code, with the general net benefits of significantly simplifying and clarifying application logic, reducing the amount of code that must be maintained, and reducing the chance of bugs.

Session EJB Migration Strategy

EJB 2.x session beans are not available in a Tomcat environment. A migration to Tomcat entails refactoring any application logic currently implemented as session beans. EJB 2.x session beans are generally considered dead-end, legacy technology (if indeed they were ever a good idea), which is another factor that drives refactoring of this code.

The general approach to refactoring session beans is to re-implement the logic as POJO services. General concerns stem from handling transactions for the session beans, and to a lesser degree, the handling of security.

Session Beans with Container-Managed Transactions (CMT)

CMT implies that transactions are applied to EJB code through a declarative process, where the EJB deployment descriptors are annotated to indicate that the container should make certain methods transactional when invoked. The use of CMT must be refactored by one of several approaches:

  • You can implement transactions programmatically (similar to bean- managed transactions), where application code explicitly drives transactions. Spring's programmatic TransactionTemplate is a good choice, as you can decouple application code from the specific JTA or local DataSource transaction APIs. Additionally, Spring provides integration with lower-level data access support functionality. Otherwise, application level code may drive transactions by using the specific transaction API available. This includes JTA where an external JTA transaction manager has been plugged into the Tomcat environment, or a local resource transaction API that drives transactions directly through the JDBC Connection object, JPA's EntityManager, Hibernate's Session, or equivalent.
  • Alternatively, where Spring Framework is an available option, the preferred approach is to refactor to use Spring's declarative transaction functionality, as there is essentially a one-to-one mapping to the semantics of applying transaction demarcation. Spring's transaction support is a complete functional superset of that available in an EJB container. It can drive transactions through both JTA and local resource APIs, and contains additional integration with Spring's data access support code. Spring supports declarative demarcation of transactions through either external (to the code) XML-based declarations, or internal annotations right in the source.

Session Beans with Bean Managed Transactions (BMT)

See JTA: Non-EJB and EJB Bean-Managed Transactions, as the same general approach applies to migrating BMT code to Tomcat as POJO code, whether using JTA or local resource APIs.

Session Beans with Container-Managed Security

I’ve rarely found a client who used container managed security, due to it’s inherent limitations. You can annotate EJBs in a declarative fashion in their XML descriptors to indicate that the container should apply simple (simplistic?) role-based security to certain EJB methods. You need to refactor container-managed security by one of these approaches:

  • The most direct approach is to refactor to the use of declarative security through Spring Security. Spring Security, an extensible security framework, generally offers a complete superset of capabilities offered by EJB container-managed security, while also offering a large number of other capabilities, and being extensible in a container-agnostic fashion.
  • Alternatively, you can replace container-managed security with custom application-specific code created during refactoring, or by the use of another security framework.
  • Alternatively, you can use any of the third party application security products that offer API interfaces, for example CA’s SiteMinder or Tivoli Access Manager. Many IT organizations already utilize such security systems because they integrate application security with organization identity management.

Message-Driven EJB Migration Strategy

EJB message-driven beans (MDBs) are also not available as a technology choice in a Tomcat environment. A migration to Tomcat entails some refactoring away from MDBs. However, because code inside MDBs does not have a significant dependency on the EJB container (as opposed to other types of EJBs), the preferred refactoring approach requires minimal (if any) code-level changes.

  • Refactoring requires the creation of additional application-level code to handle the looping and threading functionality around message reception. This functionality was previously handled by the EJB MDB container.
  • Another approach is to use Spring Framework's Message Driven POJO (MDP) functionality. MDBs are not inherently tied to the EJB container at the code level, because they are generally a class implementing the JMS MessageListener interface. Spring's MDP container functionality can also handle message-dispatching (including all needed internal threading and looping functionality) to MessageListeners. Refactoring to the use of Spring does not generally imply code level changes, but rather configuration of the Spring MDP container. Spring's MDP capabilities are a functional superset of EJB MDBs, but offer a number of additional capabilities, including the ability to drive messages to complete POJOs that do not even implement MessageListener and to allow the automatic conversion of a JMS message to other data types, when receiving or sending messages.

Entity EJB Migration Strategy

EJB 2.x entity beans are not available in a Tomcat environment. Migration to Tomcat requires refactoring of persistence logic currently implemented as entity beans. Entity beans are considered dead-end, legacy technology, and their use fell out of favor a number of years ago. Where legacy applications still use entity beans, their disadvantages are an excellent argument for refactoring, with or without a migration to Tomcat. Many IT organizations have standardized on third party Data Persistence solutions, including Hibernate and Kodo.

The goal in refactoring away from entity beans is to end up with an interface-based, decoupled data-access layer, so that to the extent possible, higher layers are mostly agnostic to actual persistence choices. Three of the technologies that exist for implementing persistence logic in the data access layer are:

  • Hybrid JDBC/ORM: The best example of this approach is iBatis, from iBatis essentially externalizes input/output and mapping logic to external files containing the SQL, while also offering some elements from object relational mappers, such as declarative mapping of data types, and automatic eager or lazy loading of related entities. iBatis does not perform change tracking in the nature of a true ORM. However, Spring Framework's iBatis support eliminates most resource management and try/catch boilerplate that would otherwise have to be used with iBatis.
  • ORM frameworks: ORM frameworks, such as Java Persistence API (JPA), Java Data Objects (JDO), or defacto-standards such as Hibernate, employ a higher-level, declarative approach to persistence, where the framework performs mapping between Java objects and the database, tracks changes to entities while in use, and handles related functions such as eager or lazy-loading of related entities. Some scenarios lending themselves to ORM use include:
  • Somewhat lower transaction volumes and/or more complex object graphs
  • No legacy schemas with use of DB features or relationships precluding use of ORM
  • Weaker SQL and/or DBA skills in-house
  • Limited or no use of stored procedures
  • JDBC: JDBC is a lower-level approach but is a strong choice in some scenarios. Consider the use of the Spring Framework's JDBC support, which eliminates most resource management and try/catch boilerplate typically associated with JDBC, while also offering low-overhead mechanisms to implement mapping logic. Some scenarios lending themselves to JDBC include:
  • Higher transaction volumes and/or simpler object graphs
  • Legacy schemas not amenable to object relational mapping (ORM)
  • Strong SQL and/or DBA skills in-house
  • Use of stored procedures

EJB Client Access Code Migration Strategy

Client code that accesses EJB functionality sometimes accesses EJBs through an abstraction or lookup layer, so that the client code is only aware of plain Java business interfaces. In general, this type of client code does not require significant refactoring when you are moving away from EJBs.

Where EJB client code has direct awareness of service EJBs, EJB stubs during lookup through JNDI, EJB exceptions, or EJB remote interfaces, you must refactor the client code as part of refactoring the service EJB code to plain Java service implementations. For migrations in which the Spring Framework is available and many EJBs exist, consider migrating EJB client code to use Spring's EJB proxies as an initial step. Client code working through Spring's EJB proxies is generally unaware of EJBs, and is concerned simply with business interfaces. The decoupling achieved in this fashion will then facilitate the Migrate in Pieces migration strategy, as it allows client code to be unaware of when exactly EJB service code is migrated.

Remoting Services

Existing application code that accesses or implements non-EJB remoting services through RMI can migrate essentially unchanged to a Tomcat environment. Convert remote EJB’s to POJO services as described in the preceding section on migrating EJB’s, and where remoting is still needed, implement remoting using RMI or another appropriate protocol.

Where remoting is desired, and some refactoring is needed regardless, consider using Spring's transparent remoting functionality. Spring Remoting allows POJO services to be exported in a declarative fashion, over a number of wire protocols, without the  services having to be aware of or coupled to the remoting protocol. Similarly, on the client, side, Spring can create client-side remoting proxies such that client code calling through the proxies is unaware that it is talking to anything other than a local business interface.

Data Sources

In a full stack application server environment, DataSources are typically application server-managed connection pools bound to the JNDI tree. When migrating to Tomcat, you can bind an instance of the high concurrency connection pool provided with Tomcat to Tomcat's JNDI tree, allowing client code to work as-is. Another common connection pool in usage in Tomcat environments is Commons database connection pool (DBCP), although the high concurrency pool is recommended for its higher scalability.

It is also quite common to embed the connection pool in the deployed application itself, where it is a product, such as DBCP, that allows this scenario. DBCP makes this process very easy, because you can create and configure it as a simple JavaBean.


Existing code utilizing Servlet spec security in the web layer will normally work unchanged in a Tomcat environment. That said, it is fairly rare for any real world application to depend on the Servlet spec security model and all the major JEE server vendors have augmented JEE security by adding sophisticated user privilege management services to their servers, as well as offering stand alone security products compatible with their JEE servers.

It is slightly more common for applications based on WAS to utilize container-managed security for EJB’s, although even there it is more common to utilize IBM’s excellent Tivoli Access Manager security, CA’s SiteMinder, or any of a number of third party application security products. In the case of WLS, BEA incorporated a comprehensive user/application security service directly into the server, and also offers a commercial upgrade that manages security for other environments. CA, IBM, and Oracle/BEA work with Tomcat, and user security generally transfers fairly readily.


The Tomcat environment does not provide an embedded message queue. As such, when moving applications from a full-stack application server environment where an embedded message queue in that environment is being used, an external message queuing product must be used alongside Tomcat. A number of options are available to you, both open source (for example, ActiveMQ) and commercial.

Convert EJB message-driven beans as described in Message-Driven EJB Migration Strategy. Where messaging-related code is being refactored, consider using Spring's extensive messaging functionality, to reduce messaging boilerplate in general, and to take advantage of Spring's out-of-the-box container managed Message Driven POJO capability.

Other messaging code should normally work unchanged in the Tomcat environment, once an external queue is plugged in, with the caveat that any vendor-specific code must be converted to the new message queuing product.

Administration and Management

Completely separate from the JEE specification (and other services) provided by the commercial JEE servers, these products also provide sophisticated management capabilities that are used by developers and IT administrators alike. Tomcat lacks most such capabilities, which makes the migration process somewhat more difficult for developers trying to debug the migrated code.

Many IT organizations have “rolled their own” Tomcat administration solutions. Some of these are excellent, but also have represented a major investment. They also tend to be script/console based and have fairly steep learning curves. None of the solutions I’ve seen include monitoring or management of other environments or of the complete stack, much less things like virtualized instances.

A number of commercial offerings are available that include a managed version of Tomcat environments, including VMware/SpringSource tcServer and MuleSoft’s Tcat Server. VMware/SpringSource’s product includes a Hyperic subset and is upgradable to full Hyperic for those environments where sophisticated monitoring and management is needed up/down the stack and across multiple environments. MuleSoft’s product is based on LambdaProbe, and while it is much less functional than Hyperic, it has also been optimized for Tomcat monitoring and management.


We’ve been discussing the conversion of applications from JEE Application Server’s to Tomcat based deployment environments. We’ve reached a number of conclusions, based on both IT industry experience and on expert advice. Some of the most important points are:

  • IT organizations can achieve significant benefits, both in total cost of ownership and in reduced weight/complexity, by migrating applications from JEE Application Servers to Tomcat.
  • It is extremely important to plan such migrations and to create organizational agreement for both objectives and costs.
  • Not all applications hosted on JEE Application Server are suited to migration…in some cases eliminating all the dependencies on JEE Application Server functionality is simply too costly.
  • Typically, Tomcat add-ins/plug-ins will be required for common application services that are beyond the scope of the Tomcat project charter. Remember that while Tomcat is demonstrably an “application server”, it is NOT (and not intended to be) a JEE Application Server. This means that some services (messaging, data persistence, security, etc) will need to be layered around Tomcat.
  • Where migrating applications from JEE Application Servers to Tomcat is both feasible and cost effective, IT organizations have multiple choices for both technology acquisition and support. These range from complete Open Source/DIY to using commercialized versions of Tomcat with support subscriptions. In all cases, with careful planning the IT organization can save significantly…sometimes in the millions of dollars annually, but using Tomcat is NOT free!

Take a hard look at where you are spending your IT dollars. You can save a lot by telling your JEE Application Server vendor “thanks, but we’re moving to Tomcat!"

Andy has recently decided to make the jump from individual consulting to join the Spring Source team. He will continue to be working with major clients to assist them with IT architecture evolution, now as a member of a large and growing organization. His first project will be leveraging Tomcat, Spring, and a Tomcat based data grid/cache called GemFire. He’s looking forward to sharing the lessons learned with the tomcatexpert community. Andy has been architecting, designing, and building enterprise infrastructure and applications software for most of his career. He’s been responsible for BEA’s “Blended Source” initiative, combining the best of Open Source (including both Tomcat and Spring) with WebLogic, BEA’s WebLogic Enterprise Security product family, MEI Software’s financial systems, Netegrity’s SiteMinder security product, Camex’s electronic publishing systems, mainframe applications for Bell Telephone, and many others. During that time his hands on technology experience has ranged from octal coding into neon lighted switches all the way through JAVA and beyond, including many generations of “the best and final thing we will ever need”, and he looks forward to working on the even better things coming in the future. He was involved in the early days of Open Source software as a contributor to EMACS and refocused on Open Source during his tenure as Director of Product Management with BEA Systems, combined with a fascination for the rapidly evolving application deployment architectures and technologies driving today’s development. Andy has provided architecture and technology guidance for both vendors and IT organizations and he shares what he is learning through consulting services and through his web site, Enterprise Software Trends (


Migrating Java applications

Migrating Java applications from JEE Application Servers to Tomcat applications seems to be the most tricky things these days. But you have proven that with expert advice and tutorials, nothing is impossible. You have seriously researched a lot to come up with this piece. Thanks and keep the good work on! auto repair in los angeles

cmx videomxf

Software avchd converter convert avchd video files to avi, mp4, wmv, mov mod converter free download to convert HD camcorder files. mts to avi mp4 mov mkv iMovie, FCP/FCE with mts converter, so to convert mts files for your PC and mobiles. Thanks and keep the good work on!

I'm glad to see the great

I'm glad to see the great detail here!.

Thanks you very much for

Thanks you very much for sharing these links. Will definitely check this out..
Jason Spencer Dallas

Thanks for a wonderful share.

Thanks for a wonderful share. Your article has proved your hard work and experience you have got in this field. Brilliant .i love it reading.
Strategic Marketing

Exactly, you're very kind of

Exactly, you're very kind of us about comment!.
navigate to this website

Your website is really cool

Your website is really cool and this is a great inspiring article.
appetite suppressant gummies

Wow what a Great Information

Wow what a Great Information about World Day its very nice informative post. thanks for the post.
phenq ingredients


This is a great inspiring article.I am pretty much pleased with your good work.You put really very helpful information...
android spy
android spy

This is such a great resource

This is such a great resource that you are providing and you give it away for free. I love seeing blog that understand the value of providing a quality resource for free.

It is imperative that we read

It is imperative that we read blog post very carefully. I am already done it and find that this post is really amazing.
android spy

Is it okay to post part of

Is it okay to post part of this on my website basically post a hyperlink to this webpage?
Baseball Drills


This is truly a great read for me. I have bookmarked it and I am looking forward to reading new articles. Keep up the good work!.
buy steroids canada


I was surfing net and fortunately came across this site and found very interesting stuff here. Its really fun to read. I enjoyed a lot. Thanks for sharing this wonderful information.
condo for sale cebu

I have not any word to

I have not any word to appreciate this post.....Really i am impressed from this post....the person who create this post it was a great human..thanks for shared this with us.
West Virginia Mesothelioma Law Firm

Interesting and amazing how

Interesting and amazing how your post is! It Is Useful and helpful for me That I like it very much, and I am looking forward to Hearing from your next..
new futura 5 bedroom

This article gives the light

This article gives the light in which we can observe the reality. This is very nice one and gives in depth information. Thanks for this nice article.
wedding dresses uk

This is such a great resource

This is such a great resource that you are providing and you give it away for free. I love seeing blog that understand the value. Im glad to have found this post as its such an interesting one! I am always on the lookout for quality posts and articles so i suppose im lucky to have found this! I hope you will be adding more in the future...
billiga makeup borstar fraktfritt online

I think this is an

I think this is an informative post and it is very useful and knowledgeable. therefore, I would like to thank you for the efforts you have made in writing this futura 2 bedroom

This is a smart blog. I mean

This is a smart blog. I mean it. You have so much knowledge about this issue, and so much passion. You also know how to make people rally behind it, obviously from the responses.
new futua launch

buy followers review This is

buy followers review This is also a very good post which I really enjoyed reading. It is not every day that I have the possibility to see something like this.. buy youtube views and comments

8 ball pool hack no

8 ball pool hack no survey These things are very important, good think so - I think so too... clash of clans juwelen hack

I truly love your blog.. Very

I truly love your blog.. Very nice colors & theme. Did you make this website yourself? Please reply back as I’m trying to create my very own website and would like to know where you got this from or just what the theme is named. Many thanks!
Mortgage Broker Calgary

We can migrate JEE

We can migrate JEE application to Apache Tomcat server by sending the JAR files into tomcat lid directory. We must see that each and every JAR file is transferred into lid directory as per reviews i got to know. By migrating JEE application into tomcat. This application will get access to use all the server resources.

Amazing, this is great as you

Amazing, this is great as you want to learn more, I invite to This is my page. party source


nice post i will love Wallpaper car and then you choose baked potato casserole recipes

psn free codes

It is time of the generator which generates the unused codes,One of them are psn code generator which gives you the free psn codes within just click.


This is one of the best site and your "Applications to Apache Tomcat" post too good. Please update some more great post as soon because your post gives us some awesome ideas. For sale new gymnastic mats

Thanks for writing such a

Thanks for writing such a good article, I stumbled onto your blog and read a few post. I like your style of writing...
arino party wear shoes

I love the blog. Great post.

I love the blog. Great post. It is very true, people must learn how to learn before they can learn. lol i know it sounds funny but its very true. . .
mozrank checker

I have learned java which is

I have learned java which is one of the toughest programming languages. Migrating JEE applications to Apache Tomcat is a very difficult task and for doing that it is important to follow many steps and all the points are clearly given here. off road gear for trucks

his is also a very good post

his is also a very good post which I really enjoyed reading. It is not every day that I have the possibility to see something like this attorney mm to inches inche to cm

Apart from the value of such

Apart from the value of such assertions as "there is a categorical imperative in us," one can always ask: What does such an assertion indicate about him who makes it? There are systems of morals which are meant to justify their author in the eyes of other people; other systems of morals are meant to tranquilize him, and make him self-satisfied; with other systems he wants to crucify and humble himself, with replica burberry handbags others he wishes to take revenge, with others to conceal himself, with others to glorify himself and gave superiority and distinction,—this system of morals helps its author to forget, that system makes him, or something of him, forgotten, many a moralist would like to exercise power and creative arbitrariness over mankind, many another, perhaps, Kant especially, gives us to understand by his morals that "what is oyster perpetual air-king estimable in me, is that I know how to obey—and with you it SHALL not be otherwise than with me!" In short, systems of morals are only a SIGN-LANGUAGE OF THE EMOTIONS.

In contrast to laisser-aller, every system of morals is a sort of tyranny against "nature" and also against "reason", that is, however, no objection, unless one should again decree by some system of morals, that all kinds of tyranny and unreasonableness are unlawful What is essential and invaluable in every system of morals, is that it is a long constraint. In order to understand Stoicism, or Port Royal, or breitling Puritanism, one should remember the constraint under which every language has attained to strength and freedom—the metrical constraint, the tyranny of rhyme and rhythm. How much trouble have the poets and orators of every nation given themselves!—not excepting some of the prose writers of today, in whose ear dwells an inexorable conscientiousness—"for the sake of a folly," as utilitarian bunglers say.

And thereby deem themselves wise—"from submission to arbitrary laws," as the anarchists say, and thereby fancy themselves "free," even free-spirited. The singular fact remains, however, that everything of the nature of freedom, elegance, boldness, dance, and masterly certainty, which exists or has existed, whether it be in thought itself, or in administration, or in speaking and persuading, in art just as in conduct, has only developed by means of the tyranny of such arbitrary law, and in all seriousness, it is not at all improbable that precisely this is "nature" and "natural"—and not laisser-aller! Every artist rolex submariner knows how different from the state of letting himself go, is his "most natural" condition, the free arranging, locating, disposing, and constructing in the moments of "inspiration"—and how strictly and delicately he then obeys a thousand laws.

Which, by their very rigidness and precision, defy all formulation by means of ideas (even the most stable idea has, in comparison therewith, something floating, manifold, and ambiguous in it). The essential thing "in heaven and in earth" is,rolex datejust apparently (to repeat it once more), that there should be long OBEDIENCE in the same direction, there thereby results, and has always resulted in the long run, something which has made life worth living; for instance, virtue, art, music, dancing, reason, spirituality—anything whatever that is transfiguring, refined, so hot foolish, or divine.


Nice information
Very good for file and picture share To PC To any Phone
xender for pc


In your posts, all blog posts are providing complete information of java. Keep posting the updations and tutorials which can be easily understood by the viewers.


Outsourced Software Development

You’ve written nice post, I

You’ve written nice post, I am gonna bookmark this page, thanks for info. I actually appreciate your own position and I will be sure to come back here.his is a really good post. Must admit that you are among the best bloggers I have read. Thanks for posting this informative article of obat aborsi . You may havce a lot of jual obat aborsi and obat aborsi

obat aborsi | cara menggugurkan kandungan | jasa website | jasa pembuatan website

Travel Haji Umroh

Good writing, good, and very informative. Thank you for posting

Biaya umroh Februari
promo umroh Februari 2017
promo umroh Februari Murah
promo umroh Februari Hemat
promo umroh Februari
promo Murah umroh Februari
promo paket umroh Februari

This type of message always

This type of message always inspiring and I prefer to read quality content, so happy to find good place to many here in the post, the writing is just great, thanks for the post worlds best diet pill.


Since the land the golf course sits on was annexed in separate pieces from the county to the city of Phoenix, two-thirds of the course has a stipulation specifying an 18-hole golf course, while the remaining one-third has no such stipulation. seo monthly packages

This article gives the light

This article gives the light in which we can observe the reality. This is very nice one and gives indepth information. Thanks for this nice article best male enhancement pills.

Thanks lots considerably for the aim of finding the time towards doubt this original, thus I’m if truth be told to line it yet again and collectively utterly love grasping further relating to world organization agency articles and different content. That future in these nowadays adopt this distinctive it's very from marvelous steering for every individual.

Thank you for sharing the

Thank you for sharing the post! The information is very detailed. instagram cars

I read that Post and got it

I read that Post and got it fine and informative.
pool builder reviews

I found your this post while

I found your this post while searching for some related information on blog search...Its a good post..keep posting and update the information.
inz residence balance units


All the contents you mentioned in post is too good and can be very useful. I will keep it in mind, thanks for sharing the information keep updating, looking forward for more posts.Thanks
condo for sale

Post new comment

This question is for testing whether you are a human visitor and to prevent automated spam submissions.