Slashdot Mirror

There is a very nice open-source webserver called Enhydra that really is impressive, however it sort of fell by the way side in the stampede to EJB-compliancy, too bad, although there are a bunch of commercial sites using the software.

As for JBoss, it seems the news is always a bit muddled, i.e. what's with the "fork" and all that? If it's so great, why do they have to have their employees write in at TSS? I'd be much more impressed, if they just wrote in as employees - show yourself, fools!

For that matter, I've always wondered about Slashdot - seems whenever there's an MSFT post, there are hordes of folks writing in vehemently defensive of MSFT - very suspicious in a tell-tale heart sort of way.

Or take the reviews on Amazon that come of so polished. As soon as I read something like "In chapter 12 the book really shines at ...", I skip to the next review. Or like the recent voting on one of those music reality tv shows, star search or what not, where the whole state of Hawaii was busily dialing in to vote for the home-town girl.

Whatever. I think we'll see a movement towards blogs, where I only want to see what James Duncan Davidson has to say (those pictures are great!), the heck with everyone else.

Enhydra, an Open Source Java-based Application Server, was recently installed on an XBox using Xebian.

I had submitted a story about this the day it happened (a few days ago) but for some reason it didn't make the cut. I guess underpowered web servers are sexier than underpowered application servers..(?)

Enhydra, an Open Source Java-based Application Server, was recently installed on an XBox using Xebian.

I had submitted a story about this the day it happened (a few days ago) but it didn't make the cut.

About a month ago I completed a J2ME training class. We used the Motorola i730 throught the Nextel network. We were able to write a couple of small apps that accessed the GPS network and send the phones location via kXML to a Servlet running half way across the country.

Nextel is very protective of their network, so you do have to jump through hoops to get permission to load apps onto phones "connected" to their network.

Interestingly, none of these "migration articles" on web sites that are explicitly devoted to CMS matters (e.g., CMSwatch.com, cmsReview.com) seem to characterize this problem as relating to Extraction, Transformation, and Loading (ETL), raising the possibility that their authors are ignorant of the many ETL tools that are available. In the open source world, these tools include Octopus and Jetstream. Of course, Perl programmers do not call this process "ETL," but, rather, simply "data munging."

A prior Slashdot story on "Transferring data 'tween databases" (posted 14 April 2003) might interest you. I cannot post a link to it, however, because Slashdot's search engine is currently down.

Finally, EMC just bought Documentum, the CMS that you are considering. EMC is primarily a storage company, and I cannot help but wonder how CMS fits into their storage strategy.

That's what they say:

The GNU license (GPL) has its roots before modern Object Oriented languages became popular. It is viral in nature since it affects all code that extends or uses it. It is not entirely clear about where to draw the lines as to where external software gets "infected" by GPL's viral nature. In fact, one could easily argue that with Java, where everything is a library (class), any code that includes a GNU component must convert into GPL. [my emphasis]

The Enhydra Application Server provides an environment for application code to be loaded and executed, thus extending the original functionality of the base server. This is the primary way of developing systems built with Enhydra, and one might say that providing such an environment is the primary purpose of an Application Server. This is thus clearly incompatible with the GPL license since all the code that you might develop must also become GPL.

The LGPL takes the GPL license a step in the right direction by addressing libraries and clarifying that code that uses a library can carry any license, while code that modifies the library itself is subject to the LGPL license. We don't feel that we can use it because the Enhydra Server is not by any definition a library, but is a server or platform designed to call other code. Although LGPL has been used in Open Source Java initiatives, we believe that it still suffers from GPLs ambiguities for Java and we don't ever want to have to change our license again!

That's one of the reasons I use Enhydra
That and a few other tools makes my job easier.

You should check it out, it's open source.

Enhydra for the Java set is good, or Ariadne for the PHP crowd is decent. For those doing a shopping-cart Interchange or osCommerce is nice. If one's running a RPM distribution get cpan2rpm as well.

XMLC and Barracuda offer a nice alternative to Struts without all the crap of JSP and the enormous clusterf**k single XML file that Struts uses.

XMLC enforces a nice clean seperation of code and presentation data and has a great framework (Barracuda) that does everything Struts does and more. (polymorphic event dispatch and real OO event handling, for example)

Check it out at www.enhydra.org. There's also a great book out on XMLC, if you prefer paper.

The main difference in these frameworks is how you handle the html. Struts is JSP focused, Barracuda uses XMLC and Tapestry uses HTML with extra tags, Webwork and Turbine use Velocity as a first choice and can use JSP.

I use Struts a lot now. The community is very active and helpful. There is more documentation available and with a lot of the development is by Sun insiders so I expect it to be around for a while. Unlike some, I see the JSP focus as an advantage in that it can easily include other tag libraries.

That said, I'd like to see people post advantages to other approaches. Not "Struts sucks, use XYZ!" but "XYZ is better when your site uses ABC and needs to DEF".

Struts is but one presentation framework. A discussion comparing Struts and other frameworks is informative, and, indeed, there is an entire website devoted to such a comparison. For Struts links, try the home page of Ted Husted, the lead Struts developer.

