Felipe Leme's Blog: J2EE Archives

Posted by felipeal on June 25, 2007 at 09:52 AM | Permalink | Comments (6)

I have taught Java and web-tier (Servlets/JSP/taglibs) development to about 10 classes over the last 3 years. And everytime I teach servlet attributes, I face the same situation: first I explain what request attributes are, why they are useful, and which methods you use to manipulate them. Then, when I teach session, I have to explain that it has a similar concept, with the exact same methods. And when I get to the ServletContext topic - well, you got the picture...

Now, to make things worse, the Servlet API is taught a couple of weeks after the OO concepts, like interface. It's already hard to explain interfaces for people coming from non-OO backgrounds (you have to explain many concepts and analogies, like 'interfaces are contracts', 'an interface defines methods signatures that classes must implement', and so on...), and when they are finally understanding it, they face a situation where an interface would make sense, but it's not used.

So, putting A and B together, there should be an interface defining an object that handles user attributes, and both ServletRequest, HttpSession, ServletContext, and PageContext (from JSP) would implement it. Something like AttributeContainer (which is a bad name as container has zillions other meanings on Java EE), AttributeHolder, AttributeStore, etc (I honestly cannot think about a nice name for it).

This is a very simple change, as the classes already have the methods - it's just a matter of "making the contract official" by defining such interface. In fact, it's so simple that I believe the previous EG didn't think it would worth the effort (I had suggested it before, I believe in the 2.5 timframe) - they might think it doesn't bring enough value.

But I can guarantee it would help in at least 3 scenarios:

Teaching attributes on Servlet courses
Teaching interfaces (once you reach the attributes class, this is a good example of interface use)

Provide an easy (although not necessarily more efficient) way to write code that store attribute in many different scopes (like JSTL set tag):



public void set( String var, String scope, Object value ) {
  AttributeHolder holder = attHolders.getHolder( scope );
  if ( holder == null ) {
    throw new BlaBlaException( "invalid scope: " + scope );
  }
  holder.setAttribute( var, value );
}

I know the EG has more serious issues to handle, but this is a minor one, which would not hurt anyone. Besides, this is a new major spec release (3.0), so that's a good time to include some change (it could even deprecate the method that return the attribute names in an Enumeration, and provide an additional method that uses a Set, for instance).

SOIA - Specfiy Once, Implement Anywhere

Posted by felipeal on June 23, 2005 at 06:36 AM | Permalink | Comments (1)

Have you ever wondered how hard would it be to switch the implementation for a JCP-based technology? Theoretically, it should be easy as changing the skin of your MP3 player. Unfortunately, that has not being the case for most of the J2EE technologies, specially EJBs.

Last Monday I finished the JSF port of the application we are usign for our BOF at JavaOne. Our originally plan was to port an existing webapp to different MVC frameworks, including JSF RI and MyFaces. As the clock was ticking (our presentation is a week away and we are departuring today) and I hadn't even finished the JSF RI version, we pratically gave up the MyFaces port.

