Caucho Technology, the vendor behind the Resin application server, have become a licensee of J2EE. Steve Montal, Director of Sales and Strategic Partnerships at Caucho Technology said, "Resin and the J2EE platform provide a framework for developing and deploying web services. We are delighted to become a Sun Microsystems J2EE licensee."

Montal added, "We look forward to offering valuable J2EE features to our customers and giving them faster web services solutions which allows them to focus on their businesses."

"Sun applauds Caucho's decision to license J2EE technology," said Mark Bauhaus, Vice President of Java Web Services at Sun Microsystems. "Caucho Technology's customers will gain valuable assurance that Resin application server adheres to the J2EE standard by passing nearly 25,000 rigorous tests for compatibility," he added.

Read more: Caucho becomes latest J2EE licensee

that is really great news. In the past, I encountered difficulty taking a war file and deploying it on Resin when the app used JSTL. I never got around to tracking down the cause, but regardless Resin is a solid container.

Congratulations to Caucho! I haven't used the non-Servlet aspects of Resin, but I can attest to the smoothness of the Servlet / JSP functionality.

I first ran into Resin when I was visiting Salesforce.com ('99?) and they were running it (many servers) and were extremely happy with it.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

I deployed Resin on 6 servers for Ziff Davis for 10K concurent users. It used to be ASP :-)
(Check netcraft for 1up.com )

Very nice. Tomcat 5.5 is nice. (and the only other one I like is Orion)
But now I use Caucho Hessian.... a LOT. I find other SoA not up to speed.
.V

Agree Resin does rock !

I deployed Resin on 6 servers for Ziff Davis for 10K concurent users. speed..V

Can u translate 10K concurrent users to a number of pages/s for the site that u mentioned ?

Thx-Claude

Claude,
No :-(. This was 6 months ago.

I'd have to dig arround for the code. We have JaMon (open source) monitoring. The slow part was Laszlo and DB access, not pages, that is so .... 80's. (During Stress test -OpenSta - the botleneck was the 1Gb LAN Nic). Any scalability was prety flat, we just add another Resin box. I allways user concurent.
hth,
.V

Does this means Resin is now a full blown EJB container?

peter

FYI:

http://www.webperformanceinc.com/library/ServletReport/

For those of you who haven't seen this.

Bill

FYI:http://www.webperformanceinc.com/library/ServletReport/For those of you who haven't seen this.Bill

Tomcat holds pretty well considered that it is allegedly poorly written: http://www.sdtimes.com/cols/javawatch.htm

The [Tomcat] code is a mess. It’s poorly structured, poorly documented and poorly written. ... Some other open-source source code that I’ve seen is equally bad — Hibernate is a mess, for example—and many commercial projects aren’t much better. ... The bottom line is that you have to do a lot of work to use an open-source product like Tomcat.

I'm definitely no expert compared to Remy, Costin, Filip, Mladen, Yoav, and all the other active developers, but I'm gonna say the author of the article is full of it. Comparing the code in Tomcat to the proprietary code I've seen, the quality of Tomcat is atleast 10x better. By no means is the code perfect and there plenty of stuff that could use some cleaning, but it's solid code.

Remy has gone through the code systematically to clean things up, profile and optimize it. Although there's a lot of docs on Tomcat, it definitely could use some editing by a professional tech writer. Sometimes I have trouble finding stuff and I'm not a newbie to tomcat. for a new user, it is a bit daunting, but there aren't any technical writers that are developers. I tried to help by writing an article on tomcat, but some people will never be satisfied. oh well.

peter

Tomcat code inside is bit bloated,but its structured. The bloating part is the Standard Wrapper-Valve pipeline components.Tomcat has an excellent module oriented packaging too.The notable part is probably that Tomcat 5 has changed a lot,its better than the previous ones

Regards
Surajeet

Tomcat code inside is bit bloated,but its structured. The bloating part is the Standard Wrapper-Valve pipeline components.Tomcat has an excellent module oriented packaging too.The notable part is probably that Tomcat 5 has changed a lot,its better than the previous onesRegardsSurajeet

Tomcat 4 is well structured, but tomacat 5 ...
Tomcat 5 is a mess because they took tomcat 4 and tried to optimize it (actually they did it very well). They added a lot of things which just don't match tomcat 4 structure. Don't know tomcat 5.5 code, but tomcat 5.0.25 was a nightmare. Lot's of reflection calls (think they didn't like interfaces), 0 comments inside.

