Filip is a Senior Software Engineer for SpringSource and a key participant in the company’s Apache Tomcat initiatives. Filip has extensive experience working in the architecture, design and development of distributed application frameworks and containers and is recognized for his top-quality system development skills and continuous participation of open source development projects. Filip is an active committer to the Apache Tomcat project and a member of the Apache Software Foundation (ASF) where he is a leading authority on Tomcat clustering and author of the Hitch-Hikers Guide to Tomcat. Prior to SpringSource, Filip worked as a Senior Software Engineer at Covalent Technologies which SpringSource acquired in early 2008. Previously, Filip was a Senior Software Engineer/Architect for La Quinta Corporation. Filip has made contributions to software initiatives for walmart.com, Sony Music, France Telecom and has held a variety of senior software engineering positions with VRP Consulting, Pakana Corporation, XmarkstheSpot.com, Extrico Data AB, IRIS Data AB, and SEBA Data AB. Filip received his education at Chalmers University of Technology in Gothenburg, Sweden where he majored in Computer Science and Computer Engineering. Filip has posted 1 posts at DZone. View Full User Profile

SpringSource tcServer - The Tomcat You Know, The Enterprise Capabilities You Need

01.05.2009
| 34713 views |
  • submit to reddit

Comparing Tomcat with a JEE server makes Tomcat look very bleak:

  • For a sales person – it would have a very limited feature set to use as selling points

  • For a developer – it implements a very limited set of technologies

  • For a system administrator – it lacks many of the bells and whistles that commercial vendors have for production support

Of these comparison points, it's the first two that have made Tomcat such a popular platform.

Less is more

During a meeting with a CTO, in the process of migrating from a commercial JEE platform to a more cost friendly solution, I was told that he only had one primary concern regarding the cost of the platform. To my surprise, it was not the cost of acquiring the technology solution, it was the cost of migrating away from it. Acquiring a new technology solution has a known cost factor, that can be calculated before making the decision. The cost of keeping the technology and possible trying to move away from it becomes the unknown factor. When managing long term cost, it is a natural move to choose an application server like Tomcat. An application running on Tomcat is almost guaranteed to run on any other application server. Adding complexity turns out to be easier and cheaper than removing it.

Lacking the coolness factor didn't stop developers, who adopted Tomcat before it became a popular application server for production environments. It turned out that productivity increased, solutions became simpler, easier to maintain and more efficient than the ones that had previously been developed.

Gratification from a well performing, on time and under budget application is as, if not more, satisfying than playing around with technologies that sound enticing.

Similar advancements of choosing simple technologies over complex have become a de facto standard in the development industry. The Spring framework is possibly one of the more prominent examples. Feedback from developers has been that combining frameworks like Spring and Tomcat, simplifies software development, especially for larger, more complex projects.

If there is princess, then there has to be a pea. According to the tale, The Princess and the Pea, written by the Danish poet Hans Christian Andersen, only a princess would be so sensitive that she would have to endure a sleepless night due to a single pea under a layer of 20 mattresses.

One doesn't have to be a princess to realize that Tomcat doesn't measure up to all the needs of a deployed application server in production. The pea is pretty obvious. A savvy Unix administrator accustomed to text based configuration files and with a good knowledge of the TCP stack implementation fares fairly well with Tomcat. Small install, a few configuration tweaks and launch the server. It works well in smaller environments with a few dozen instances running.

Trying to accomplish the same thing in a larger server farms means the administrator has to develop a custom framework to handle these installations. If configuration changes are required the management framework will have to expanded to handle these changes for existing instances.

I have had the fortune to be able to work with numerous operations teams, and be a part of hundreds of different Tomcat installations and environments. All of them share a few common challenges and solutions.

Published at DZone with permission of its author, Filip Hanik.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Andrew McVeigh replied on Mon, 2009/01/05 - 1:01pm

Hi Filip,

All good stuff. Would you mind, though, putting in something either in your profile or at the start of your article that you work for SpringSource/Covalent? It clarifies for people what your affiliations are.

Cheers,
Andrew 

p.s. I have no affiliations with any middleware company of any sort. 

Ryan Developer replied on Tue, 2009/01/06 - 1:50am

Can you provide a compelling reason for someone using light weight open source GlassFish V3 to switch?

Will tcServer be open source?  How much will it cost for support? When SpringSource first announced support they quoted me $22,500/year for a single server 2 cpu computer in our customer's server room. For less than that price we can purchase support for unlimited servers running any of Sun's entire software portfolio (Java Enterprise System).  We're paying $4,500/year for GlassFish support right now. 

Filip Hanik replied on Tue, 2009/01/06 - 11:49am in response to: Ryan Developer

hi Ryan,

 [quote] Can you provide a compelling reason for someone using light weight open source GlassFish V3 to switch? [/quote]

 

If I was a manager for a medium to large size development shop, the most compelling reason is employee turnover. The skillset in Tomcat is already out there. Compared to Glassfish, the ratio of developers that know Tomcat versus the number of developers that know Glassfish is pretty large. So everytime an employee leaves, it most likely means that I have to hire someone and train them on the platform that I have picked.

The other reason would be company stability. tcServer is built on top of Apache Tomcat and switching between the two is as easy as switching between Apache Tomcat and Apache Tomcat, and the Apache Tomcat product is not very likely to go away anytime soon. In my article I also brought up the interesting point of exit cost, and that is what a manager for a larger company should be looking at in addition to the costs they are evaluating today. 

While I can't answer pricing questions here, the quote you received in September of 2008 is definitely not for a single server deployment. That just sounds like there was a simple misunderstanding based on what you were asking for and what the sales rep actually delivered. In a competive market, support prices will be competitive.

[quote] Will tcServer be open source? [/quote]

tcServer is a suite of components, and will not be released as open source. In my next article I will cover more of the technical details of what tcServer is and how they work together.

Chandra Sekar.S replied on Tue, 2009/01/06 - 12:19pm in response to: Filip Hanik

[quote=fhanik]

hi Ryan,

 [quote] Can you provide a compelling reason for someone using light weight open source GlassFish V3 to switch? [/quote]

 

If I was a manager for a medium to large size development shop, the most compelling reason is employee turnover. The skillset in Tomcat is already out there. Compared to Glassfish, the ratio of developers that know Tomcat versus the number of developers that know Glassfish is pretty large. So everytime an employee leaves, it most likely means that I have to hire someone and train them on the platform that I have picked.[/quote]