Write a FAQ like every other open source project in the world

"Yuh huh... trying ripping off a websphere license or two and see how the great linux savior IBM will react.

The point that slashdotters tend to miss is that for 80%+ of the market the Microsoft middleware is more that good enough and is a damn sight cheaper than the *nix competition.
"

Take a look at enhydra. It doesn't matter if it isn't as scalable, useable, etc. as Websphere or BEA today (or even if it is). The point is that the same mechanics that worked for Apache is working in the application server market and will continue to work in all other markets as soon as you have also-rans or interested outsiders (Bull Software and France Telecom in Enhydra's case) willing to pour in resources to provide a free alternative.

DB

So Enhydra may have other intellectual property problems.

As noted in the original story, the old version (perhaps a link to http://enhydra.enhydra.org/ would have been more appropriate) is still free. This license perpetuates itself in the code:

3.1. Application of License.
The Modifications which You create or to which You contribute are governed by the terms of this License, including without limitation Section 2.2. The Source Code version of Covered Code may be distributed only under the terms of this License or a future version of this License released under Section 6.1, and You must include a copy of this License with every copy of the Source Code You distribute. You may not offer or impose any terms on any Source Code version that alters or restricts the applicable version of this License or the recipients' rights hereunder. However, You may include an additional document offering the additional rights described in Section 3.5.

So they let you know that this source must remain under this license, and that any derivatives must carry it, and that they can revise the license at any time (for future versions of the code). They even said that they could do that to you, but you went and spent time and effort on it anyway.

The only thing really keeping anyone from basically ignoring this license is the following paragraph:

3.7. Larger Works. You may create a Larger Work by combining Covered Code with other code not governed by the terms of this License and distribute the Larger Work as a single product. In such a case, You must make sure the requirements of this License are fulfilled for the Covered Code.

As long as you keep code compartmentalized, you only have to keep *their* code (or any code which has been submitted to them) with this license agreement.

Anyway, what all this boils down to is that they gave all the rights you could ever ask for, but that includes their right to take it back. They could also revise the license in future versions to say "From this point on, all code is the exclusive property of Lutris, and will be closed for all of eternity, and used by us as we laugh and spit in your face." Because they reserve the right to revise the license at any time, this is what you asked for, and what you got. Oh sure, at the time they change it, you can fork the existing code under the old license, because they said you could continue to use the old one, but that doesn't change the fact that they can (and apparently will) railroad your code at a moment's notice. Your code is after all required to carry their license now that it's a part of their project, and submitted back to them.

So while closing it might be sleazy, it's completely legal, within their rights, and you all should have expected it. Corporations don't have souls, or morality. Sometimes its members do, but it's rare that the people with morals (or at least those willing to exercise them) are the people in power.

Put another, blunter way; If you grease yourself up and bend over, someone will f*ck you.

As noted in the original story, the old version (perhaps a link to http://enhydra.enhydra.org/ would have been more appropriate) is still free. This license perpetuates itself in the code:

3.1. Application of License.
The Modifications which You create or to which You contribute are governed by the terms of this License, including without limitation Section 2.2. The Source Code version of Covered Code may be distributed only under the terms of this License or a future version of this License released under Section 6.1, and You must include a copy of this License with every copy of the Source Code You distribute. You may not offer or impose any terms on any Source Code version that alters or restricts the applicable version of this License or the recipients' rights hereunder. However, You may include an additional document offering the additional rights described in Section 3.5.

So they let you know that this source must remain under this license, and that any derivatives must carry it, and that they can revise the license at any time (for future versions of the code). They even said that they could do that to you, but you went and spent time and effort on it anyway.

The only thing really keeping anyone from basically ignoring this license is the following paragraph:

3.7. Larger Works. You may create a Larger Work by combining Covered Code with other code not governed by the terms of this License and distribute the Larger Work as a single product. In such a case, You must make sure the requirements of this License are fulfilled for the Covered Code.

As long as you keep code compartmentalized, you only have to keep *their* code (or any code which has been submitted to them) with this license agreement.

Anyway, what all this boils down to is that they gave all the rights you could ever ask for, but that includes their right to take it back. They could also revise the license in future versions to say "From this point on, all code is the exclusive property of Lutris, and will be closed for all of eternity, and used by us as we laugh and spit in your face." Because they reserve the right to revise the license at any time, this is what you asked for, and what you got. Oh sure, at the time they change it, you can fork the existing code under the old license, because they said you could continue to use the old one, but that doesn't change the fact that they can (and apparently will) railroad your code at a moment's notice. Your code is after all required to carry their license now that it's a part of their project, and submitted back to them.

So while closing it might be sleazy, it's completely legal, within their rights, and you all should have expected it. Corporations don't have souls, or morality. Sometimes its members do, but it's rare that the people with morals (or at least those willing to exercise them) are the people in power.

Put another, blunter way; If you grease yourself up and bend over, someone will f*ck you.

One quote from one of the emails:

- 2) Over the past year, several of us received explicit permission from Lutris to use InstantDB without payment. We have proceeded on that assurance. I don't believe Lutris can unilaterally and arbitrarily rescind that. Nor do I think Lutris can limit that approval to those to whom it was explicitly extended.

Uh, can we get a lawyer in here? If I'm not completely insane, it sounds like *any* venture that was operating under the understanding that InstantDB would be available free of charge could absolutely sue Lutris for the cost of migration? I imagine that this will not happen, just because the cost of migration will probably be a lot less than the cost of legal action. Isn't Lutris responsible for these sorts of assurances? Hell, is there a case for fraud?

I realize that the answer to all of these questions might be "no" but I don't see why.

Remember MySQL's old documentation, where it poo-pooh'ed the whole concept of transactions, which they didn't implement at the time? That which they couldn't or wouldn't implement, they trashed with FUD. I read something similar from Lutris in their "making waves" column that basically trashes J2EE for being, from what I can decipher from the article, an overall platform name and version for several technologies. The gist seems to be that the name J2EE has so much marketing power that you can no longer use the single pieces of it you need in your application and discard the rest, simply because in order to be branded J2EE, you have to (gasp) comply with the spec. And of course, since the spec is versioned, then well, the little guys can't keep up, so this is Sun's ploy to squeeze them out.

I suppose this confusion is normal when his application happens to be a J2EE app server, but it's utterly absurd and wrong to say that an application running on a J2EE app server is somehow forced into a monolithic API. It sounds like Lutris is just facing the fact that they started with an app server that was not J2EE then went on a crash program to make it so, and are running into a shortage of manpower. So to compensate, they are including the code from Sun's own J2EE reference implementation.

No, I'm not a fan of Sun's closed and expensive testing process, but Lutris's argument isn't about that, and it simply doesn't hold any water. Lutris is using Sun's code, not just their specs, and they are griping that they can't sublicense it however they wish. They might have been better off pulling a Zope instead, and just building on their existing app server and damn the J*-acronyms from Sun. Enhydra was damn functional, but as far as front-ends go, they have a lot of catching up to do with Zope.

Check out JOnAS, which serves as the core for Enhydra. Both are functional, real-world application servers.

Check out Exolab, consisting of OpenEJB, OpenJMS, OpenORB, and more. Again, this is another open-source application server.

For web services, check out Apache SOAP. The wonderful folks at IBM have gifted the open source community with a SOAP/WSDL/UDDI implementation. There was some talk a while back about JBoss integrating Apache SOAP into its offerings, although the mailing list now causes me to doubt this.

Of course, I'm taking Mono and dotGNU.

What does all this add up to? It looks to me that Mono and dotGNU provide migration paths for existing MS customers. J2EE provides a software scalability that is not possible with Microsoft application servers. Between Sun, SGI, and IBM, the MS/Intel hegemony don't stand a chance with respect to hardware scalability. And with JBoss, Microsoft can't compete on price. It seems to me that the Unix camp will do quite well with this whole web services thing.

That said, it's not like one side will win while the other side loses. No matter what happens, MS will have a sizable camp of die-hard devotees. Likewise with the Unix camp. Somewhere in between, web services will support mixed solutions. Throw in non-MS implementations of the CRE, and the current quality of Java under Windows (it's still better than Linux...and, yes, I have tried the IBM VM), and we've got a situation where the underlying platform is really not that important. Finally, I'll get to focus on what I do best (programming), while avoiding all the religious hype surronding MS vs. Unix.

JBoss Enhydra Jakarta Jetty jUDDI pUDDIng Resin

Just pick a project and start contributing ;-)

