tag:blogger.com,1999:blog-15929719.post6388351301391115884..comments2023-10-21T01:56:53.775-07:00Comments on Van Couvering Is Not a Verb: From chaos to Glassfish v2: you've come a long way babyAnonymoushttp://www.blogger.com/profile/04898259486137280102noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-15929719.post-79682947540529581512007-09-18T19:26:00.000-07:002007-09-18T19:26:00.000-07:00David, nice post. You prompted me to do my own bra...David, nice post. You prompted me to do my own brain dump on the history of Applications Servers at Sun.<BR/><BR/>http://blogs.sun.com/page/sharps?anchor=fish_genealogyAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-15929719.post-27145185441617316102007-09-18T18:10:00.000-07:002007-09-18T18:10:00.000-07:00ISP deployment without some kind of JVM support I ...ISP deployment without some kind of JVM support I think would be spectacularly difficult.<BR/><BR/>For casual applications, it may not be such a big issue. Basically for WARs of minimal to medium complexity.<BR/><BR/>Perhaps even with the future Java Module API, there's some hope.<BR/><BR/>But when applications get complicated, when they start fighting over XML implementations, then the app servers become the bastion of "Classloader Hell". In some applications its difficult enough to get it running alone within a container that you have full control over.<BR/><BR/>Then you have general QOS and SLA functionality. The major app servers are more designed "friendly" applications. But throw in some poor souls latest alpha release laced with endless loops and memory leaks, and any other application deployed within that container is going to be having a bad day. <BR/><BR/>Heck, in theory, you can't even kill a thread that's in an endless loop in a JVM. So, any badly behaved application can potentially force a container restart.<BR/><BR/>I think that modern hardware specs and VM services (Zones, zen, VMWare) are going to outpace any work done at the JVM level to give the kind of control a public host provider would most likely enjoy.<BR/><BR/>GF v3 and JEE6 are just going to blur the lines that we know today of what an app server is.<BR/><BR/>When you have a system that you can toss a generic WAR with a bundled Session Bean, and can load services on the fly, we'll have a very nice lightweight option over what we have now with GF. No EAR, no descriptors, just some annotated bean soup.<BR/><BR/>That'll be nice.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15929719.post-3728493150727342132007-09-18T15:35:00.000-07:002007-09-18T15:35:00.000-07:00Hi, Anjan. Great feedback!Convincing someone to s...Hi, Anjan. Great feedback!<BR/><BR/>Convincing someone to switch is a personal experience -- it depends upon your requirements. I would say you should identify the key requirements of your system - be it a particular feature, performance, support costs, long-term viabaility of the company behind the product, and so on. Then do side-by-side comparisons and testing and decide if it's worth the effort to switch.<BR/><BR/>Also, there is a <A HREF="http://java.sun.com/j2ee/tools/migration/index.html" REL="nofollow"> migration tool</A>, <A HREF="http://www.sun.com/software/products/appsrvr/migration/" REL="nofollow"> guides and people ready to help</A> with your migration if you choose to do it :)<BR/><BR/>In terms of a "Glasffish-lite" - it's not exactly what you're looking for, but you might take a look at the incredibly light-weight (152K footprint), super-high-performance (uses NIO networking) HTTP server from the <A HREF="https://grizzly.dev.java.net/" REL="nofollow"> Grizzly project</A>, which also acts as the HTTP kernel for Glassfish. No, it doesn't include clustering - I know what you're looking for -- please rip out all the Java EE stuff -- and I don't know if there's something there.<BR/><BR/>I do know that v3 <A HREF="http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-6503&yr=2007&track=8" REL="nofollow"> is based on a very modular architecture</A>, and one could potentially create a configuration like the one you speak of. Have you asked the <A HREF="users-subscribe@dev.glassfish.net" REL="nofollow">glassfish user alias</A> about this?<BR/><BR/>Very interesting comment about ISPs. Not being on the team, I really don't know what they're doing around that.<BR/><BR/>DavidAnonymoushttps://www.blogger.com/profile/04898259486137280102noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-28250460615052313482007-09-18T13:45:00.000-07:002007-09-18T13:45:00.000-07:00hi there, good to know the history bits. The que...hi there,<BR/><BR/> good to know the history bits.<BR/><BR/> The question for Sun and the community to ask is : <BR/>"Good to know that Glassfish v2 works and has good functionality.<BR/>BUT...... Since I'm already using a) Tomcat OR b)JBoss, what does Glassfish have that will make me replace the current appserver ?<BR/><BR/>I know that Glassfish has many features that the mentioned appservers don't have. It will take a lot of effort from Sun to convince the community that a ONE-SIZE-FITS-ALL will work for them.<BR/><BR/>I'm thinking that Glassfish v3.x should come up with a Glassfish Lite version which is only a servlet/JSP container PLUS the HA/Cluster feature.<BR/><BR/>Without the Lite version, many customers will sneer at the 50MB download size.<BR/><BR/>It'll be interesting to see how soon SUN can get ISPs to offer hosting services based on Glassfish. That will be the crucial step that Sun needs to do : make it easy to deploy/host java apps! That has been the BIGGEST FAILURE from sun all along.<BR/><BR/>BR,<BR/>~AAnonymousnoreply@blogger.com