Anyway, last night I decided to give it a try while watching a soccer game (that's one of the best uses of a laptop system :-). And how wasn't my surprise to finish the job just before the half time (and that becuase most of time was spent downloading the software!): all that it took to switch RI for MyFaces was to add a few lines on web.xml and replace half a dozen jars!

That's right: no changes on JSPs, backing-beans or even faces-config.xml; just add a listener on the deployment descriptor (and replace the jars, of course) and you're done!br>
Still don't believe me? Well, take a look on the diff between the 2 projects then:


[felipeal@localhost webapps]$ diff -r jsf-project myfaces-project
Only in myfaces-project/WEB-INF/lib: commons-el.jar
Only in myfaces-project/WEB-INF/lib: commons-validator.jar
Only in myfaces-project/WEB-INF/lib: myfaces.jar
Only in jsf-project/WEB-INF/lib: jsf-api.jar
Only in jsf-project/WEB-INF/lib: jsf-impl.jar
Only in jsf-project/WEB-INF/lib: jstl.jar
Only in jsf-project/WEB-INF/lib: standard.jar
diff -r jsf-project/WEB-INF/web.xml myfaces-project/WEB-INF/web.xml
27a28,33
>
>
>  
>    org.apache.myfaces.webapp.StartupServletContextListener
>  
>

Of course, we have to take in account that our application was very simple: just 3 JSP pages and 2 backing beans. Still, the transition from one implementation to another was very smooth, much more than we predicted.

Setting a lightweight JBoss server for web development only

Posted 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/web

2.Copied the tomcat41-service.xml from the default configuration:

cp ${JBOSS_HOME}/server/default/deploy/tomcat41-service.xml ${JBOSS_HOME}/server/web/deploy

3.Copied some JARs from default's lib:

cd ${JBOSS_HOME}/server/default/lib; cp jboss.jar tomcat41-service.jar jbosssx.jar ../../web/lib

At this point, the new server was already ready for web development, and starting as a breeze:

~felipeal# ${JBOSS_HOME}/bin/run.sh -c web

...

...

00:25:43,280 INFO  [Server] JBoss (MX MicroKernel) [3.0.8 (CVSTag=JBoss_3_0_8 Date=200306050849)] Started in 0m:7s:303ms

Now 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/lib

That's it: the new server was ready for quick development cycles (startup and shutdown in about 20s!)

Maven 1.0 released

Posted by felipeal on July 13, 2004 at 04:38 AM | Permalink | Comments (1)

I haven't blogged in a while - even after attending Java One 2004, which is source for blogging heaven - but I couldn't let this date pass on without making some noise.
From Maven's main page:


Maven 1.0 Released - 13 July 2004



Maven 1.0 has been released.

Download | Installation Instructions | Release Notes

'Nuff said..

Felipe

PS: and, of course, congratulations to the whole Maven team :-)

When LinkedIn met JSTL

Posted by felipeal on March 26, 2004 at 08:09 PM | Permalink | Comments (5)

JSTL's SQL and XML are controversial taglibs. A lot of people complain they hurt the MVC principles, while others defend they can be useful in some situations (specially on protoypes and small projects). The truth is, both sides are right: it can causes great havoc in a MVC-based application, but it is an invaluable tool in small, time-limited projects like the one shown below

Now let's forget JSTL for a while and talk about LinkedIn, which is the motivation for this blog entry. For those who don't know it yet, LinkedIn is a tool/site for social networking management. I joined the site a couple of months ago, invited by an old college friend. Although I was skeptical about the technology in the beginning, I slowly realized it was a nice way to keep in touch with old friends - or even strengthen my relationship with new ones.

My favorite way of using LinkedIn is browsing throughout my connections' connections looking for known folks. Once I found one, I invite him to be a direction connection of mine. There are 2 ways to ask for a connection: sending a request indirectly through LinkedIn or directly by email.