I don't know about IBM but I doubt Sun feels fucked by the OSS community. There are several Open Source implementations of the J2EE platform or parts of it available and being developed. It's mostly that the Linux community is somewhat ignorant of them. Plus, of course they have more than 20 commercial companies developing implementations the J2EE platform, including IBM, which guarantees competition in the platform implementation and I doubt we will see in the same scale with the Microsoft platform.

For Open Source J2EE, check the following:
Jakarta
JBoss
Enhydra
Jetty
Resin

And why should anyone ally with Sun and Java? I've read their license and billj's justification for it. Why should anyone surrender their rights in this manner?

What does writing Java software or implementing Java API's have to do with Sun's community license?

There are plenty of Java implementations out there, both commercial and open source, that directly compete with .NET. Yet you never hear any of them mentioned in /. news. Seems the editors are to keen on spreading the .NET hype.

Jakarta
JBoss
Enhydra
BEA Weblogic
IBM WebSphere

My personal opinions, of course..

But first of all, all this is doing is adding the hype behind the .NET platform. At the moment, it's an unproven technology and is relying on the marketing force to get it established. And seeing there's 2 or 3 .NET articles on /. every week makes me wonder if the community here is just doing free work for Microsoft. I don't even remember when slashdot last posted an article about the competitive technologies (J2EE) last time.