Rather than giving such generic claims, can you pinpoint atleast a couple of areas where developers (not admins) need retraining to use Glassfish which is not needed on Tomcat?

William Louth replied on Tue, 2009/01/06 - 3:44pm

""All of them share a few common challenges ........(1) Custom installation method (2) Custom management and configuration solutions (3) Custom monitoring tools"

What is with the "custom" monitoring tools?

You mean tools that are not tied to one company one platform (tc).

You mean tools that actually support industry IT management standards (ITIL:CMDB,SPE,....) and provide the same feature set across multiple managed runtimes. 

You mean tools that outperform by a huge margin the jamon like monitoring code you offer up in garnish dashboard that is only applicable in one application lifecycle stage.

Sorry I have much more powerful and truly intelligent diagnostics that are not tied to one web server and work offline across all life cycle stages and can actually be used in the environment they are needed for - production.

Of course anyone with some degree of real-world management experience would know that the focus is more on the application software execution behavior than the middleware even with all its factories and layers of indirection to create a "simple" singleton POJO bean.

William

Filip Hanik replied on Wed, 2009/01/07 - 6:47pm in response to: Chandra Sekar.S


[quote=chandru.in]

Rather than giving such generic claims, can you pinpoint atleast a couple of areas where developers (not admins) need retraining to use Glassfish which is not needed on Tomcat?

[/quote]

Being a huge solaris fan myself, running both Solaris and OpenSolaris, trying to install glassfish 3 leads to

[quote]

Welcome to GlassFish V3 installer

Using the user defined JAVA_HOME : /software/jdk1.5.0_14
Entering setup...
Warning: Cannot convert string "-monotype-arial-regular-r-normal--*-140-*-*-p-*-iso8859-1" to type FontStruct
Warning: Unable to load any usable ISO8859 font
Warning:
   Name: FONTLIST_DEFAULT_TAG_STRING
   Class: XmRendition
   Conversion failed.  Cannot load font.

java.lang.InternalError: java/langNullPointerException
   at sun.awt.motif.MComponentPeer.pSetFont(Native Method)
   at sun.awt.motif.MComponentPeer.setFont(MComponentPeer.java:247)
   at sun.awt.motif.MWindowPeer.init(MWindowPeer.java:122)
   at sun.awt.motif.MFramePeer.<init>(MFramePeer.java:58) 

[/quote]

Compare this to a Tomcat install on the same system:

[quote]

gunzip apache-tomcat-6.0.18.tar.gz

gtar xvf apache-tomcat-6.0.18.tar

[/quote]

Is there a need for a GUI installer, is this really the optimal way for a server product.

Another interesting read is the fact that Sun offers free training in order to increase adoption.

If the system was so intuitive, would I need training? My guess is that Sun thinks so. A free lance developer can learn plenty about Tomcat simply using free resources.

 

Rather than digging into details and making this a Apache Tomcat vs Glassfish discussion, which ignores the other very important factors of the article. For example, does anyone know how the recent cuts in work force at Sun Microsystems will effect the Glassfish container, and would one want to bet his/her business on it?

Its not about the acquisition cost alone, and that is the important point to take home. 

Ryan Developer replied on Wed, 2009/01/07 - 11:13pm in response to: Filip Hanik

[quote=fhanik]
If I was a manager for a medium to large size development shop, the most compelling reason is employee turnover.
...
So everytime an employee leaves, it most likely means that I have to hire someone and train them on the platform that I have picked.
[/quote]

Won't new hires have to learn tcServer's management, monitoring, and other features?  That isn't very different from having to learn GlassFish.  In GlassFish you never see XML because everything can be done with an intuitive web UI or a command line tool.  It's not exactly like Tomcat so I can see your point.  JBoss is built on Tomcat too. 

 

[quote=fhanik]
In my article I also brought up the interesting point of exit cost, and that is what a manager for a larger company should be looking at in addition to the costs they are evaluating today.

[/quote]

Switching from GlassFish to JBoss, WebSphere, or WebLogic is simple because they all implement the Java EE standards.  My application is completely portable because I don't use any vendor specific features.  Those who choose to avoid Java EE standards and also don't use proprietary features will have no problems switching vendors either. Once SpringSource adheres to Java EE 6 Web Profile, my application will work on your application server too.


[quote=fhanik]
Compare this to a Tomcat install on the same system:

gunzip apache-tomcat-6.0.18.tar.gz

gtar xvf apache-tomcat-6.0.18.tar

Is there a need for a GUI installer, is this really the optimal way for a server product.
[/quote]

You are absolutely right, there shouldn't be a need to use a graphical installer for a server product. You clicked the link with the description "GUI-based installer for Solaris, Linux and MacOS X". Directly below that link is a link with the description "Platform-independent download file". I downloaded this file onto my OpenSolaris box and extracted it with one less command than you did for Tomcat:

 

$ unzip glassfish-v3-prelude-ml.zip
 

I was able to start the server then browse around the intuitive web admin console within seconds.  

[quote=fhanik]
Another interesting read is the fact that Sun offers free training in order to increase adoption.

If the system was so intuitive, would I need training? My guess is that Sun thinks so. A free lance developer can learn plenty about Tomcat simply using free resources.
[/quote]

Read the rebuttal : blogs.sun.com/jclingan/entry/when_they_smile_you_know

What I find interesting is that I was able to get started with GlassFish without having to read online reference documentation. I was able to discover and learn its features using the intuitive web admin console. For those that want free online resources to learn more, there is a comprehensive online manual too: docs.sun.com/app/docs/prod/gf.ent.svr

Has SpringSource spent any time looking at GlassFish? I wouldn't think so since any marketing piece that mentions other application servers like JBoss, WebSphere and WebLogic fail to mention GlassFish.  I figure its to play down GlassFish's rapid worldwide adoption:

blogs.sun.com/theaquarium/entry/260k_glassfish_v2_registrations_and
beta.glassfish.java.net:81/maps/
 

[quote=fhanik]
does anyone know how the recent cuts in work force at Sun Microsystems will effect the Glassfish container, and would one want to bet his/her business on it?

[/quote]

Sure, they are restructuring. For more details look here:

www.sun.com/aboutsun/pr/2008-11/sunflash.20081114.1.xml

They survived the .com bust, and I personally have no doubt that Sun will be around for many years to come.  I should ask the same question of SpringSource. Why should I bet my business on a company that has relied on venture capital and is creating products that encourage the use of proprietary non standards that are not portable to other vendors unless I don't use any of the features, which defeats the purpose of using it. If SpringSource goes out of business, their product is not open source.

 

