I agree with you. Syntax can be and should be learned in days. Intricacies, libraries, good behavior and the like that at least a year, but then you should have it done.
I come from a similar situation and have managed to do what you want to do. To sound a little zen don't try to change their minds just show them the benefits. In my case I drew on my knowledge on the lack of vendor lock-in combined with the economics of the situation and the inclusion of support in our seperate support contract (really cheap support at that).
As for support that was never really and issue with us so I have no argument there. Now Tomcat has some flaws (most in the JSP compiler Jasper and their live redeploy area), but is otherwise a very sweet little servlet engine (don't call it an appserver it isn't one in the J2EE sense of the word and that is the game you're playing when you use things like servlets).
Once it has compiled your JSPs it works just fine and the sweet things and the selling argument for our projects was redundancy of providers. You have a change of enviroments like going to another servlet engine. With a very minimal amount of care in your coding and everything is portable in fact if you stick to the Servlet/JSP api then you're good to go.
In fact we had some time one evening and switched between Tomcat, Resin and Jetty with only a few minutes spent making the configurations fit and the files unpack and install.
On a sidenote if you can delay any lock-in on a specific version of Tomcat, try and see if you can get your system over on the upcoming Tomcat 4.1 I am loving the improvements it brings esspecially in speed.
You should try to change his opinion on jBoss though. jBoss has been the most loved thing about that recent projects (and EJB writing is in combination with a good Ant script and XDoclet http://xdoclet.sourceforge.net not that big a pain). It is probably the most stable thing about this entire project with hot redeploy (great for development), good performance and great ease of use and install on top. In fact the new 3.x version is even greater with clustering, failover and some very interesting innovations in the area of control over which parts of the server to actually run via SARs and JMX. But enough about all this.
We are in the process of finishing a large J2EE project with the database end running on SAPDB and we have had no regrets. It runs along smoothly and in fact the only annoyance with it has been a crufty manager application for datamanipulation (for tests), which was remedied by using Access as an ODBC client and a little trouble with the actual creation of a database. The same database has had a 3 months run under load and with the developers hitting it with the weirdest commands and it has only needed one service restart so far. I recommend it.
Re:Modular solution
on
KDE 3.0.1 Ships
·
· Score: 3, Insightful
Actually the reason for Konqueror and KHTML is the really tight integration of the system components and IO substructure of KDE. KDE has a brilliantly easy to use component technology called KParts, which is good for Desktop use and a equally great (and extremely useful) IO system called KIO, which is used in combination with KHTML and KJS (the JavaScript engine) to make Konqueror a browser.
Now it could be basically possible to use Gecko (the HTML/XML/XUL renderer of Mozilla) like they do in Galeon, but honestly when they began writing Konqueror Mozilla just wasn't something useful and there was and is no release quality Gecko port to Qt, which is absolutely required for an integrated browser. Now for normal browsing both browsers are greatly useful and I do use both (Mozilla RC2 and Konqueror for KDE 3.0). But honestly to me Konqueror is just more friendly for general work, while I use my Mozilla for netbanking (mostly due to the really insistent browser ID checking of the banking webapp).
It's all good, all the time
-Herbal Thought, Dark Angel TV series, brought to u by RandSig
Slashdot Mirror
I agree with you. Syntax can be and should be learned in days. Intricacies, libraries, good behavior and the like that at least a year, but then you should have it done.
I come from a similar situation and have managed to do what you want to do. To sound a little zen don't try to change their minds just show them the benefits. In my case I drew on my knowledge on the lack of vendor lock-in combined with the economics of the situation and the inclusion of support in our seperate support contract (really cheap support at that).
As for support that was never really and issue with us so I have no argument there. Now Tomcat has some flaws (most in the JSP compiler Jasper and their live redeploy area), but is otherwise a very sweet little servlet engine (don't call it an appserver it isn't one in the J2EE sense of the word and that is the game you're playing when you use things like servlets).
Once it has compiled your JSPs it works just fine and the sweet things and the selling argument for our projects was redundancy of providers. You have a change of enviroments like going to another servlet engine. With a very minimal amount of care in your coding and everything is portable in fact if you stick to the Servlet/JSP api then you're good to go.
In fact we had some time one evening and switched between Tomcat, Resin and Jetty with only a few minutes spent making the configurations fit and the files unpack and install.
On a sidenote if you can delay any lock-in on a specific version of Tomcat, try and see if you can get your system over on the upcoming Tomcat 4.1 I am loving the improvements it brings esspecially in speed.
You should try to change his opinion on jBoss though. jBoss has been the most loved thing about that recent projects (and EJB writing is in combination with a good Ant script and XDoclet http://xdoclet.sourceforge.net not that big a pain). It is probably the most stable thing about this entire project with hot redeploy (great for development), good performance and great ease of use and install on top. In fact the new 3.x version is even greater with clustering, failover and some very interesting innovations in the area of control over which parts of the server to actually run via SARs and JMX. But enough about all this.
We are in the process of finishing a large J2EE project with the database end running on SAPDB and we have had no regrets. It runs along smoothly and in fact the only annoyance with it has been a crufty manager application for datamanipulation (for tests), which was remedied by using Access as an ODBC client and a little trouble with the actual creation of a database. The same database has had a 3 months run under load and with the developers hitting it with the weirdest commands and it has only needed one service restart so far. I recommend it.
Actually the reason for Konqueror and KHTML is the really tight integration of the system components and IO substructure of KDE.
KDE has a brilliantly easy to use component technology called KParts, which is good for Desktop use and a equally great (and extremely useful) IO system called KIO, which is used in combination with KHTML and KJS (the JavaScript engine) to make Konqueror a browser.
Now it could be basically possible to use Gecko (the HTML/XML/XUL renderer of Mozilla) like they do in Galeon, but honestly when they began writing Konqueror Mozilla just wasn't something useful and there was and is no release quality Gecko port to Qt, which is absolutely required for an integrated browser.
Now for normal browsing both browsers are greatly useful and I do use both (Mozilla RC2 and Konqueror for KDE 3.0). But honestly to me Konqueror is just more friendly for general work, while I use my Mozilla for netbanking (mostly due to the really insistent browser ID checking of the banking webapp).
It's all good, all the time
-Herbal Thought, Dark Angel TV series, brought to u by RandSig