Second, I think what is inevitable is that if there is ever even a threat of genuinely competitive Open Source implementation to Microsoft's own view of .NET, they will use their entire legal force, patents and such, to stop it from succeeding. Remember that .NET is major move from MS to get into new markets and introduce new licensing models (rent software, etc), so basically they're putting all of their corporate power behind the .NET effort and they'll be damned to let any Open Source effort to take a single $ out of their market share. We've already seen some indications of this in some of their new licenses which puts the Open Source licenses in some disadvantage.

Learn UDDI, ebXML, J2EE. There's no risk in providing Open Source alternatives on the first two. J2EE has still some licensing issues that requires extra work to get around for OS projects but it's quite feasible and have been done already. It's a proven and established platform. Basically SUN would love to see Open Source J2EE implementations fight the threat of .NET on the low end market so they're unlikely to react in negative fashion to such endeavours (SUN is only one of over 20 J2EE platform providers, including companies such as IBM, Oracle, BEA, Sybase, etc).

For those who are interested in working in the Windows realm, reverse engineering .NET might be an interesting project. However, I don't see the point of putting a major Open Source force behind a battle that will be fought in Microsoft's terms. I see it more productive to fight the .NET on our own terms. Choose your battles wisely.

jboss.org
Apache Jakarta
Enhydra
Jetty

This perspective is based on multiple experiences in which serious bugs in MS products - like memory leaks in IIS/ASP - were never addressed. Being a highly competent developer, it is not acceptable to me to be at the mercy of a company that does not even do a good job of pretending to have my interests as a customer at heart.

Much the same feeling applies to the operating system and OS-level tools. I know experienced Microsoft systems integrators who have had endless problems with Microsoft's tools, Proxy Server being a prominent example. Problems with Exchange are legion and legendary; System Management Server is a spectacular failure; and their DNS server is little more than a joke. MS Service Packs and hotfixes are as likely to break major functionality as to fix bugs - the original Service Pack 6, and the more recent Exchange hotfix are cases in point.

From my perspective, Microsoft peaked at around the time NT 4.0 came out and has been wandering directionless since then, changing acronyms (DNA anyone?) on a regular basis to attempt to hide the lack of any significant innovation.

Two technologies originally led me to be pro-Microsoft: NT itself, and COM. NT was a good product, for its time, when the betas of NT 3.1 came out in 1992 or so. NT 4 made the catastrophic mistake of importing the Windows 95 user interface, and then turning the ever-buggy Internet Explorer into the GUI shell. Since then stability has only deteriorated, and almost no fundamental progress has been made in making NT/2000/XP support some of the more powerful capabilities and configurability long provided by Unix - proper remote administration capabilities not least amongst those.

It seems that any overall vision that had existed at the time NT or COM were conceived have since deteriorated into a mad rush to maintain control in a changing market, driven by the Internet, which is something Microsoft is still trying to control rather than "get". Factions within Microsoft with backgrounds in things like mainframe transaction server systems argue at cross-purposes with advocates of academically pure object-oriented systems. If there's someone with a global vision at Microsoft, I don't know who it is: Nathan Myrhvold left long ago, and Bill Gates has spent too much of his career making billions to be a competent software architect today.

Microsoft has also never quite gotten the hang of TCP/IP - with the possible exception of the core of IIS, its Internet-oriented tools uniformly suck. I've already mentioned Proxy Server and DNS. In Win2K, Microsoft finally gave up the battle in some areas and fell back on pure BSD tools, such as the telnet implementation. The Wall Street Journal's recent story on Microsoft's reliance on open source software gives more examples of this admission of defeat.

But even while they're resorting to open source code, Microsoft seems to completely miss the power of simplicity and interoperability evident in Unix/Internet tools; or this may be a deliberate strategic policy. If tools are too simple, extensible, interoperable, or open, customers will have too much ability to control their own destiny, and thus won't be as easy to suck into a recurring-revenue future in which Microsoft bills its customers annually and provides arbitrarily chosen upgrades in return ("this new dancing paperclip is better than the old one, honest!")

