SeeSaw's blog: Tag java

How to sell fluff to James Gosling...

Paolo — Mon, 18 Sep 2006 00:54:00 -0500

The JavaJournal blog has just published an article on how I sold a funny T-Shirt to James Gosling at the last Italian JavaConference. We had a lot of fun there with the JUG Padova guys… nice to see someone remember the great gig I did :D

JavaJournal is a brand new magazine about Java and Software development. It’s very hard to set up magazines like this in Italy but it seems those guys are motivated and the whole story looks really promising!

I wish you the best JavaJournalers!!! ...and who knows, I could find myself writing for them sooner or later…

Getting MIME type from a file

Michele — Sat, 09 Sep 2006 22:56:00 -0500

It’s pretty simple: just grab activation framework from the web and type:

import javax.activation.MimetypesFileTypeMap;
import java.io.File;
...
File file = new File("WhoAmI.jpg");

System.out.println("MIME type of " +
  file.getName() + " is " +
  new MimetypesFileTypeMap().getContentType(file)
);

The expected output is:

MIME type of WhoAmI.jpg is image/jpeg

simple and effective, isn’t it?

UPDATE: If you want to detect types other than simple images you should integrate the activation framework default list as stated in the javadoc . For example detection of a zip archive can be done by adding this:

MimetypesFileTypeMap mt = new MimetypesFileTypeMap();
mt.addMimeTypes("application/x-zip zip ZIP");

seesaw Series: Java, Ruby and Enterprise

Jacopo Murador — Sat, 24 Jun 2006 15:48:00 -0500

During the last few months I read a lot about Java, Ruby on Rails and enterprise applications. I realized with surprise that these topics were always covered from the technological point of view: scalability, performance, integration and other issues were well addressed and discussed. But something in my mind kept telling me they were somehow heading to the wrong direction. I spent some time thinking and gathering past experiences and came up with a strong belief.

Trust me, technical issues are not the real point about the Java vs RoR debate. Enterprise applications, as the name suggests, are developed in enterprises, not totally-awesome-oh-so-web2.0-startups or long haired communities. Now ask yourself: who’s holding the development keys inside an enterprise? The IT manager. He’s a strange guy, hard to interact with. Doesn’t understand “scalability”, “integration” or “performance”. Doesn’t eat code for lunch. He prefers the sound of terms like “costs”, “investments”, “ROI” and guess what? Money. That’s why I won’t write about the Java vs RoR debat from the IT manager point of view.

Here in SeeSaw we use either Java and Ruby on Rails. We actually do love RoR. We started some project with it and found it invaluable. We’re spending a growing amount of time with rails. But we also love Java. We couldn’t hate it: it helps us pay the bills. In fact the experience tells us that if you want to do consulting with big companies, you’ve got to have Java in your pocket.

Let’s digg this point. An enterprise project differs from the other kinds of projects in team dimension and software lifetime. We’ll call it the five-by-five rule as it usually involves more than five developers and will stay on line at least for five years. In this context the IT manager target is to maintain the highest quality with the lowest costs for the whole software lifetime. How? For the answer add our feed to your news reader ;-)

Ruby@JUGPadova has been a big success!

Paolo — Wed, 24 May 2006 19:34:08 -0500

Hey guys, Paolo and Jacopo held a speech at the last JUG Padova meeting. I can proudly say it has been a big big success!

You can find our photostream here.

We actually love to digg things in public and really seems attendants appreciated our effort. It’s not the first time we’re going public but this event has been somehow special. It gathered more people, more interest, more ideas.

I want to personally thank ChiaroScuro who had enough patience to not kill me during our crazy and tiring weekend.

Well, I guess we’ll repeat this meeting somewere else someday… so stay tuned!

Cannot change charset from 'UTF8' to 'UTF-8'

Paolo — Fri, 14 Apr 2006 15:24:00 -0500

A few months ago I run into a problem using Tapestry over BEA Weblogic 8.1 SP2. During the execution of a beginPageRender I issued a redirection and got a weird:

     org.apache.hivemind.ApplicationRuntimeException: 
     Attempt to change ContentType after calling getWriter() 
     (cannot change charset from 'UTF8' to 'UTF-8')

