Domain: jboss.org
Stories and comments across the archive that link to jboss.org.
Comments · 201
-
you're confusing "app server"...
with "servlet container" and-or "JSP container". both tomcat and jetty are fine examples of servlet and JSP containers.
an app server, i.e., a server which serves up J2EE applications, is more generally thought of as a combined servlet, JSP, and EJB container. BEA, IBM WebSphere, etc, and JBoss are the real players in this space, but Oracle has their own app server rolling along now too. FYI, JBoss ships both a Jetty and Tomcat distribution.
Tomcat is the reference implementation for the Servlet and JSP container APIs. This means it is absolutely the standard. While Jetty is great for being "lighter" weight and more easily embedded, Tomcat would have to be my choice for "open source" servlet and JSP container. -
Enough Tomcat Bashing... I have proof it works!
I manage a few servers...
1 Apache box on an Ultra 5 (Slow sun box typically used as a workstation)
1 Tomcat box on an Ultra 5
I use mod_jk and hide the tomcat box behind the web server. This adds a nice layer of security and lets Apache process .html pages.
In total I have 5 instances of Apache, ~100 instances of tomcat, and ~150 web sites. The apache box sustains about 2MB/s and about 400k/s gets sent to the Tomcat box to deal with. I have had very few problems with Tomcat 3.3.
If you need some redundancy I would recommend using the mod_jk load balancing. It works very well and is simple to setup.
My advice: Don't litsten to all the Slashdoters who gripe about anything to do with Java, give Tomcat a try. It works for me!
BTW: If you want to get into J2EE stuff, absolutly use JBoss!!! It rocks! -
JBoss !
JBoss is an excellent fullfledged J2EE application server.
They even offer consultancy if you cannot get it right the first time.
Excellent award winning server, excellent support, what do you need more ?
It has Jetty integrated and gives you the full J2EE stack.
You can get it to work with Tomcat too: no problem.
Check it out, the design is awesome for the techies.
The support option is great for the management.
Everyone's happy :) -
Re:BEA is a joke
If you want something that actually is a development tool with a built-in Servlet Container, then check out Simplicity Enterprise. It uses a drag-and-drop metaphor that is much easier than Eclipse. Since it has a built-in Jetty server (the same one used by JBoss) with Execution-On-The-Fly(TM) technology you can test as you develop without having to re-compile! Definitely checck out the video
Disclaimer: I used to work for Data Representations, Inc., so I'm a little biased
:) -
Re:Don't scream
Actually it is not that important to have an open source Java implementation these days; since we have decent JVMs for free (from Sun and IBM for example). What is important is to have a J2EE compliant application server, and we have a production quality solution consisting of JBoss and Tomcat, which are open source.
-
Re:Yes, I definitively would!J2EE requires Tomcat (free) or a costly implementation (JRun,Webshere,etc.)
Uhh, Tomcat is hardly a full blown J2EE platform. Try JBoss instead.
It's amazing the amount of ignorance of most
.NET zealots here. You don't know a fucking thing about the alternatives that have been offered to you, free of charge, for years.Though fine by me, go burn your money on the next dead end solution (.NET) that is nothing but glorified Visual Basic.
-
Re:One might ask what took so long.
Its been on the JBoss site for qutie some time now
JBoss.org -
Re:Gee, been out a while
I have all but the clustering documentation. They've been decent. Not perfect, but often better than nothing and worth the $10. However the SAMS book that you can get the preview for(at least the edition I got a little while ago) is for the 2.3 & 2.4 series, NOT 3.0. You can get 3.0 documentation at sourceforge (look for the Quickstart pdf). Mostly I found the documentation was more for a serious programmer, not often good for someone new to J2EE. Also the 3.0 quickstart documentation is still in revision -- it's uncomplete. In general, when I need information, I check out the JBoss forums. They're up and running again.
-
Easy, Robust, and Open!AnalystScan (http://www.analystscan.com) is a high volume, dynamic Java powered web site. It runs PURELY open software (Jakarta Tomcat, Linux, PostgreSQL, Sendmail, JBoss), and has even withstood a mini-slashdotting when it was the focus of a slashdot posting regarding stock market analysts.
If you want to get going quickly, I recommend that you begin using Jakarta Tomcat 4. It has some features that make developing true J2EE apps a lot easier (JNDI support, JMS support, etc.) Remember that many J2EE apps don't actually need EJBs, which means that you do not need to deploy a J2EE container. If you choose to deploy a container, I recommend JBoss. It has some quirks, but is true free software, and the latest versions are actually beginning to outperform some commercial EJB containers.
Finally, take heed of some other people's comments... you do not need to have every Java TLA running for the solution to be a J2EE application. Choose the bits and pieces that meet your needs, and don't throw in the kitchen sink just because it's the technology du jour.
-
Re:His Father is a DinasaurFreeUser wrote: Those who write free software (myself included) do so because we love to do it, not because we are trying to get rich doing so. If you're writing free software because you hope to get rich by doing so, then you're in the wrong field.
I disagree. I believe that it is perfectly valid to try to "get rich" writing free software. Good examples are Zope and the JBoss group. If giving software away for free helps to market consulting services, then one can indeed "get rich". Now, we're obviously not talking Bill Gates rich, but we are talking doctor rich (which is rich enough for me).
-
Re:Your Apache example
Apache is a web server... iPlanet is a J2EE implementation. Apache is a great web server... iPlanet is a shitty J2EE implementation. True, iPlanet will serve up web pages, but if you aren't developing an enterprise-level web application, then it's like using a hammer to push the thumbtack into the wall. A broken hammer, but a hammmer. (I've done this by the way, and the plastic part of the thumbtack will break before the wall gives.)
I use weblogic 5.1 at work, and I guess it's okay. I mainly deal with the servlet side of things, as opposed to EJBs or JMS or any of that, and the servlets that it generates are not that efficient. Nor is the generation itself efficient (which doesn't impact runtime, but does impact my sanity as I reload pages). Anyway, wl5.1 feels like molasses in January in Greenland, but I'm sure it's not as bad as it feels.
At my previous company, we used Resin, which was pretty nice, but it's not a complete J2EE solution, it's just a small and fast servlet container.
If I were to start a new project, and I needed JMS/EJB/etc, I would probably investigate JBoss, which is OSS. If needed just a servlet engine but MIGHT need the other stuff in the future, I'd use Tomcat (also developed by our friends at Apache)... if I just wanted a servlet engine and that's it, I'd probably stick with Resin, which has the source available and is free for non-commercial use.
Maybe it's not OSS, maybe it's just Apache that kicks much ass. Xerces/Xalan/Tomcat/Struts/Apache. Damn, you have everything there for web application development (in Java anyway), and it's good and you can read the code, which I've used many times before. I've cursed weblogic many times for not being able to read the code (of course JAD helps for that sometimes).
My point is, iPlanet is not the counterexample to Apache, or Tomcat, or JBoss... iPlanet is horribly broken and bad. Which is strange, since it emerged from Netscape Application Server, which has been around for, well, since before I knew what the hell an Application Server was. Weblogic (maybe 6.1 or 7.0 is much better, we need to upgrade) works and is popular, but is horribly, HORRIBLY expensive for a production license.
-If -
You do _not_ open source truly custom work,The short answer is you don't. Open sourcing works great for generalized systems, the 'more eyeballs' maxim only holds when there are more eyeballs, and you only get them when the system is generalized enough to be of interest to anyone besides you and your client. True custom work should only contain your client's business logic (and maybe design) which as mentioned in other posts above is not a good thing to open source for security and business IP reasons.
I myself do custom work for small businesses for a living. I'm a Java guy who's into open source, here's how I typically work:
- Gather requirements duh. You gotta find out what they really need, obviously. Not always clear, but that's part of the job - translating their requirements on a business level into concrete development action.
- Sell the Client on pre-existing OSS frameworks In my case, server-side web development w/ Java, this almost always includes Tomcat. Not GPL'd, but hey, certainly better than the other, proprietary crap. Lately I've been doing more involved projects, so I've been pushing JBoss as well, which _is_ GPL'd and frankly fantastic as well. I try and run these on Linux w/ Apache if possible. I find this is not a hard sell - the main points being no licensing costs for them, more stable tools than the proprietary solutions, etc. These are also popular well-known systems which always makes business types feel better than unknown sketchy things.
- Use pre-existing OSS libraries for the general parts For me this means class libraries - if I need logging I use log4J, if I need XML processing I use Xerces, etc. (well bad examples since they're APL, not GPL, but you get the point). I also make this clear to the client, they usually like the idea as it saves development time and thus their money. I also let them know that any code I write to improve these libraries goes back to the project and is not the ownership of the client. This is also not a hard sell - my client doesn't care about owning parts of a logging system, it's not his business. This is how I get to contribute to OSS on the client's dime.
- Write the custom bits Given the above, all that's left is business logic and design. For me this means incorporating the client's business logic in a bunch of servlets of EJBs, and their front end design into a JSP page or an XSLT template. I typically give them full IP ownership of this - yes, I charge a higher rate b/c of this, and frankly this shit is useless to me outside of the current project anyway.
-
You can fry an egg on my head right now...
This should be a great boon to Java, a language renown for, well, sucking. But at the expense of the greatest of all languages? It's just to sad for me to express in words. I mean, who uses java anyway?
For Gawwwwds Sake!
Don't even get me started at how much faster, how much cleaner, how much easier to add to, and how much more efficient an enterprise site, like slashdot, would benefit from the full use of J2EE, including EJB's and a nice webcontainer (You can even stay with OpenSource and use Tomcat and JBoss.
Wow, this is the first troll I bit on in a loooong time... -
Re:Has anyone figured out how to pay the coders?Okay. First of all, when you're talking about paying software developers to write code, you have to understand that there are a few different "types" of software. I'll stick to the two I'm most familiar with: consumer software and enterprise software.
Let's take consumer software. Consumer software is things like applications, consumer operating systems, development tools, etc. Companies like Red Hat, CodeWeavers, Mandrake, theKompany, Suse, etc. all employ programmers. As far as I know, these programmers are making money, and in some cases, the companies are as well. CodeWeavers, for example, contributes code to the Wine project and then writes non-free "easy-installation and setup" utilities in order to have some "value add" that is worth paying for. Red Hat actually makes money from selling only services, as every piece of code that they write (AFAIK) is released to the public under an OSS / FS license.
Now let's take enterprise software. Look at projects like JBoss, Tomcat, Castor, etc. In nearly all enterprise software, there is a need for an "infrastructure layer". My company actually PAYS ME to fix any bugs in JBoss, Tomcat or any of the other things we're using as our "infrastructure" because it's a hell of a lot cheaper than paying for a resale license of WebLogic or WebSphere. Our customers are happy because they get a reliable system. I'm happy because I get paid to work on OSS stuff. My company is happy because they save money (or make more money, depending on how you look at it) using the OSS / FS infrastructure
... everyone is happy. I'm not starving to death, I swear. Lots of enterprise software companies take this approach. Why? Because it makes economic sense to do so. Why? Because if they pay their programmers to fix bugs in an OSS codebase, they get the added advantage of other people (who they do NOT pay) fixing bugs for them, too.So, I'd hate to be harsh, but
... you're just WRONG. -
Other options???
-
JBoss, OpenJMS
-
Re:That's what happens with proprietary "standards
Why not ask JBoss?
-
Apache/SunA couple of thoughts:
While it does matter in the aesthetic that Sun is restricting certification of open-source J2EE platforms, fortunately Sun has not taken drastic positions of 'shutting down' JBoss or anything like that. This letter from Marc Fleury seems to clarify the exact issue with JBoss.
This seeming 'rivalry' between Sun & Apache is not as clear-cut; Many of the Jakarta contributors are Sun employees and engineers. (Tomcat/Catalina is used as the 'reference implementation' for the Servlet/JSP specifications.) For more on this, check out the former 'open source guy' at Sun: James Duncan Davidson -
Re:J2EE books
FYI there's a JBoss book on the way from Sam's. It promises to be pretty useful; you can get more info about it and other JBoss documentation at http://www.jboss.org/doco.jsp
-
Re:Goodbye GNOME, Hello KDE
I switched a few weeks ago from GNOME to FXCE (I know, it's still base on GTK, but at least it isn't GNOME). And I think KDE is also barking up the wrong tree. It has become too bloated for my taste.
But I agree, GNOME is clearly going to the dark side of the force. If it's .NET functionality they want, there can always help with the JBOSS project. -
iPlanet vs. JBoss
The people over at JBoss are very high on their software (rightfully so in my opinion) and have proclaimed that their J2EE application server will be the death of WebSphere, JRun, iPlanet, etc. Presumably the big draw to JBoss is not only that it works but also that its free and open source. Is Sun planning on open-sourcing iPlanet or making it free to compete with JBoss?
-
Why isn't JBoss certified?
There has been some speculation that Sun is uncomfortable with certifying JBoss as a J2EE-compliant container. Mark Fleury, president of the JBoss team, has said "Sun quoted a price for that certification suite that is beyond the current financial resources of the JBoss team." Is there any possibility that Sun will relax these certification fee requirements for open-source initiatives such as JBoss, especially when they meet the technical requirements as specified by Sun?
- Rev. -
KHTML is not bulletproof yettry opening JBoss Documentation.
Well, I have not checked the source, but even if we assume that HTML there is not on a par, other browsers do not choke on it...
-
Project Info Page
-
Performance?
I have heard a number of negative things about JBoss's performance under heavy loads. Anyone with experience using it care to comment? It seems like the clustering would really help such situations, and I am excited to see it advancing as well as it is.
.. -
Lack of NATIVE Aps is not important
I operate in the J2EE world, the java enterprise world. we don't give a rats ass what OS we run linux/solaris/windows same crap to us btw the state of virtual machines on linux trails windows just fyi...
The modern application server the .net the j2ee should be in java just because is buys you teh app. then you compete solely on the vm field and that is a sweet position, level playing field.
it is the app server stupid, the web-app server is the key to adoption.
the article does mention linux+apache as a deployed solution "but it doesn't go much father" that is correct and why we need strong support of Java VM on linux, the J2EE open source groups are there: see JBoss, they have a full J2EE implementation and web services support -
Re:Who writes open-source software?interesting if not funny. I don't know the demographics of other projects but go see our team here.
yes many of them are actually stealing time on their job but many are also professionals taking the jump. I for one live of open source, I don't have a dumb job, haven't for the past year or so. It is ok, better living, more money, but it is not a "millionaire dot-com thing".
Bottom line: don't dismiss the open source model for a way FOR INDIVIDUALS TO MAKE MONEY.
I seriously think that one of the problems here is that you all assume that you must be working for some stupid corporation to make a living. Actually you can make a living too in open source it is not difficult.
marcf -
securing apps is the real dealsecuring the port is a trivial issue. Securing 80 or the IIOP ports or the RMI ports at the "firewall" is a pile of dunk. Using SSL to do the comm is more important and RMI/SSL IIOP/SSL is real. The real issue that is not addressed in this question is securing the applications themselves by allowing for authentication. There web services doesn't specify anything, it is a huge hole. So while the port 80 is "secured" or whatever that means to the manager that goes "oh ok them I am safe" you are really securing the little entry from the backyard, while the front door to the house is wide open with neon signs saying "steal me! steal me!".
App securing and propagation of security context/credential is the key, microsoft "passport" is aimed at that, by adding proprietary protocols to propagate credentials and implement security in a way that will be MS specific.
For more interoperability there, check J2EE that does specify security propagation at the wire leve with RMI/IIOP. And I am going to plug a project I work on (had to
;-) for the J2EE reference implementation with JAAS so that you can plug in your legacy stuff in there as well. Then we DO offer a WSDL/UDDI port to web-services to communicate with EJB so you leverage that model of security and VOILA, secured webservices. -
JBOSS is the Awnser!!
Dont wory about it... JBoss is still here. It was and IS the best open source J2EE app server out! It has features the biggies don't even have.
jboss.org
Regards,
Hiram -
from a technical standpoint...
this is really not a disaster, since lutris products actually suck a whole lot. Believe me. Ugly, confused, disorganzied, buzzword-driven design. But here's jboss to save the day. Use it if you're doing server-side work in java.
-
Can someone explain the dependence on Sun code?Plenty of free software implements proprietary standards (Mesa, Lesstif, all the *nix utilities in GNU, really). This has typically not been a legal problem, so I don't understand why implementing J2EE might be a legal problem. Perhaps someone can enlighten me.
My understanding is that J2EE comes from Sun in basicall three parts: specification and other documentation in natural language; the Java API; and a sample implementation. I think these parts are fairly distinct. I want to know which of these is the "problem".
Obviously, every implementor must make use of the documentation. Normally, this does not taint an implementation, but Lutris claims that "reading the specification for J2EE forces the reader to agree to the SCSL". The J2EE specification license I can find doesn't say that. Though it is fairly restrictive, it doesn't seem to prohibit a free implementation. So is the specification a problem or not?
The JBoss response says that JBoss uses "seven jars" from Sun. I'm guessing these jars define the API, ie, they consist entirely of interfaces, abstract classes, and (maybe) trivial classes. Is this necessary? Most free implementations of proprietary API's include their own header files as free software. Does Sun claim a copyright on the API itself? What is the legal status of such claims, since there is basically only one way to express an API? Or did JBoss simply choose not to write their own versions?
Finally, does Enterprise Enhydra use essentially the same Sun classes as JBoss, or do they borrow some of the sample implementation as well? Do they claim that their commercial nature, or some pre-existing agreement with Sun, makes their situation different?
Thanks if you can untangle this.
-
Re:Enhydra and J2EEHowever, Orion is not an Open Source product.
For Open Source (LGPL), go to www.jboss.org. It is the leading OS J2EE app server.
-
Sounds like JBoss' WebOSThis sounds awfully similar to the vision that is being implemented by the JBoss Group for their WebOS. For those unfamiliar with JBoss, it is an open source implementation of Java 2 Enterprise Edition (J2EE). However, the v3.0 release (known as the "rabbit hole" release) also contains a bunch of new technologies. Things like:
- Seamless distribution. The entire application server itself, as well as applications written within it, can be distributed automatically. Very cool.
- Worldwide scalability. Leveraging Java application servers' focus on scalability, this thing scales to the biggest hardware and to clusters
- Fault-tolerance. The clustering abilities provide high availability to JBoss (something JBoss lacked in pre-v3.0 releases).
- Self-tuning. Hmmm....no quick answer here. It can all be configured by way of JMX (Java Management eXtensions). I assume that, in the future, people will add self-tuning features.
- Self-configuration. Same as self-tuning.
- Security. Java has a very nicely developed security model already. JBoss uses this pervasively, as does any Java application server.
- Resource controls. Gee, this sounds to me like declaritive security. That, again, is offered by J2EE.
For those of you unfamiliar with JBoss, check it out. It's really nice. For those of you who doubt Java as a platform for application development, go talk to IBM or BEA. They both have tremendous businesses built upon Java application server technology. It's fast, stable, robust, flexible, scalable, and is buzzword-compliant with about anything else I can think of. Besides, I can write applications far quicker with Java than I can with other platforms.
-
Re:Tomcat As the Anti.NET?Tomcat and other open-source J2EE servers (e.g., jBoss, a J2EE application server) are not the only things that we (in the Linux and open-source community) need to compete with MS's
.Net. We also need open-source implementations of Web services, whose components include SOAP, a derivative of XML-RPC. Web services comprise a crucial part of the foundation of .Net. IBM has developed some documentation on configuring Tomcat to work with SOAP. The other components of Web services include:a) ebXML;
b) eXtensible HTML (XHTML);
c) Universal Description, Discovery, and Integration (UDDI), and
d) Web services description language (WSDL).
-
Re:J-Run
And if you do need EJB support, give JBoss a look. It's open source and intergrates well with Tomcat to provide the EJB side of things.
-
Re:J2EE-ish support? (for java CA)
Tomcat is a servlet container, not an EJB container. As such, it can only run servlets, jsp's (which really are just special cases of servlets), and javabeans. You need an EJB container to run EJB's. The most popular open-source EJB container is JBoss (it also integrates very well with Tomcat).
Your are correct in saying that you never instantiate an EJB directly, you ask the container for a reference to an EJB and the container can instantiate a new EJB for you or reuse an old one or pull one out of a pre-existing pool.
BTW, you may want to look into using JAAS (Java Authentication and Authorization Services) which was released today as a component of J2EE 1.3 for some of your security needs.
-
Why use Enhydra?
I'm not sure why someone looking for a J2EE implementation would go to Enhydra. JBoss is a much better, robust, mature platform for that sort of thing than Enhydra. None of this is to say that Enhydra is worthless - it's very good at what it does, which is a much more lightweight Java web platform than DB + EJB + Servlets + the kitchen sink which is what full J2EE servers are. In fact, most projects would be better off with the lighter-weight Enhydra, especially published-content type projects.
I guess what I'm trying to get at is Lutris should have kept Enhydra the way it was, and not screwed around with J2EE. We have JBoss for that, and Enhydra filled a much different need. The whole mess could have been avoided.
-
Re:Apache JakartaOne question: Where's the Jakarta EJB container??? Oh, wait, they ISN'T one...
Oh, yes they [sic] is
... JBoss. It's not part of the Jakarta project, but it integrates nicely with Apache/Tomcat. It mentioned (although only briefly) in the article, had you bothered to read it. -
Re:Wasn't this expected ?
-
Re:Where are MS rivals on this?
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
-
Re:Ximian, don't be silly.
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
-
Not worth it... (at least not yet)
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
-
Re:Tomcat vs. Apache Jserv
You might want to check out jboss. They've got an active community and a pretty good container.
-
JBoss
Anyone who hasn't already should check out JBoss -- my vote for the next-generation web services platform.
-
What about MY project?
I am the developer who won third place in the "Best Webapps Contest". While a lot of the winning entries didn't seem to be making much headway, my project was under active development.
I was to deliver 4 milestones to complete my project. The first was delivered in early December of last year and I have yet to receive the payment for this milestone yet. I was assured by John Egan of Collab.net as late as February 22, that I would be paid for it. I have a snowballs chance in hell of seeing that money now.
Milestone 2 was scheduled to be released in two weeks after being integrated into the Jive CVS repository.
Milestone 3 is to begin this weekend when I travel to work with Bill and Matt of CoolServlets to consult with them on the best way to include Moderation in the Jive codebase and integrate with existing Moderation code.
I still plan to do Milestone 4.
For those of you wondering what does the passing of SourceXchange mean for the Open Source world? Nothing. SourceXchange was more of a hinderance than a help to my project. They were supposed to supply every project (mine was #39) with a mailing list. The first time that I saw the SourceXchange mailing lists work was when Brian Behlendorf sent out the SourceXchange announcement that they were closing the doors.
From the letter:
Thank you to the hundreds of participants on our various projects, and to the sponsors who were willing to take a risk on a new model (and who, by and large, got good results).
I certainly doubt that MyComponents.com feels that they got good results from SourceXchange. They got very little from the contest winners (myself included) and I am sure absolutely nothing that would benefit them as a business. If MyComponents made any payments to Collab.net, they should be asking for a refund.
The only good thing to come out of the whole "Best Webapps Contest" was that it inspired the First place winner Rickard Oberg to write WebWork.
-
Re:JSP + Servlet + EJB = HeavenYes, but using gcj eliminates all of the benefits of JSPs. Namely, you loose the benefit of having a common JVM across multiple calls to the code. This means you can't pool objects (JSP does this automatically) or pool resources, such as database connections (DB pooling comes for "free" with J2EE implementations, such as the free one from JBoss).
All told, if you pick a decent JSP/Servlet engine (JRun or Resin perform about 3x better than Tomcat), you'll find the JSPs run just a hair (about 10%) slower than the fastest dynamic page systems, mod_perl & mod_php. With the object oriented benefits of Java, and the ability to separate presentation logic from business logic using JSP tag libraries, JSP/Servlet engines are an excellent choice.
By the way, I wouldn't discount ASP+, either. While ASP has a lot of problems, ASP+ has learned from a lot of previous mistakes, as well as from all the benefits achieved from JSP/Servlets. Of course, it will tie you in to MS solutions (bad! bad!), but it's a very good piece of technology, none the less.
-
Re:JSP + Servlet + EJB = Heaven
The link: JBoss.
Whoops.
-Hunter -
Re:JSP + Servlet + EJB = Heaven
JBoss is an excellent Open Source EJB server, plus all the other J2EE goodies. Some say better than WebLogic.
-Hunter -
politics != good software
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.
--
-
Re:Why are they doing this?Completely uninformed. There is a lot of GPLed, LGPLed and BSD licensed code out there written in Java. Java is not a "closed language". Some of the implementations of some of the APIs that are released by Sun are licensed under varying degrees of closedness. Generally they are freely available, and nobody forces you to use them (they aren't part of "Java" per se, but libraries for Java, such as the J2EE APIs). There are free implementations of many of these as well, for example, look at (JBoss. It's an LGPLed implementation of the J2EE APIs.
Also, with respect to Java itself, there are free implementations of the Java compiler and the Java runtime environment as well. But using Sun's Java compiler and Java runtime IN NO WAY affects the licensing of code that has been compiled with it.
There is sometimes confusion over what "linking" and similar concepts referenced in some Free or Open Source licenses mean in the context of Java. I won't seek to open these arguments up here. I'm just pointing out that your points are completely off base and the two issues - Java bindings for KDE and Freeness are orthogonal to each other.