In addition, Microsoft's own insistence on reinventing everything works against it: sucky initial implementations of Winsock led to applications which didn't get the concept of asynchronous communication. You still see this in products like Outlook today: they can lock up for extended periods while doing network access, something that should be completely transparent and in the background. [I'll say one thing positive here though: I/O completion ports are pretty sweet, and I've used them to good effect in some server applications. They've also helped IIS be an excellent performer. But one good API feature isn't enough, especially when the application developers don't understand how to use it.]

It isn't as difficult as one might imagine to convince hard-nosed business-oriented customers of the perspective I'm outlining: Microsoft's threatening lawyer's letters about license compliance, sent blunderbuss-style to all customers regardless of any evidence of lack of compliance, don't win friends amongst IT staff and CxOs. The threat of rental models, browsers which modify the web sites of other companies, and critical coverage of these things from quarters such as the Wall Street Journal, all combine to make you wonder: is Microsoft aware that it will ultimately need to rely on more than its current desktop monopoly, and instead convince customers to buy its products based on their merits, and the quality of service it provides?

There's no long-term strategy there, just an attempt to keep the excessive revenue flowing until the next set of CxOs can take over and inherit the mess. As a profit generator, Microsoft represents an incredible and possibly unprecedented feat, which I can respect from a certain perspective; but that doesn't mean I want to number myself amongst the cattle slaughtered to feed its unholy appetites.

Server software has become a commodity, and Microsoft is desperately trying to tie unrelated components together and avoid standards, so that customers have no option but to accept the entire package, and pay serious money for that which has become freely available elsewhere. This is done at every level of its software offerings, so that in the application area I'm talking about, for example, the operating system is tied to the web server is tied to the transaction server is tied to the template language is tied to the virtual machine is tied to... did I mention the operating system?

Yet you can go and download the source code to systems that do much the same thing - e.g. the Enhydra or Resin application servers - and, as alluded to above, these systems will run on almost any operating system and web server, with no secrets (you have the source), and no lifetime commitment to a development model espoused by exactly one company. And this applies double to commodity products such as file servers, proxy servers, web servers, DNS, email, and the like: the free products are actually significant improvements in terms of functionality and reliablity, over Microsoft's equivalent offerings.

Microsoft has grown too far, too fast, and become way too voracious and greedy. I rode with it to the peak of its wave; that wave has begun crashing, but instead of crashing onto a nice, wide open beach, it's crashing into an inescapable little Microsoft sandbox. I am jumping off to a different wave in which the currents don't work against me as much. I'm don't argue that .NET has no technical merits whatsoever; but the cost of chaining oneself to it is too high.

I'm also interested in investigating Enhydra.

For more info on Java servlet tutorials, ect. check out my blog: Brainspatter

Curious__George

Jython rocks! It got the static but stable java class libraries with the dynamic scripting power of python. Everything JSP can do, jython servlet can do as well.

For larger project, you no longer have to mix presentation with logic like ASP, PHP or JSP, you can use XMLC with it for clear separation.

See this site for more info.

I will agree with your level of frustration with the buzzwordology and incorrect representations of what XML is actually useful for.

--

How many times do we have to tell the "pointy haired boss" that politics does not make good software?! You need to impress upon your boss the fact that all marketing and promises aside, Microsoft Access is not a scalable or stable solution!

When will people learn to delegate responsibility fully to the people who know how to do their jobs best? By not trusting you, the knowledgable staff member, on your design decisions, your management is suffering themselves no small number of headaches for the future of their company. By locking you into an environment that you are 1) not comfortable with, 2) do not trust, 3) doubt will fit the bill, and 4) dislike, they are seeding the crop of their own distruction.

Take a stand. Review your software design goals, and research the proposed tools and environments to do the job. Include in your research their proposals, and work to disprove them based on your own knowledges and instincts. If they can't trust you, their developer, and would rather go with what a marketing drone would recommend, tell them to hire the marketing drone to write the software.

On a less general note, my advise about writing RDBMS-based software:

1) Chose an RDBMS that allows VIEW's, STORED PROCEDURES, or other optimizations that allow the RDBMS to generate and store query plans

Plans are essential tools to efficient queries. Your database management system must decide which indexes it needs to use to fulfill your requests. VIEW's and STORED PROCEDURES are excellent examples of pre-compiled query plans.

A second advantage or use of VIEW's is that of security. VIEW's hide the details of a normalized database and can limit the records viewed from larger datasets. If your design includes ANY type of privaleged users, VIEWS will help you implemnt the security model immensely.

2) Choose an RDBMS that supports TRANSACTIONS

Again, that eliminates MySQL. (Sorry, but it's true.) Some people try to argue that transaction are unnecessary. This may be true with an unnormalized database schema, but when you start to separate the data into its atomic parts, a transaction is essential in tracking the addition, subtraction, or alteration of a set of data that spans multiple tables or records. It is ESSENTIAL for database integrity. I don't trust a program to faithfully rollback a transaction on its own. Computers have hardware problems, programmers blink their eyes as they're searching for bugs. Having an RDBMS that supports TRANSACTIONS isn't a convenience, it's a requirement.

3)Design as many "canned reports" as possible.

There's nothing more frustrating than trying to design a dynamic query builder. Not only do you loose the advantage of having pre-planned queries, but you have also worry about how to best deliver an interface flexible enough to build these dynamic monstrosities. If you don't believe me, take a look at the Bugzilla query page...

4)Choose an RDBMS that supports CURSORS

"Why," you ask? Simple answer. Ever wonder how you're going to limit the result set of a query, especially that one that likes to return 10,000 records even though you will most likely find 50 records to be overwhelming to display on your carefully designed UI? CURSORS provide you a way to page back and forth through a result set withough having to requery the database using MAXROWS options. You may have to hit the database more often to retrieve the results, but the server no longer has to compile a query plan and collect the resultsets. It simply holds the data for you until you need it. Who wants to pass around huge result sets, sucking up bandwidth and memory if you don't need it?

Guess what... This counts out MySQL once again.