Sending a request is LinkedIn's core business. It would allow you, for instance, to propose a business deal to some one you don't personally know (but is indirectly "linked" with you through your connections) and LinkedIn would charge for the service. Although I think its a nice feature and a clever business plan, it is an overkill process if you just want to get a connection with someone you already know. So, in this case, it's much simpler to just send an email message to that person. The only drawback in this approach is that many times you don't know (or don't remember) that person's email address - and that's where my JSTL-based project can be handy.

The project's goal is pretty simple and straightforward: provide a repository of names and email address of LinkedIn users that know each other somehow (for instance, my Alumni class or java.net community users). Once a name is listed, you can just click on its email address and you will be redirected to LinkedIn's invitation page (with all fields already filled). (ERRATA: this part is highlighted because it has been missing from the original blog)

Considering the project's level of importance (it could be classified as "useless geek tools"), it has to be easy to use and even easier to implement (in fact, I spent more time configuring MySQL and writing this blog than developing the project). In other words, it's a typical example of application that could be written using JSTL's Core and SQL tags.

The application consists of only 2 database tables (users and communities) and 3 JSP pages:

index.jsp - protected page (user must login before accessing it), allows an user to add himself to the community or send an invitation to other users
login.jsp - welcome page where the user selects with community he would like to access (it's necessary to know the community's password)
listUsers.jsp - list all users in a community, with a link for posting a LinkedIn invitation to each user (this page is included from index.jsp

Here are some code snippets (the whole "source" can be found here):

<%-- check if user is logged on --%>


   


<%-- check if user already exists in this community --%>
        
           SELECT * FROM users WHERE email = ? AND community_id = ? 
           
           
        
        
           
        

<%-- handle submission --%>

   
   
   
      
         
      

      
        
           SELECT * FROM communities WHERE id = ? AND password = ?

Finally, the application URL is http://felipeal.net/liar/index.jsp. If you had the patience to read this lengthy blog till this point, please give it a try - the password for java.net is CafeBabe.

JavaServer Faces specification finally approved

Posted by felipeal on March 03, 2004 at 04:46 PM | Permalink | Comments (3)

The JCP committee approved the final specification for JSR 127. In other words, the long awaited JSF (JavaServer Faces) has finally left its specification stage.

There is a lot of expectation about JSF and the problems it will solve (or create). Some people are excited with the technology, others are worried it would compete with frameworks like Struts, while other are just skeptical if its really that panacea.

In my opinion, it has the potential to be a good technology, specially with the support IDE vendors are giving to it (for instance, JDeveloper 9.0.5 supports it and Sun's-IDE-formerly-know-as-Project-Rave is based on JSF), but it's still early to take any conclusion. So, only time will tell, and hence a final JSR specification is a first step in this direction...

PS: the process took so long that even Sun recognized it when they vote for it:

On 2004-02-17 Sun Microsystems, Inc. voted Yes with the following comment:
This has been a long road. I'm glad to see this important JSR coming in for final approval!

ASF's comment was even funnier:

On 2004-02-24 Apache Software Foundation voted Yes with the following comment:
Is it really done? :)

JSTL 1.1 RI is out

Posted by felipeal on January 30, 2004 at 01:53 PM | Permalink | Comments (3)

Jakarta Standard Taglib is the Reference Implementation (RI) for the JSTL specification (JSR 52).

JSTL 1.1 reached it's final specification a couple of months ago (as I reported here), so now it's time for an official RI release.

Most of the JSTL 1.1 work has been done prior to 1.1.0-beta1 - this release just fixed a couple of bugs. So, the previous release was stable, but it couldn't be called "official" as the spec was not final yet (that's the same reason why Tomcat 5 was still in beta, even after many 5.0.x releases).

We also released Standard 1.0.5, which has the same bugs fixed for 1.1.0 ported to the JSTL 1.0 trunk (a list of all bugs fixed can be found in the Release Notes.

Extra! Extra! Lomboz has gone open source!

Posted by felipeal on January 22, 2004 at 11:23 AM | Permalink | Comments (7)

Lomboz - a J2EE plug-in for Eclipse - has become open source. That is great news for the Eclipse and Open Source communities.

A couple of days ago I was browsing the Web to get more information about JOnAS and JORAM. As both products are offered by the same entity (ObjectWeb), I decided to take a look at their repository. Then, once I clicked on that link, I got the suprise: it said Lomboz was their top download project for the last 30 days!!!

If you do not understand my reaction let me tell a little bit of history: one of the main complaints about Eclipse is the lack of a free (as free-speech) J2EE plug-in, especially something that offered JSP editing and debugging capabilities. So, if you wanted a fully-integrated J2EE environment on top on Eclipse, you would need to install MyEclipseIde (which is an awesome product, but not free) or Lomboz (which was free but as free-beer, but not as free-speech). I think MyEclipseIDE is a better product, although Lomboz is more popular because it is free. But even though it was free, Lomboz had many limitations and bugs that couldn't be fixed by the community (as it was a closed-source product). To make things even more complicated, Lomboz was hosted on SourceForge, which would suggest it was indeed open-source (but the truth is that they used SF resources only for forums and bug reporting).

What intrigues me most though (and hence the reason I am posting this message) is the fact that Lomboz transition to the OSS (Open Source Software) world has not been heralded as someone would expect - in fact, if you google for "Lomboz Open source", the only notification you will find is Eteration's news page, which does not even mentioned *when* that happened.

I like Eclipse - and that comes from a Emacs junkie, whose favorite IDE is called JDK. It's the only IDE that have a nice look feel on Linux, for instance. But the fact that you have to install a lot of plug-ins to make it fully-productive is a pain. Specially when a plug-in breaks something and then you have to re-install Eclipse (and all the plug-ins).

So, now that one of the last pieces of the puzzle has been found, I think it is time for an OSS project that creates an Eclipse distribution bundled with a couple of nice OSS plug-ins (like Lomboz, XMen, JFaceJDBC, etc..) integrated with bundled servers (like JBoss, Tomcat, HSQLDB, etc). We could even call it something like ESAD (Eclipse Studio Application Development) or EIE (Eclipse Integrated Environment) - although I think the first option would have some brand/copyright issues :-).

More JSR announcements

Posted by felipeal on November 25, 2003 at 09:18 AM | Permalink | Comments (0)

As I said in my previous weblog, more J2EE-related JSR final releases would be announced soon. And here they are:

NOTE: if eventually more of those JSRs are released today, I will update this blog (instead of creating another one)

JSR announcements

Posted by felipeal on November 25, 2003 at 04:45 AM | Permalink | Comments (0)

As a subscriber to the jcp-interest mailing lists, I receive many JCP/JSR announcements. In particular, everytime a JSR changes its status, I got an email about that change.

Sometimes it take weeks to get a simple message, while at other times you got a bunch of them at once. And yesterday was one these days: I got a batch of messages regarding final releases, 4 of them related to the upcoming J2EE 1.4:

JSR 151 - Java 2 Platform, Enterprise Edition 1.4 (J2EE 1.4) Specification
JSR 154 - Java Servlet 2.4 Specification
JSR 52 - A Standard Tag Library for JavaServer Pages (final release for JSTL 1.1, a maintenance release)
JSR 115 - Java Authorization Contract for Containers

These are great news: once all specifications are final (there are still a few missing, like JSR 152 - JavaServer Pages 2.0 Specification and JSR 153 - Enterprise JavaBeans 2.1), the J2EE vendors can release their J2EE 1.4 compliant servers.

So, if you'd like to receive the latest JCP/JSR news, give the JCP-interest mailing list a try. Note that this list is open to everybody, so you don't need to be a JCP member to have access to it (although you are automatically subscribed once you become a member).

NOTE: the other JSRs mentioned were released a few hours after I finished this blog, so I posted another one

It's time to move on

Posted by felipeal on October 05, 2003 at 08:16 PM | Permalink | Comments (11)

There's been a lot of talk lately about how Tiger (J2SE 1.5) is going to make Java easier to develop with, bringing it to the masses (or as Sun call it, to the "corporate developers"). I have no doubt that this promise *will* be fullfilled. My question is: *when* will that happen?

I'm not even talking about Tiger's release schedule here - although I'm also afraid it's is a little bit late already. My main concern is how long it will take for this release to be used by commercial products. Take as example J2SE 1.4: it's been available for years, and a lot of products - specially J2EE servers - still uses 1.3. I understand the fear of using a new major release right after it's available, but gee, we are talking about a very stable product, which recently reached it's 3rd version (1.4.2).

This "late adoption" trend is really bad: there is dozens of cool features available on 1.4 (like assert, logging and nio) that can't be used in many projects because they are bound on 1.3. That's not to mention the minor improvements, like new methods on existing classes that causes hard-to-debug NoSuchMethodException when you a deploy a class compiled with 1.4 in a 1.3 JVM. And now with Tiger and its language changes, this situation can be even worse, as the IDEs have to adapt themselves to these changes...

So, in order to reach the 10M developers mark, it's necessary a bigger effort than just providing new tools and APIs: it's necessary to move on!

Running ant in loop mode

Posted by felipeal on September 02, 2003 at 09:31 AM | Permalink | Comments (9)

Once in a while I work in a Java project where I need to run a simple Ant task many times in a short period of time. Like web projects where the JSP files are located in a directory under source control and are deployed in another directory by an Ant task. If I change a JSP file, I need to run Ant again, and it takes an eternity (about 5-6 seconds), due to the overhead of running the JVM, reading the XML files, etc...

Wouldn't it be nice if I could leave Ant running in a loop mode in those situations, so when I change the file I could redeploy it without that overhead?

For me, the answer is "Yes, that would be nice". But Ant doesn't have that feature, so now what? Now I can change Ant to include that feature, and that is the beauty of open source projects: if you want a new feature, you can just grab the code and implement it yourself. The same with bugs: rather than wait for the vendor to fix, test and publish a patch, you can open the code and nail the bug!

Now back to that new Ant feature: I created such patch and opened a bug for it.

We've been using it for a while in my team, and so far it's working fine. It's not in the basecode of Ant yet - and it might never be - so I upload the code to my site. If you liked the idea, please feel free to download it and give it a try. And if you like the results, give me some feedback through the bug's page or this weblog.

Powered by
Movable Type 3.01D

java.net RSS Feeds