Oleg Zhurakousky replied on Thu, 2009/01/08 - 12:38am in response to: Ryan Developer

rdelaplante wrote
Switching from GlassFish to JBoss, WebSphere, or WebLogic is simple because they all implement the Java EE standards
Yeah. . . I am gonna assume you actually have never done this outside of pure academics. . . JEE, although meant to be portable, never has been. JEE application on JBoss is not portable to another platform such as WAS unless you spend some time making it portable. I spent 3 years of my career migrating apps from WAS and WebLogic to JBoss and it was anything but trivial due to all kinds of proprietary extensions and APIs on either platforms which resulted in a typical vendor lock-in.
rdelaplante wrote
My application is completely portable because I don't use any vendor specific features.
So what's your point? While you thrive on making application adhere to JEE standard you are missing on the number of vendor inovations (IBM or Spring), inovations that standards bodies are not to quick or willing to adapt which essentially makes your application a "legacy application" from the get go.
rdelaplante wrote
Why should I bet my business on a company that has relied on venture capital and is creating products that encourage the use of proprietary non standards that are not portable to other vendors unless I don't use any of the features, which defeats the purpose of using it
Have you had any issues migrating Spring ApplicationContext between various application servers? If there was anything that is trully portable, that would be it. Take Spring powered WAR and drop it without any changes to any server and I bet it will just work.

Ryan Developer replied on Thu, 2009/01/08 - 1:26am in response to: Oleg Zhurakousky

[quote=azhurakousky]

Yeah. . . I am gonna assume you actually have never done this outside of pure academics. . . JEE, although meant to be portable, never has been. JEE application on JBoss is not portable to another platform such as WAS unless you spend some time making it portable. I spent 3 years of my career migrating apps from WAS and WebLogic to JBoss and it was anything but trivial due to all kinds of proprietary extensions and APIs on either platforms which resulted in a typical vendor lock-in.

[/quote]

I've migrated from JBoss to GlassFish and did not have have these problems. Actually, one app did use JBoss's proprietary JMX MBeans which I later ported to JCA.  It is a well known fact that the old J2EE of years ago had a lot of vendor proprietary settings in deployment descriptors, but that is nearly gone now.  Especially with Java EE 5 and soon 6. The reason to choose one application server vendor over another is not the proprietary APIs it provides, but the management, monitoring, high availability, scalability, support costs, trust in the vendor, etc.  This is where I see benefit in tcServer.  Like other vendors, SpringSource is offering an application server with these benefits, and are a well trusted name to many. Those who are really into SpringSource now have one stop-shopping for everything they need. 

 

[quote=azhurakousky]

rdelaplante wrote
My application is completely portable because I don't use any vendor specific features.

So what's your point?

[/quote]

The author of this post used exit strategy of tcServer as a compelling reason to switch from GlassFish. My point is that there isn't an issue migrating from GlassFish to other vendors. It's not like GlassFish forces you into using proprietary extensions. Developers know better these days. I guess the difference with Spring is that the proprietary extensions (Spring APIs) get built into your .war file and installed on another vendors application server. 

 

[quote=azhurakousky]

While you thrive on making application adhere to JEE standard you are missing on the number of vendor inovations (IBM or Spring), inovations that standards bodies are not to quick or willing to adapt which essentially makes your application a "legacy application" from the get go.

[/quote]

I beg to differ. Plus I do use Spring and other innovations. Java EE standards != EJB. Java EE is made up of many technologies, some of which have pluggable implementations (like JPA):

java.sun.com/javaee/technologies/

As I mentioned before, applications that avoid Java EE standards still run on GlassFish and are still portable to other application servers.  Exit strategy is not a compelling reason for me to switch from GlassFish to tcServer.

[quote=azhurakousky]

Have you had any issues migrating Spring ApplicationContext between various application servers? If there was anything that is trully portable, that would be it. Take Spring powered WAR and drop it without any changes to any server and I bet it will just work. [/quote]

I was talking about SpringSource's new stuff like DM Server, which labels everything in Java EE "legacy archives" in favor of its new OSGi based archives. I read that server side OSGi needed a lot of work, which is where DM Server helps a lot.  Is that portable to Tomcat, GlassFish, JBoss, WebLogic and WebSphere? Maybe tcServer is a whole different story.  I'll have to wait for the next article to come out that explains what it is in more detail.

Oleg Zhurakousky replied on Thu, 2009/01/08 - 1:42am in response to: Ryan Developer

. . .which is where DM Server helps a lot. Is that portable to Tomcat, GlassFish, JBoss, WebLogic and WebSphere?. . .
Don't really want to highjack the topic, but I look at OSGi based server environments as the next-gen Enterprise Java Platform with quite different development and deployment model which is what dmServer is all about. Why would I worry about porting it back. . .?

Ryan Developer replied on Thu, 2009/01/08 - 2:28am in response to: Oleg Zhurakousky

[quote=azhurakousky]Don't really want to highjack the topic, but I look at OSGi based server environments as the next-gen Enterprise Java Platform with quite different development and deployment model which is what dmServer is all about. Why would I worry about porting it back. . .? [/quote]

That is how I feel about GlassFish V3/Java EE 6.  You are right, this is off topic. 

Filip Hanik replied on Thu, 2009/01/08 - 11:01am in response to: Ryan Developer

[quote=rdelaplante]

Won't new hires have to learn tcServer's management, monitoring, and other features?  That isn't very different from having to learn GlassFish.  In GlassFish you never see XML because everything can be done with an intuitive web UI or a command line tool.  It's not exactly like Tomcat so I can see your point.  JBoss is built on Tomcat too. 

[/quote]

This is not about Tomcat vs. Glassfish, so I wont go into more detail here, there are other fish in the pond, glassfish is one of the smallest fish in that pond.

[quote=rdelaplante]

Why should I bet my business on a company that has relied on venture capital and is creating products that encourage the use of proprietary non standards that are not portable to other vendors unless I don't use any of the features, which defeats the purpose of using it.

[/quote]

I'm glad you brought this up.

Sure you can throw out the argument that Glassfish is open source, but when you do that, you simply don't understand open source. When it comes to open source, it all is in the license, license, license. I can create an open source project, license it in such a way that you can take the code and continue should the owner of the project go away. the Apache License 2.0 is very generous, and gives you as the consumer ample flexibility, freedom and protection So when betting on open source, always understand the license. Now I'm not a lawyer, so I wont go deeper on this topic either, but it is an important one to keep in mind.