5) Do NOT design the business-logic or rules-logic into the CLIENT!

The principals of simple design logic here. If you design your software around the client, then when the rules change in the game of policy (you know, the thing that the "pointy haired bosses" change on a whim, you have to upgrade ALL the installed clients. Guess what? This counts Access out.

What can I say. Access + MySQL sounds like a loosing combination. Access and MSSQL sounds like a better combination, but I would opt for something along the lines of PostgreSQL and Java (though the client-side SWING sucks ass). If you design the application with at least a three-tiered approach, client-server-database, you will be allowed some flexibility in which direction you can migrate with DB selection and client selection.

Anyway, I have to go to sleep so I can get up tomorrow and program... Good luck! Oh, go check out some of the projects like Enhydra.org or jboss.org if Java+Appserver+RDBMS+web raises an eyebrow or two.

--

Now help your mom download, apply, configure, compile and install a source code patch!

I know people who are blessed with parents who know how to program, but my mom wanted to go back to CompuServe after Dad fixed her up with Earthlink because earthlink gave them netscape on the installation CD to read her email with.

She didn't know, until I came to visit, downloaded and tested every email client available for the Mac OS, and set her up with Sono Software's Musashi that everyone's email wasn't hardwired to their ISP. I tried to explain to her before I visited that she could get a different mail program, but didn't understand - she didn't know she was running Netscape to read her email, she thought she was reading her email in Earthlink.

My dad knows a little programming - FORTRAN IV on an IBM 360 via punchcards.

If something breaks on their little Mac (and they manage to do it somehow), it stays broken until their son the software consultant flies home to visit.

Please contribute articles to the Linux Quality Database on how to write quality software, test it, or send in links to quality information and resources that I can link to from the page or write articles about.

Especially important are articles that are accessible to ordinary users or inexperienced programers on how they can contribute in a meaningful way to QA testing of the Free Software product of their choice. An example is my article (still in progress) Using Test Suites to Validate the Linux Kernel.

Planning for the kernel testing database that I have in mind is still in a vaporware phase. If you know about designing database schemas I could really use your help in architecting this thing. I could write the database access code myself but I don't want to plan the schema because I'm sure I'd make a mess of it. I've never designed a real schema before.

I'd like to use Enhydra as the application server - it's pretty good and open source. You can integrate it with Apache or the Netscape server, or it comes with its own Java HTTP server built-in that you can use either for testing or production.

When you use the Enhydra multiserver in development the whole enhydra system can run in one Java VM process. I echoed out the java command line from the startup script to find out what all the parameters were then put the command line into NetComputing's AnyJ debugger (free as in beer for Linux) to run a whole web application in a source debugger. Much nicer and more effective than printing "here I am" to the console.

I believe they have Enhydra running under Kaffe now. It didn't when I tried it but the startup scripts now support it as an option. I reported the problem to the Kaffe folks quite a while ago and I guess they fixed it.

Mike

Personally I picked up this book a while ago. I needed to get up to speed on JSP. It is a good read. I didn't find I needed the JSP or the Servlet specification handy to get through it, and I had only a passing familiarity with JSP when I started.

Mark and Duane deal with the subject well. The chapter on "Architecting JSP applications" is very helpful for someone coming new to the Java way. The coverage of java beans is decent, although I'm not personally a big user of them.

I would recommend the book as a good starting point for using Java as a web development platform, but as a starting point. Take a look at some of the alternatives to JSP. Personally I've moved away from JSP, and haven't used them in a single large project to date, except in a purely cursorial manner. We've since moved to using Enhydra as our framework for using Java on the web. I highly recommend it, but also check out some of the stuff over at the Jakarta Project for some other alternatives to JSP.

Mark

--

I originally wasn't going to write a response to this, thinking that the whole premise was ludicrous. There doesn't have to be linux support for Java, you just write java and it runs on any platform. There is a large amount of Open Source support for Java, from the Giant Java Tree, to the Java, Jakarta, and XML Apache projects. There is even an Open Source application server called Enhyra that supports pretty much everything you would expect from an enterprise class J2EE server. And if you don't like open source, then BEA's WebLogic server runs fine on Linux.

So why is there an impression that the Linux community doesn't support Java? One thing I will say is that if you are a Java supporter, you probably aren't a strong Linux supporter. That is because Java is platform independent. A Java developer doesn't care what platform they are on. Before people respond to this with the typical FUD that Java isn't cross, platform, bear in mind that all of the open source projects above run on all the platforms I've ever used them on, without any recompilation. Xerces worked on Win2K and linux. Tomcat worked on Win2K, linux, and Solaris. I don't know about weblogic, since I haven't tries moving the binaries over (I just used the rpm on linux, install on Win2K). Development in Java is development in Java. If you do it right (meaning don't setLayout(null)), it'll work. If you're server side, you have no worries.

That being said, Blackdown supports JDK1.3, the latest release of the JDK on any other platform. It seems that the majority of the OS developers I know from the projects I listed use linux as their development machine. And let's face it, Java is giving linux a lot of credibility in the server side market because it's sinking in that spending 20,000 on a single Sparc if better spent on a cluster of linux machines running (insert appserver du jour here).

