Felipe Leme's Blog: Open Source Archives

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 :-)

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 :-).

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