The most interesting point in your quote is that you're not betting your business on SpringSource, you're investing in Apache Tomcat as the core of your platform. Should SpringSource against all odds go away, Apache Tomcat will always be there. That can't really be said for any of the other platforms mentioned here. The support we provide for tcServer is the same support you can purchase for the open source Apache Tomcat as well. When running on tcServer, you can leverage additional features, but none of those features prevent the application from being portable and move away should you really need to. And that is the beauty of it, move the application to Apache Tomcat, and it still works.

We're not the only company providing support for Apache Tomcat, we're just the company providing the best support for Apache Tomcat. So you can hedge your bets here as well.

All in all, it comes down to managing risk, understand the choices that are made and what they might cost you in the future.

Ryan Developer replied on Thu, 2009/01/08 - 12:08pm in response to: Filip Hanik

[quote=fhanik]

there are other fish in the pond, glassfish is one of the smallest fish in that pond.

[/quote]

GlassFish is shaping up to become one of your strongest competitors. You guys should stop pretending that it is insignificant.

 

[quote=fhanik]

Sure you can throw out the argument that Glassfish is open source, but when you do that, you simply don't understand open source.

[/quote]

Excuse me??

 

[quote=fhanik]

When it comes to open source, it all is in the license, license, license. I can create an open source project, license it in such a way that you can take the code and continue should the owner of the project go away. the Apache License 2.0 is very generous, and gives you as the consumer ample flexibility, freedom and protection So when betting on open source, always understand the license. Now I'm not a lawyer, so I wont go deeper on this topic either, but it is an important one to keep in mind.

[/quote]

And that is why GlassFish is dual-licensed under both Sun's CDDL and GPLv2.  Since when has GPLv2 stopped a business from runing their applications ontop of things like Linux?  Using GPLv2 is only a disadvantage to those who want to fork it and create their own product based on it.  It forces them  to contribute their improvements upstream, which is a disadvantage to a company like SpringSource who wants to create a closed source application server based on an existing open source product.  It appears that you are the one who doesn't understand open source. 

 

[quote]

The most interesting point in your quote is that you're not betting your business on SpringSource, you're investing in Apache Tomcat as the core of your platform. Should SpringSource against all odds go away, Apache Tomcat will always be there.

[/quote]

I'll have to wait and see your next article about what tcServer is.

An interesting point about your quote on betting my business on Sun by choosing GlassFish is that GlassFish will always be around too, even if Sun goes away.  GlassFish V3 is the new Tomcat with instant startup, directory deploy, superior management, clustering, optional Java EE APIs, etc. If tcServer wasn't ceated, Tomcat would have become technically inferior to GlassFish V3, which by the way is not fully released yet.  V3 Prelude is released, but doesn't have all of the capabilities of V2 such as clustering.

I'm sorry to keep going on about GlassFish. I would like to have stopped earlier but I have to respond to these kinds of comments.

Filip Hanik replied on Thu, 2009/01/08 - 1:57pm in response to: Ryan Developer

[quote] I'm sorry to keep going on about GlassFish. I would like to have stopped earlier but I have to respond to these kinds of comments. [/quote]

Yes, this will be my last response about Glassfish, it is simple not relevant to the article in its whole, its leadin nor its conclusion.

What is interesting though is that even Glassfish is built partially on Apache Tomcat

[quote]An interesting point about your quote on betting my business on Sun by choosing GlassFish is that GlassFish will always be around too, even if Sun goes away. [/quote]

A software projects future also depends on who owns and controls the license and what the contributor agreement looks like. Just being an open source project/license, doesn't really guarantee anything about the future of the project. That would be a very false and misleading statement to make. 

As you may not yet have noticed, I have not even talked about features of Glassfish or other containers, or how cool or superior they may be, since its not relevant. For a technologist like myself, I still do think the larger JEE platforms are way cooler than Apache Tomcat when it comes to feature completeness and innovation, but that doesn't drive my decision of adoption. Software sales have long been based on that assumption, but I would not be surprised if that starts changing in the future as well.

An SUV or sport car is a lot cooler than a small fuel efficient car that start shaking as soon as gets anywhere near 90mph. That doesn't mean I will buy that car again. When I look back at what got me to buy that car in the first place and what kind of car I actually needed to get to my destination, I may reevaluate my original decision.

Dont get side tracked again and miss the point of the term 'less is more', that its not the cost of adopting a technology just cause it has more and fancier features, or is by some considered superior. By doing that you may have just fallen into the trap that the article meant to educate you about.

So I think its safe for me to stop talking about Glassfish or any other container for that matter, since nothing new is being brought to the table and is beside the point, and start looking at the bigger picture. My own fault and mistake for being sucked into it.

The best way to predict the future is to read up on the past, learn from others mistakes rather than repeating them youself.  Avoiding costly adoption mistakes is most easily done by not following or chasing buzz words or bloggers advice, but to take a clear look of where complexity can be removed and simplicity added.

 

Alexis MP replied on Thu, 2009/01/08 - 5:53pm in response to: Filip Hanik

[quote=fhanik]

Sure you can throw out the argument that Glassfish is open source,but when you do that, you simply don't understand open source. When itcomes to open source, it all is in the license, license, license. I cancreate an open source project, license it in such a way that you cantake the code and continue should the owner of the project go away. theApache License 2.0 is very generous, and gives you as the consumerample flexibility, freedom and protection So when betting on open source, always understand the license. Now I'm not a lawyer, so I wont go deeper on this topic either, but it is an important one to keep in mind.[/quote]

So what exactly is ASL 2 giving you that CDDL + GPLv2 is not?
License is not everything in an open source project. IP and governance are two other key parts. 

Filip Hanik replied on Thu, 2009/01/08 - 6:28pm in response to: Alexis MP

[quote=alexismp]

So what exactly is ASL 2 giving you that CDDL + GPLv2 is not?

[/quote]

There is no such thing as ASL 2. I don't think I have to go into details what AL 2.0 gives you in terms of flexibility. If you are looking for license comparisons, there is plenty of information in the web, much more than I can disseminate in a single comment response. 

[quote=alexismp]

License is not everything in an open source project. IP and governance are two other key parts. 

[/quote]

You are absolutely right, and that is the beauty of Apache Tomcat, it is developed under a very well defined governance model. One that has proven itself again and again. As for the IP, the individual contributor retains the rights to the IP, as well as grants the ASF the right to use it. I would say that as for governance and IP of Apache Tomcat, it speaks for itself, no need for a comparison.