Finally, you can go ahead and say that it isn't making any headway on the desktop. Well, that's true, but it isn't making headway on any platform's desktop. Linux is no exception.

You can try to say that it isn't making headway in the embedded market, but with the KVM for larger embedded devices (>40K RAM), and real-time specification fromt the community development, you'd be wrong.

I'm surprised that JDJ would print such tripe. I'm not surprised that Slashdot twisted it even farther and threw in a bunch of FUD.

Have you looked at Enhydra? It includes XMLC which compiles static HTML files containing dummy data which can be prepared by a web designer into classes which can be used by the app programmer to display dynamic content. Take a look at it, it sounds like it might just suit your requirements. It's Java, so runs pretty much anywhere.

For great, easy-to-use, scalable open-source web application delivery, check out Enhydra by Lutris Technologies. It uses Java for easily programmable web applications, and comes with Director, which allows you to automatically connect servers for failover at the software level. Not only that, but it's free, or for a nominal fee, buy it and get support from Lutris. Also great is XMLC, which lets you take HTML (or other XML) pages, insert tags, and add in dynamic content very easily. Definitely worth at least downloading and trying out, it only takes about half an hour to learn the basics (assuming you know Java).

Standardized (albeit by Sun), extensible APIs, especially on the server end, and extensible products, is part of what makes Java thrive today. Transaction API, J2EE, JNDI, Java2D/imaging, Java3D, servlets, JDBC, CORBA. Plus a host of pre-packaged libraries for things like sockets and RMI. Products: object databases (Ozone, the Castor O/R mapping framework), transaction managers (Tyrex), web servers (Resin, Jetty, Orion, Enhydra), XML etc.

Above all, Java connect to anything, provides a lot of freebies (garbage collection, a simple object model), is high-level and easy to learn, and lets you be more productive right out of the box as opposed to languages such as C++. No wonder new stuff is sprouting up like mushrooms -- a phenomenon that I suppose Bjarne Stroustrup is mildly annoyed about and doesn't quite understand. Once you've written a C++ app, it's a dead end. It not reusable. Unless you wired it up with magical strings and CORBA and reinventing all sorts of technologies, it just sits there.

This is much the same reason Python is thriving, really. Unfortunately, Java currently does not have anything that comes close to Zope. Turbine and Cocoon sound like two different projects aimed at this area, but they're not even close.

Who cares about Amex or set-top boxes? Unless I can write TiVo-like apps on my desktop computer that controls the box in interesting and hitherto-unrealized ways, it's useless, just another closed implementation. And Amex, well, how do I connect to my card, then?

Now:

• Both Oracle 8i and IBM's DB2 use Java extensively both for their DB administration GUIs as well as for middleware code. If you didn't know, these are the number 1 and number 2 Enterprise database systems in the world

I wish you hadn't mentioned that. Oracle's bloated, clunky Java GUI stuff is their big black sheep. I wish they never screwed this part up -- Oracle's native NT tools used to be at least adequate. Compare Oracle's present, slow, unstable, overdesigned, Microsoft Bob-like Java GUIs with Microsoft SQL Server 7.0's flashy, fast, and hugely functional tools and you just want to crawl into your mama's arms and cry like a baby.

• Java servlets and JSP are used extensively on the web from sites like mail.com to Firstunion.com. Hundreds of sites use Java(TM) to deliver dynamic content these two are simply the most prominent that come to mind.

Servlets is hardly Java's finest moment, same goes for JSP. True, servlets replace CGI in a nice way, and anything is better than ASP and assorted horrors, but that's about it.

Servlets make up a very low-level layer, and servlets themselves are quite isolated entities, compared to the riches of Zope's DTML documents.

Please, developers, do yourselves a favour and read up on how to properly divide content, logic, and presentation. Hint: Putting Java inside HTML gives you no cigar. Look instead at things like Freemarker and Webmacro, or even that bastard son of template processing, XSLT. Even so, these are quite weak tools, and you need to buy a $35,000-per-CPU app server to get any sense of an integrated package.

End of rant.

I imagine the reason there is so little heard about GSP is because there are so many other solutions that are familiar and work well for people...and not just proprietary solutions, either. There are open source implementations of Java Server Pages, which appeals to the Java development community, not to mention PHP. Both of these are tried and tested by tons of sites. BTW, if you're looking for an application server that's open source, check out Enhydra, an OSS Java/XML server that can run standalone or as a servlet.

Brief summary of the argument: our customers are not the people who buy toolkits and components, they're people who buy completed applications. But in order to deliver completed applications we need a toolkit to build on. If we try to keep our toolkit proprietary, it will fall behind competing toolkits (such as, e.g., Enhydra) because we don't have, inside the team, enough people to develop it and debug it fast enough.