Tomcat code inside is bit bloated,but its structured. The bloating part is the Standard Wrapper-Valve pipeline components.Tomcat has an excellent module oriented packaging too.The notable part is probably that Tomcat 5 has changed a lot,its better than the previous onesRegardsSurajeet

Tomcat 4 is well structured, but tomacat 5 ...Tomcat 5 is a mess because they took tomcat 4 and tried to optimize it (actually they did it very well). They added a lot of things which just don't match tomcat 4 structure. Don't know tomcat 5.5 code, but tomcat 5.0.25 was a nightmare. Lot's of reflection calls (think they didn't like interfaces), 0 comments inside.

If you followed the development of tomcat from pre TC4 days to the current code base, you'd realize TC4 had a ton of wrappers and interfaces. The end result was a trade off in speed. All of this can be verified by reading a couple years of archives on tomcat-dev. The process of cleaning up those extra wrappers and interfaces is necessary and it's expected that the transition phase will look messy. Is there any other way around that? I believe the tomcat developers take quality of the code seriously, so it's just a matter of time. If one were to compare the code base from JServe all the way to TC5, you'd see how much the code has changed.

Also, keep in mind TC5 added support for lots of new things required by the spec, so once that stuff matures a bit, the code will get cleaned up. TC4 didn't include things like file tags or built in expression language. I followed that development fairly close and you'd be surprised at how hard it was to implement. I still only understand a small portion of what was added in TC5 to meet the spec. I think the key here is to compare TC5 to other compliant containers to get a clearer idea.

Now that Resin is certified and it's open source, there's another high quality container to use and compare against. I've been meaning to do a comparison for myself, but just can't find the time to do it.

Tomcat code inside is I believe the tomcat developers take quality of the code seriously, so it's just a matter of time.

 No doubts. As you mentioned,it is beyond doubt that getting a product certified has tradeoffs too..Just another trade-off..but the trade-off compromised is "quality ".

Regards
Surajeet

I think in many cases that is a real trade off, but in other cases, I think it can help make quality better. Alot of anti Java people claim "things move to slowly." given that implementing a spec is hard work, it's good to have sometime in between spec revisions to allow for the previous one to mature a bit. Otherwise, if new specs came out every year and a half, it would be impossible to insure the quality didn't go down like the titanic.

peter

"Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design"

and he said you have to do a lot of work to use Tomcat?

I tell you, there are charltans amongst us.


.V

I've used Resin for the past 3 years. It is great for basic servlet/jsp work but can be frustrating if you want to do something more complex. Trying to get an EAR working in Resin-EE was just painful. My biggest problem with Resin is their need to reinvent the wheel too frequently. For example, they have their own XML infrastructure rather than just using Xerces/Xalan and it's buggier than the Apache XML projects.

Hopefully this is a sign of better J2EE compatability to come.

... My biggest problem with Resin is their need to reinvent the wheel too frequently. For example, they have their own XML infrastructure rather than just using Xerces/Xalan and it's buggier than the Apache XML projects...

My experience if the opposite: thanks to the integrated XSL/XML we could live to the xerces-in-JDK problem (which forced many people to update the global Xerces for all apps) and also found it quite robust.
On the opposite sometimes it's soooo easy to use built-in objects (filters, servlets, OTF XSLT etc...) that you might find yourself with a Resin-only application

would u direct me on how this is at all done?
erezh at magicsoftware dot com

:-) 10x