Andrew McVeigh replied on Thu, 2009/01/08 - 8:19pm

The article's content is great, but many of the responses from Filip are shocking.

Let's quote back a selection of Filips comments:

 tcServer is a suite of components, and will not be released as open source

 Ok, fair enough.  It's your choice.  You are writing the extensions, and the ASL2.0 license allows it.

 For example, does anyone know how the recent cuts in work force at Sun Microsystems will effect the Glassfish container, and would one want to bet his/her business on it?

An ad hominem attack on a competitor as soon as Ryan reasonably asks for a technical justification?  That's your position?? -- that SUN might fold and therefore they are better using tcserver?  On that basis I certainly wouldn't base my software on tcserver -- what if SpringSource folds -- i'm back to plain vanilla tomcat and left possibly with an unmanageable set of servers?  Better not to use it in the 1st place then.

If the system (Glasshfish) was so intuitive, would I need training? My guess is that Sun thinks so. A free lance developer can learn plenty about Tomcat simply using free resources.

What a load of rubbish.  What use are the covalent training courses then?  https://www.covalent.net/services/training/onsite.html  Are you serious about this point?  And you couldn't install Glassfish on Solaris and claim it's a bad product because of that?  It's delivered usually as a zipfile.  Unzip and go.  C'mon.

Oleg now pipes up.  Another unacknowledged SpringSource/Covalent employee:

Don't really want to highjack the topic, but I look at OSGi based server environments as the next-gen Enterprise Java Platform with quite different development and deployment model which is what dmServer is all about. Why would I worry about porting it back.

Umm,yeah, of course you do.

Back to Filip:

Sure you can throw out the argument that Glassfish is open source, but when you do that, you simply don't understand open source. When it comes to open source, it all is in the license, license, license.

You are exactly right -- the license is the key.  So, why is tcserver not under the ASL2.0?  Of course, it's a commercial product.  Noone cares if it's commercial -- that's your choice.  Just don't go trying to take the high moral ground against something that has a clear open source license all the way (GPL + classpath extension).

And isn't it the case that SUN donated the initial source for tomcat to Apache back in '99.  You are starting to sound extremely ungrateful to a company that you owe a lot of heritage to.

As for community around each product -- Springsource is boasting that it has almost all the Spring committers and 80%+ of the tomcat committers.  Obviously they see this as a positive.  And suddenly it's a -ve because SUN employ the glassfish committers?

You also imply that you are some kind of grand arbiter of what constitutes an open source project.  And yet, here you are monetising an open source product that was gifted to you from the company whose legitimate open source project you are now FUDding.  Unbelievable.

I don't think I have to go into details what AL 2.0 gives you in terms of flexibility.

This is silly now.  The apache license is a good one, but you are simply avoiding the question in 2 ways: firstly, tcserver isn't under the apache license.  Your point about just dropping back to tomcat if springsource goes away is noted, but you'd then lose any of the stuff that tcserver offered.  at least with glassfish and other open systems you'd have the source at least and wouldn't be running on an opaque binary platform.  Someone could pop up and take over the Glassfish project.

And secondly, the only thing that the GPLv2+classpath exemption prevents is creating a closed-source commercial product based on it.  Are you saying that GPLv2 (linux kernel etc) + the classpath exemption isn't a good option?  GPL+ dual licensing seems good enough for the dm server?!

Oh, and we all saw what could have happened to the Spring ASL goodness when Rod and others recently attempted to restrict the visibility of fixes to 3mths on older versions.  Lovely.

And here's the kicker: until I saw this article and read your responses, I was a major SpringSource booster (and I have no ties to SUN or any other middleware company).  However, your lack of respect for legitimate competitors in your replies, your lack of respect for reasonable questions here and the recent spate of shill-like articles promoting the recent range of new SpringSource products has turned me off.  Way to go, Filip.  I'll gladly use tomcat, but i'll be damned if i'll use tcserver.

Andrew

Filip Hanik replied on Thu, 2009/01/08 - 9:34pm in response to: Andrew McVeigh

[quote=andrewm]

The article's content is great, but many of the responses from Filip are shocking.

[/quote]

We all get carried away, I've never been a big fan of these comment wars, seems you've taken to it too :)

[quote=andrewm]

 For example, does anyone know how the recent cuts in work force at Sun Microsystems will effect the Glassfish container, and would one want to bet his/her business on it?

An ad hominem attack on a competitor as soon as Ryan reasonably asks for a technical justification?  That's your position?? -- that SUN might fold and therefore they are better using tcserver?  On that basis I certainly wouldn't base my software on tcserver -- what if SpringSource folds -- i'm back to plain vanilla tomcat and left possibly with an unmanageable set of servers? 

[/quote]

No attacks, simple advice. You should always look at the stability of the company backing the product. If you read a bit further, you can see how I addressed the question about SpringSource folding, even that has been answered.

[quote=andrewm]

If the system (Glasshfish) was so intuitive, would I need training? My guess is that Sun thinks so. A free lance developer can learn plenty about Tomcat simply using free resources.

What a load of rubbish.  What use are the covalent training courses then? 

[/quote]

The only way you could find out the quality and this course ware would be to take the course. It goes above and beyond your normal technical product course. I was a developer and used Tomcat without training long before I became a committer. However the topics we teach in our classes goes beyond the XML syntax, it goes through what we have learned over the year successfully run the system itself in production.

[quote=andrewm]

Oleg now pipes up.  Another unacknowledged SpringSource/Covalent employee:

[/quote]

Way to go Andrew, welcome aboard to the thread of coziness and respect.

[quote=andrewm]

Back to Filip:

Sure you can throw out the argument that Glassfish is open source, but when you do that, you simply don't understand open source. When it comes to open source, it all is in the license, license, license.

You are exactly right -- the license is the key.  So, why is tcserver not under the ASL2.0?  Of course, it's a commercial product.  Noone cares if it's commercial -- that's your choice.  Just don't go trying to take the high moral ground against something that has a clear open source license all the way (GPL + classpath extension).

[/quote]

There is no such thing as ASL 2.0. It's already been pointed out.

tcServer provides value add above and beyond Apache Tomcat. However you are still running Apache Tomcat and switching between the to is seamless. I believe that has also been answered. However there is a big difference, let me draw an analogy.