Many people from the Tapestry mailing list continue to ask me a solution to this problem so I’m posting it here for future reference.

How to trigger the Exception

I couldn’t immediately figure out what was going on but I was pretty sure it was a Weblogic fault, as my app run well under Tomcat.

To simulate the error you can just set up a page like this one:

    public abstract class Test extends     
           org.apache.tapestry.html.BasePage {
      // do nothing, just redirect to Home when invoked
      public Test(){
        addPageBeginRenderListener(new PageBeginRenderListener(){
          public void pageBeginRender(PageEvent event) {
            throw new RedirectException("Home");
          }
        });
      }
    }

I’ve got two html templates: “Home.html” and “Test.html”. both of them do not have components, just plain html. I wanna perform a redirection from Test to Home, so I try to call http://localhost:7001/app?page=Test&service=page. On tomcat this call performs the redirection to the “Home” page without generating errors.

On WLS 81 I got the infamous IllegalStateException “Attempt to change ContentType after calling getWriter() (cannot change charset from ‘UTF8’ to ‘UTF-8’)”

Why does it happen?

It seems that the servletResponse is already committed during redirection. The ServletWebResponse.getPrintWriter(ContentType) method tries to reset the contentType and get a new writer without checking if it needs to or not… Servlet specifications are not clear on this, or at least, server implementations not always behave the same.

Solution 1: Hack Tapestry

This first solution involves a modification of a Tapestry class, so you need to download the source and then rebuild the distribution. This is a way, but I really don’t encourage its adoption as Tapestry is evolving quickly and you could get stuck on your very own hacked version.

This is the solution I submitted to the Tapestry jira too. Modify the ServletWebResponse.getPrintWriter(...) method this way.

     public PrintWriter getPrintWriter(ContentType contentType) throws IOException  {
         Defense.notNull(contentType, "contentType");
         if (_needsReset)
             reset();
         _needsRes et = true;
         if (!_servletResponse.isCommited( ))
              _servletResponse.setContentType(contentType.toString());
          }
         try {
             return _servletResponse.getWriter();
         } catch (IOException ex) {
             throw new ...
         }
     }

This will check if the contentType has already been set or not, and will avoid the Exception to be thrown.

Solution 2: Cheat on it!

A smarter solution is to be less invasive on the Tapestry framework. I’ve chosen to wrap my ServletResponse objects in smarter ones, that can deal with the encoding problem.

So I wrote this:

     public class NotUpsettingHttpServletResponse extends  
                  HttpServletResponseWrapper {
       private boolean gotWriter;
       private boolean gotOutputStream;
       public NotUpsettingHttpServletResponse(HttpServletResponse httpServletResponse) {
         super(httpServletResponse);
       }
       public void setContentType(String contentType) {
         if (isCommitted() || gotWriter || gotOutputStream){
           // skipping response.setContentType(..);");
         } else {
           super.setContentType(contentType);
         }
       }
       public PrintWriter getWriter() throws IOException {
         gotWriter = true;
         return super.getWriter();
       }
       public ServletOutputStream getOutputStream() throws IOException {
         gotOutputStream = true;
         return super.getOutputStream();
       }
     }

And applied it on every call with a ServletFilter like this one:

     public class ContentTypePatchFilter implements Filter  {
       public void init(FilterConfig filterConfig) throws ServletException {
         log.debug("ContenTypePatchFilter started.");
       }
       public void doFilter(ServletRequest servletRequest,
                            ServletResponse servletResponse, 
                            FilterChain filterChain) 
                            throws IOException, ServletException {
         HttpServletResponse res  = (HttpServletResponse) servletResponse;
         NotUpsettingHttpServletResponse myResponse = new NotUpsettingHttpServletResponse(res);
         filterChain.doFilter(servletRequest,myResponse);
       }
    }

Of course the last step is to set up the filter in your web.xml:

      <filter>
        <filter-name>
          contentTypePatchFilter
        </filter-name>
        <filter-class>
          it.seesaw.ContentTypePatchFilter
        </filter-class>
      </filter>

This approach solves the problem. Every response is now smart enough to let your app go without considering unecessary setContentType calls.

Hope this can help all those people who keep contacting me. Let me know if it has worked for you too…