|
|
||
Felipe Leme's BlogCommunity: Java Enterprise ArchivesThe name is bound, Java EE boundPosted by felipeal on July 31, 2006 at 06:53 PM | Permalink | Comments (3)The previous weblog says JEE is The Official Acronym for Java Enterprise Edition. That's not true - the new name for the <img alt="technology formerly known as J2EE"> is - and always have been - Java EE. If you don't believe me (after all, I'm not a Sun employee :-(, read the following message, sent to all SMI licensess (I'm such a licensee because I was awarded a TCK Scholarship a couple of years ago) last month: ---------- Forwarded message ---------- From: SMI-JavaLicenseeEngineering Date: Jun 23, 2006 1:31 PM Subject: Java Platform Naming Convention To: SMI-JavaLicenseeEngineering Back in 2005, Sun Microsystems announced a new Java naming convention, whereby future versions of the platform would be called “Java EE 5,” “Java SE 6," and “Java ME.” However, over the last year we have noticed that a few members of the Java community are using “JEE” and "JME," rather than “Java EE” and Java ME." Unfortunately "JEE" has different meanings that are not associated with Java technology. For example, a Google search on "JEE" returns topics unrelated to Java EE. We'd like to encourage you to spell out “Java” - i.e. Java EE, Java SE, and Java ME – especially in external communications, such as websites and blogs. Please take a few minutes to understand the reasons for the new naming schema, which are spelled out in this article. http://java.sun.com/developer/technicalArticles/javaone2005/naming.html Also, take advantage of the resources available, including the FAQs, and the 1-pager with the naming guidelines at the bottom of the page. Additional resources: Graham Hamilton's Blog: http://weblogs.java.net/blog/kgh/archive/2005/06/goodbye_j2se_he_1.html Thank you, Java community, for your support! Use the Java name and keep growing your momentum.So, if you are convinced now, please do your part and spread the word (I hope I have done mine :-). My 2 rants, -- Leme, Felipe Leme PS: the above message is reproduced here with proper authorization... The rise and fall of the application server as product (A.K.A. app server commoditization)Posted by felipeal on June 16, 2006 at 02:37 PM | Permalink | Comments (2)Much has been talked about the commoditization of the Java EE application server, specially now that 2 servers (Sun's Glassfish and Apache's Geronimo) are available under 'unrestricted' open-source licenses (JBoss and JOnAS are also open-source software and have been out there for more time, but they are licensed thorugh LGPL, and therefore cannot be modified unless the modifications are also made available as OSS). So, is the commoditization of the application server a true trend or just a speculation? Well, given the number of certified servers over the Java EE versions, looks like the trend is true:
So, we had a rise up to J2EE 1.3 and a fall afterwards, with only 13 J2EE 1.4 and so far only 2 Java EE 5 application servers available (even though Glassfish - the Reference Implementation - was developed under the OSI-approved CDDL license). I know it's too early to analyze the JavaEE 5 arena (I'm sure JBoss, IBM and WebLogic will come with their implementation as well), but the J2EE 1.4 numbers show the trend is true: the JSR-151 specifiation has been out there for almost 3 years and the total number of servers available is less than 50% of its predecessor, J2EE 1.3 - not to mention that many servers took years to be ready. Setting a lightweight JBoss server for web development onlyPosted by felipeal on October 27, 2004 at 09:04 PM | Permalink | Comments (11)A couple of months ago, I had to implement a custom LoginModule to be used by a J2EE application running primarily on JBoss 3.0.8 (bundled with Tomcat 4.1.24). While developing it, I had to restart JBoss on every new progress, in order to test the changes. As my desktop was just a poor Pentium III with 512MB, running all sort of geek stuff (mozilla, emacs, eclipse, many shells, gaim, openoffice, etc...), JBoss started in about 2 minutes and stopped in another 1:30 minutes, totalizing long 4 minutes for every iteration! So, as a good 'lazy developer', I decided to spend some time cleaning JBoss (I was using the default configuration, which loads a lot of stuff that didn't matter to my LoginModule, such as EJB container, Messaging server, EAR deployet, HSQLDB, etc...) and recover that time during each iteration. So here's what I did: 1.Started copying the minimal server configuration to a new configuration called web:cp -a ${JBOSS_HOME}/server/minimal ${JBOSS_HOME}/server/web2.Copied the tomcat41-service.xml from the default configuration:cp ${JBOSS_HOME}/server/default/deploy/tomcat41-service.xml ${JBOSS_HOME}/server/web/deploy3.Copied some JARs from default's lib:cd ${JBOSS_HOME}/server/default/lib; cp jboss.jar tomcat41-service.jar jbosssx.jar ../../web/libAt this point, the new server was already ready for web development, and starting as a breeze: ~felipeal# ${JBOSS_HOME}/bin/run.sh -c webNow I needed to set the authentication stuff: 4.Added new MBeans on jboss-service.xml:
<mbean code="org.jboss.security.plugins.SecurityConfig"
name="jboss.security:name=SecurityConfig">
<attribute name="LoginConfig">jboss.security:service=XMLLoginConfig</attribute>
</mbean>
<mbean code="org.jboss.security.auth.login.XMLLoginConfig"
name="jboss.security:service=XMLLoginConfig">
<attribute name="ConfigResource">login-config.xml</attribute>
</mbean>
<mbean code="org.jboss.security.plugins.JaasSecurityManagerService"
name="jboss.security:service=JaasSecurityManager">
<attribute name="SecurityManagerClassName">
org.jboss.security.plugins.JaasSecurityManager
</attribute>
</mbean>
5.Created the login-config.xml on web/conf, adding my custom LoginModule:
<?xml version='1.0'?>
<!DOCTYPE policy PUBLIC
"-//JBoss//DTD JBOSS Security Config 3.0//EN"
"http://www.jboss.org/j2ee/dtd/security_config.dtd">
<policy>
<!-- put my login module setup here - don't remember the details :-) -->
</policy>
6.(optional) If running on JDK 1.3, it's also necessary to copy jboss-jaas.jar and xalan.jar to lib:cd ${JBOSS_HOME}/server/default/lib; cp jboss-jaas.jar xalan.jar jbosssx.jar ../../web/libThat's it: the new server was ready for quick development cycles (startup and shutdown in about 20s!) | ||
|
|