Think of tcServer as the XM radio in your car. You car will run with or without the radio. Cancel your subscription, and the car still takes you where you need to go.  However, when you travel across the country, you might find value in the fact that the radio never stops, you never need to tune to a new channel, and so on. There is a value add here, but you don't have to trade in your car when you don't want XM.

Building on top of a JEE container, and using technologies when you don't need to, you suddenly have a car that you are forced to use. You can't cancel the XM subscription, you will pay for it if you use it, you will pay for it if you don't use it. Trading in the car can become costly, cause you've attached so many accessories you now have to replace when buying a new one. 

Hopefully that paints a clearer picture

[quote=andrewm]

And isn't it the case that SUN donated the initial source for tomcat to Apache back in '99.  You are starting to sound extremely ungrateful to a company that you owe a lot of heritage to.

[/quote]

I'm unsure where I'm ungrateful to Sun. When I point out that looking at the stability of the company  should be part of the sleection criteria. I wouldn't want to be in the company that doesn't do that evaluation when they select a product. It has nothing to do with gratefulness, simply business sense.

[quote=andrewm]

As for community around each product -- Springsource is boasting that it has almost all the Spring committers and 80%+ of the tomcat committers.  Obviously they see this as a positive.  And suddenly it's a -ve because SUN employ the glassfish committers?

[/quote]

We don't boost 80% of the committers, and have never claimed to do so. And when contributing to the ASF, you don't represent your employer, you represent yourself. Hopefully this also clarifies the difference between the two governance models and why one is better than the other.

[quote=andrewm]

You also imply that you are some kind of grand arbiter of what constitutes an open source project.  And yet, here you are monetising an open source product that was gifted to you from the company whose legitimate open source project you are now FUDding.  Unbelievable.

I don't think I have to go into details what AL 2.0 gives you in terms of flexibility.

This is silly now.  The apache license is a good one, but you are simply avoiding the question in 2 ways:

[/quote]

I already specificed that I won't go into the licenses. mainly cause I'm not a lawyer, secondly cause a company should always consider the legal effect of having source code in the house with the potential of developers changing that code, and the impact it can have on the company's IP.

[quote=andrewm]

firstly, tcserver isn't under the apache license.  Your point about just dropping back to tomcat if springsource goes away is noted, but you'd then lose any of the stuff that tcserver offered.  at least with glassfish and other open systems you'd have the source at least and wouldn't be running on an opaque binary platform.  Someone could pop up and take over the Glassfish project.

[/quote]

I'm not sure it's as easy as 'popping up and taking over the project'. That depends on the many factors we already outlined, governance model, contributor agreements and who owns controls/ the source code and the IP of it. Would you care to elaborate how someone would take over the project in question, I couldn't answer it because I'm not a lawyer and I'm not familiar with the terms.

[quote=andrewm]

And here's the kicker: until I saw this article and read your responses, I was a major SpringSource booster (and I have no ties to SUN or any other middleware company).  However, your lack of respect for legitimate competitors in your replies, your lack of respect for reasonable questions here and the recent spate of shill-like articles promoting the recent range of new SpringSource products has turned me off.  Way to go, Filip.  I'll gladly use tomcat, but i'll be damned if i'll use tcserver.

Andrew

[/quote]

And that is the main point of the article. Use something as light and simple as Apache Tomcat. I usually leads to cost savings in the long run.  And if you feel inclined to, feel free to contribute back to the project

To clarify, this has nothing to do with disrespect. I'd be the first to apologize if that is the case. I've only tried to answer the questions as clearly and directly as possible, without dancing around the x-mas tree for politeness. If I knew how to be politically correct at all times, I wouldn't be an engineer, I'd probably be more successful being a politician.

[/quote]

Ryan Developer replied on Thu, 2009/01/08 - 9:41pm in response to: Filip Hanik

[quote=fhanik]

Building on top of a JEE container, and using technologies when you don't need to, you suddenly have a car that you are forced to use. You can't cancel the XM subscription, you will pay for it if you use it, you will pay for it if you don't use it. Trading in the car can become costly, cause you've attached so many accessories you now have to replace when buying a new one. 

[/quote]

You may not believe me, but there really are many developers out there who choose to use, who want to use, Java EE technologies. JAX-WS, JAX-RS, JPA, etc. are good examples. Plus, nothing forces developers to use Java EE technologies when deploying on a Java EE application server.  They can still take advantage of its other features such as management, monitoring, scalability, high availability, etc.  GlassFish V3 recognizes that some developers won't touch an application server that comes bundled with technologies that they don't want to use and has made all of them optional.  They have created a lightweight alternative to Apache Tomcat (yes, inconceivable) that IMO happens to be simpler to manage and has more built-in functionality. Its plugins manager enables you to scale it up to a full blown Java EE application server if you want. The ever increasing adoption stats and mailing list activity proove that they are doing something right.

My guess is that tcServer == GlassFish V3 feature wise, and I think there is definitely a market for such a product from SpringSource. There are a lot of Sun haters out there, no matter what they do. And yes, tcServer offers the benefit of falling back to Apache Tomcat, assuming that the company wants to use Tomcat.

 

Chandra Sekar.S replied on Thu, 2009/01/08 - 10:14pm

Ok guys.  This is just a marketing post.  Tomcat no doubt is light and sweet for development.  But needs another framework for even simple things like managed transactions.  I guess Filip thought if Tomcat gets pushed people would choose and depend on Spring for even simple things like transaction management.

 We all know Glassfish v3 offers all we need (there is no app without ORM and managed transactions), without forcing to pick a third party framework.  So let Filip continue his FUDing of glassfish, let us enjoy using Glassfish and getting our job done faster.

Filip Hanik replied on Thu, 2009/01/08 - 10:36pm in response to: Ryan Developer

[quote=rdelaplante]

You may not believe me, but there really are many developers out there who choose to use, who want to use, Java EE technologies. JAX-WS, JAX-RS, JPA, etc. are good examples. Plus, nothing forces developers to use Java EE technologies when deploying on a Java EE application server.  They can still take advantage of its other features such as management, monitoring, scalability, high availability, etc. 

[/quote]

You are absolutely right. One should always use the right technology for the right job.

[quote=rdelaplante]

GlassFish V3 recognizes that some developers won't touch an application server that comes bundled with technologies that they don't want to use and has made all of them optional.  They have created a lightweight alternative to Apache Tomcat (yes, inconceivable)

[/quote]