We could adopt another toolkit (such as Enhydra) but if we do we become just another user of the toolkit, with little control over its direction and no particular reason for people who want things built with it to come to us. By being the core of an Open Source project we get potential for kudos, the ability to steer the project, and, hopefully, a wider user base for the toolkit contributing patches and extensions.

Enhydra is an open-source Java application server. It provides a graphical database design tool, a site management console, load balancing, database connection pooling, and session management which automatically chooses between using cookies and url rewriting. Plus it's free. :)

It also has a great tool called XMLC which IMHO is a far better solution for embedding dynamic content in HTML than ASP or JSP. It lets you create dynamic HTML pages which a graphic artist can then edit in Dreamweaver or whatever tools they want to use - they can change the look and feel of the site without bothering the programmers, and there are no non-standard tags for their tools to choke on.

The students will still have to do needs-analysis, design the database structure (if necessary), design the interface, write the servlets, integrate with existing legacy systems, integrate with any credit-card processing software they might need, etc... Enhydra just provides a fantastic set of tools to let their applications include advanced features which they might not otherwise have the time or inclination to implement. It also provides a supported platform that the businesses can grow on, add functions to, and scale up if their on-line requirements increase in the future... and you know they will. ;)

http://www.enhydra.org

Last summer I wrote a paper advocating to my colleagues that we open source our core Servlet toolkit. After some discussion they agreed, and the toolkit is now available here. The paper is a purely business argument, and you might like to consider whether any part of it would be useful in your case.

The point at which we finally announced it as Open Source on Freshmeat and on the Java newsgroups was only a month ago, so we haven't really much experience yet; we've had some hundreds of downloads, but as yet absolutely no feedback.

Do I regret open sourcing? Not at all. The only regret I have is that we didn't do it much earlier. In some sense our competition is Lutris' Enhydra. We started work on our toolkit before they did on theirs, and were, at the time, a similar sized team. By open sourcing early, and proselytising widely, Lutris have not only gained themselves huge visibility (and apparent success), they've also been able to develop their toolkit a lot further than we have ours, partly because other people have contributed to it but also, I suspect, because they've got a lot of business as a result of their visibility. This isn't sour grapes - I respect those people, they've started from the same place and been more successful than we have.

Enhydra also comes with InstantDB, a pure-Java RDBMS designed for the web and Enhydra Director, a very good load-balancing tool.

Other nice features are the MultiServer which, among other things, allows easy local developement without needing to setup a server like Apache. It also allows debugging live servlets.

All in all, Enhydra is great! Use it!

Adam

P.S. Also, there are facilities to use an IDE like JBuilder or JDeveloper with Enhydra.

--
Adam Sherman

Enhydra also comes with InstantDB, a pure-Java RDBMS designed for the web and Enhydra Director, a very good load-balancing tool.

Other nice features are the MultiServer which, among other things, allows easy local developement without needing to setup a server like Apache. It also allows debugging live servlets.

All in all, Enhydra is great! Use it!

Adam

P.S. Also, there are facilities to use an IDE like JBuilder or JDeveloper with Enhydra.

--
Adam Sherman

Enhydra also comes with InstantDB, a pure-Java RDBMS designed for the web and Enhydra Director, a very good load-balancing tool.

Other nice features are the MultiServer which, among other things, allows easy local developement without needing to setup a server like Apache. It also allows debugging live servlets.

All in all, Enhydra is great! Use it!

Adam

P.S. Also, there are facilities to use an IDE like JBuilder or JDeveloper with Enhydra.

--
Adam Sherman

Enhydra also comes with InstantDB, a pure-Java RDBMS designed for the web and Enhydra Director, a very good load-balancing tool.

Other nice features are the MultiServer which, among other things, allows easy local developement without needing to setup a server like Apache. It also allows debugging live servlets.

All in all, Enhydra is great! Use it!

Adam

P.S. Also, there are facilities to use an IDE like JBuilder or JDeveloper with Enhydra.

--
Adam Sherman

The cool thing about Engydra (that I'm suprised the original poster didn't mention) is that the development is entirely opensourced. It's sponsored by lutris. They make their money off support contracts for this thing. I've seen some demos of the product, mostly just using cell phone emulators (that I think they ship with enhydra, or they will very shortly), one java, and two win32's, so you can test all your wap apps before fully deploying them. There's also a sample app or two in there. go check them out .

-Peter

They are currently in the process of upgrading to the servlet 2.2 API, and their FAQ details the finer points of running Enhydra with Apache and Apache JServ.

All in all, it's a fine solution. It took me just a little bit of research, but once I got it up and running, I found that it was very reliable, and more than ample speed-wise.

Hope this helps...

EJBoss (by Telkel) is one of the OSS EJB container developments that I know of. Others are the efforts at the Apache Foundation and Enhydra.

Hope this helps...

Java internationalization is a really cool solution. It takes a day or two to master the fine points. But it'll pay off in the long run.

Hope this helps!

Not that I have used it but what about Enhydra? Shouldn't it be a worthy contender in this space? It is afterall a Java based solution and this is usually something "the big boys" like more than something as non-industry standard as PHP.