Not at all inconceivable. Many other products, like Weblogic Express, or Apache Geronimo, recognized this years ago, way before Glassfish v3 was even in the works. It's not a hard to understand concept once you understand it. But it is an important concept, and not understanding it can have long term consequences.

Apache Geronimo has the exact pick and choose technology assembly, and that has always been the goal of that project. It's been around for a while now.

[quote=rdelaplante]

My guess is that tcServer == GlassFish V3 feature wise, and I think there is definitely a market for such a product from SpringSource. There are a lot of Sun haters out there, no matter what they do. And yes, tcServer offers the benefit of falling back to Apache Tomcat, assuming that the company wants to use Tomcat.

[/quote]

Glassfish v3 is an acknowledgement that there is a market for more light weight containers. I do believe light weight, less complex containers will become a focus for the next year or so.

Filip Hanik replied on Thu, 2009/01/08 - 10:46pm in response to: Chandra Sekar.S

[quote=chandru.in]

Ok guys.  This is just a marketing post.  Tomcat no doubt is light and sweet for development. 

[/quote]

That's the trap many companies fell into many years ago. Let's use Tomcat for development, but we need a real application server for production. I think we can safely say that myth has been buried long time ago.

[quote=chandru.in]

But needs another framework for even simple things like managed transactions.  I guess Filip thought if Tomcat gets pushed people would choose and depend on Spring for even simple things like transaction management.

[/quote]

Spring doesn't do managed transactions, in other terms, it doesnt implement a transaction manager like JTA, your statement is factually incorrect. Knowing what a technology does is a key factor to a wise technology choice.

[quote=chandru.in]

 We all know Glassfish v3 offers all we need (there is no app without ORM and managed transactions), without forcing to pick a third party framework.  So let Filip continue his FUDing of glassfish, let us enjoy using Glassfish and getting our job done faster.

[/quote]

Use the technology that is best of the job. Be it tcServer, Apache Tomcat or even a full blown JEE server. What I'm merely pointing out, is that there are many ways to go from A to B, choose the simplest, most efficient and most cost effective one.

Chandra Sekar.S replied on Thu, 2009/01/08 - 11:42pm in response to: Filip Hanik

[quote=fhanik]That's the trap many companies fell into many years ago. Let's use Tomcat for development, but we need a real application server for production. I think we can safely say that myth has been buried long time ago.[/quote]

No it still is the fact.  See my last point.

[quote=fhanik]Spring doesn't do managed transactions, in other terms, it doesnt implement a transaction manager like JTA, your statement is factually incorrect. Knowing what a technology does is a key factor to a wise technology choice.[/quote]

It does do transactions with AOP.  AOP is the only reason anyone would want to choose spring.

[quote=fhanik]Use the technology that is best of the job. Be it tcServer, Apache Tomcat or even a full blown JEE server. What I'm merely pointing out, is that there are many ways to go from A to B, choose the simplest, most efficient and most cost effective one.[/quote]

Except for simple JSP, Servlet apps using direct JDBC, there are very few apps which can be run on Tomcat without bundling loads of JARs.  If I was using a more capable server (like Glassfish 3), I don't have to bundler dozens of JARs even for simple apps.  Tell me one non-trivial app which doesn't need ORM, transactions and an MVC web framework.  All these are provided by Glassfish 3.  Can you tell one of them which is provided by Tomcat without bundling more and more JARs into my WAR?

Oleg Zhurakousky replied on Fri, 2009/01/09 - 1:54am in response to: Andrew McVeigh

Andrew says:
Oleg now pipes up. Another unacknowledged SpringSource/Covalent employee:

Well, you've acknowledged me. . . so, Thank you!
But for crying out loud Andrew. . . as far as that particular comment goes. . . you seem to be a reasonable man and must agree that OSGi is giving us a new development, deployment and most importantly thinking model where Application server (JEE or other) can now be treated as just a library amongst other enterprise libraries and services allowing us to build much more robust and dynamic applications. . . form which we will all benefit. But as I said. . . it's a different discussion. . .

Jay Spring replied on Fri, 2009/01/09 - 4:37am

eh...is this turning into theserverside.com?

 

...and what's with this story? Developers don't talk to each other on your teams? They develop in isolation? A week goes by and the tech lead or architect never followed up or had a conversation with the developer during this period? OUCH

"I'll never forget the day a developer in my team was tasked to provide a utility class to easily send an email with an attachment. A week later, about 4 more days than anyone had anticipated for the task, we received an Enterprise Archive (EAR) containing the solution."

 

Andrew McVeigh replied on Fri, 2009/01/09 - 4:32am in response to: Oleg Zhurakousky

But for crying out loud Andrew. . . as far as that particular comment goes. . . you seem to be a reasonable man and must agree that OSGi is giving us a new development, deployment and most importantly thinking model 

Sure, seems like a reasonable enough thing to agree to.  If there's one word of advice I'd give, it's just this: simply put in a .sig or something that identifies you as a SpringSource employee.  The reason myself and others are so hung up on this point is to avoid the past horrible situation with JBoss astroturfing.

As for being a reasonable person: not really.  Particularly at 1am in the morning after a 14 hr programming day.  However, the comments I've read made me livid.

Andrew 

Andrew McVeigh replied on Fri, 2009/01/09 - 5:04am in response to: Filip Hanik

We don't boost 80% of the committers, and have never claimed to do so. And when contributing to the ASF, you don't represent your employer, you represent yourself. Hopefully this also clarifies the difference between the two governance models and why one is better than the other.

Actually, that's technically true. You just claim to represent more than 80% of the commits. Different statistic perhap, but the intent is the same. Even though you indicate that your ASF and SpringSource work are not really tied, clearly SpringSource marketing sees a benefit in tying them together.

From the marketing literature at http://www.springsource.com/node/897

Over 80% of Tomcat commits in the last two years were made by SpringSource employees and with our leading Tomcat committers, SpringSource can rapidly address support incidents and commit bug fixes to Tomcat

You could do with a level of self-reflection on the following comment:

No attacks, simple advice

Let me put it into context. You've implied that there is a likelihood of SUN going bankrupt (in an attempt to show that people are better off using tcserver and tomcat), that Glassfish isn't really an open source project, that people who claim that it is "simply don't understand open soure". You've claimed that SUN's training is not very good and that Glassfish is very hard to use and install. These may not have been your intentions, but that's how I read a lot of your stuff. Others did also.

Building on top of a JEE container, and using technologies when you don't need to, you suddenly have a car that you are forced to use

Not really, and that's where the analogy breaks down perhaps. It's always been good practice to stick with a JEE subset that you feel you feel comfortable with. In fact, I've alway been a huge fan of just using the jsp server part or in fact just using Spring with the best parts of the container. I understand how the tcserver/tomcat programming model works -- you don't bind your code to anything that is proprietary, and in that sense I see it is different to the JEE model. However, if tcserver suddenly disappears, you are left without its benefits which presumably means that you might be left with an unmanageable set of tomcat servers.

There is no such thing as ASL 2.0. It's already been pointed out.

Huh? http://www.apache.org/licenses
Are you simply being pedantic because I used the word ASL instead of "Apache License". You knew what I meant. Perhaps a more straighforward way to reply would be to address the issue and then say by the way "it's Apache License, not ASL".

Would you care to elaborate how someone would take over the project in question, I couldn't answer it because I'm not a lawyer and I'm not familiar with the terms.

With Glassfish, you simply copy the codebase under the GPLv2 + exemption license and call it something other than the trademarked name. Sure, you can never then create commercial extensions to the server, but AFAIK there's no legal issues involved. In fact someone could do this now.

And that is the main point of the article. Use something as light and simple as Apache Tomcat.

So you've got notionally a great story based around the above line. "Use tomcat, here's our commercial value add for enterprises, you'll never be locked in or bound to proprietary interfaces". I've always been a strong advocate of tomcat in production; it's an accepted model now. You've got (presumably if its the same as the other spring stuff) an excellent technical product. You offer commercial support, you give back to the community.

The tragedy is that you've managed to present this in a way where by straying from the message you've managed to embroil yourself in an unpleasant and offtopic (to you at least) discussion. Perhaps part of the problem is presentational. For instance, when you specifically mention SUN going broke, it looks like you are implying they might. However what you were presumably trying to say was "don't tie yourself to something that might disappear. Here's a better way using tomcat..." That's not how it came across initially to me and others.

If I knew how to be politically correct at all times, I...

Well, yeah. I can certainly apply this to myself also ;-)

Andrew

p.s. Just as an aside, when I was younger and dealing with a lot of IBM salespeople, I was sincerely and profoundly impressed by the fact that they seemed to have a code of ethics which included not specifically badmouthing competitors. Sure, IBM has many other bad qualities and I'm no fan of their s/w in the main, but they were able to differentiate themselves without mentioning specifics or speculating about the health or otherwise of other companies. Very impressive at the time.

p.p.s. please, please put something in your .sig about being a SpringSource employee if its relevant to your posting. It prevents me and others from getting uppity about lack of disclosure, which is a massive hangup we have perhaps from the old JBoss days of astroturfing. And if you think I'm picking on you or springsource, just have a look at many of my previous comments over the years to this forum.

 

Filip Hanik replied on Fri, 2009/01/09 - 10:58am in response to: Andrew McVeigh

[quote=andrewm]

We don't boost 80% of the committers, and have never claimed to do so. And when contributing to the ASF, you don't represent your employer, you represent yourself. Hopefully this also clarifies the difference between the two governance models and why one is better than the other.

Actually, that's technically true. You just claim to represent more than 80% of the commits. Different statistic perhap,

[/quote]

Very different statistic. I do believe it is important to present the facts, and that is why I corrected you. If I falsely claim something please let me know. I wont try to spin it in a different direction, I'll simply say I was wrong.

Even though I'm not familiar with the term 'technically true', and I hope I never hear that from my kids when I ask them if they still are not doing drugs, committers vs commits makes a huge difference.

[quote=andrewm]

No attacks, simple advice

Let me put it into context. You've implied that there is a likelihood of SUN going bankrupt (in an attempt to show that people are better off using tcserver and tomcat), that Glassfish isn't really an open source project, that people who claim that it is "simply don't understand open soure". You've claimed that SUN's training is not very good and that Glassfish is very hard to use and install.

[/quote]

I once was with a company using Peoplesoft for their financial system. The executives had selected that software through a vendor evaluation including Oracle and SAP. Today they are an Oracle customer. That is a fact and that is reality.

What I'm trying to get across is that vendor evaluation should be part of the criteria. If you feel like that is criticizing Sun then let me back up and say that's not the case and is not the point. The point is take a look at it with an objective eye, maybe even use your own jugement but lets not pretend that the possibilities don't exist. (You know I can't stop throwing gas on the fire :). Of course, my way of presenting it seems to have been less than optimal and I'd like to thank you for pointing that out.

[quote=andrewm]

 

And that is the main point of the article. Use something as light and simple as Apache Tomcat.

So you've got notionally a great story based around the above line. "Use tomcat, here's our commercial value add for enterprises, you'll never be locked in or bound to proprietary interfaces". I've always been a strong advocate of tomcat in production; it's an accepted model now. You've got (presumably if its the same as the other spring stuff) an excellent technical product. You offer commercial support, you give back to the community.

The tragedy is that you've managed to present this in a way where by straying from the message you've managed to embroil yourself in an unpleasant and offtopic (to you at least) discussion.

[/quote]

And this is very unfortunate nevertheless life and blogs are always an interesting learning experience and an opportunity to improve. And apparently, to occassionally get into a cat fight.

Peter Huber replied on Fri, 2009/01/09 - 11:40am

Well a rather lengthy article about tomcat and tcServer. It's pretty amazing that spring was able to build a OSGi-fied tomcat and that tomcat is such a great software. But wait a minute! This might have two reasons that it was so easy for spring.

1.) It was done before - There have been allready tomcat OSGi-bundles out there. By the way there are even other OSGi-Runtimes like knopplerfish. 

2.) Since tomcat 5 it's rather easy (compared to tomcat 4 -> http://www.gefionsoftware.com/LiteWebServer/) to have a tomcat embedded into another process like an OSGi Container. Its even rather easy to expose an api which alows other bundles to deploy webapps (I have done that). Seems like the tomcat guys have delivered...and spring just absorbs another thing. Persistence is futile, ah no, We are spring, resistance is futile! you will be part of spring-collective... 

Peter

 

Filip Hanik replied on Fri, 2009/01/09 - 5:28pm in response to: Peter Huber

[quote=peterhuber]

Well a rather lengthy article about tomcat and tcServer. It's pretty amazing that spring was able to build a OSGi-fied tomcat and that tomcat is such a great software. But wait a minute! This might have two reasons that it was so easy for spring.

[/quote]

It's an interesting comment, but the article doesn't mention the word OSGi a single time. But you are right, resistance is futile :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.