Saturday Mar 25, 2006

BIRT and GlassFish b41

The BIRT project includes a web application for displaying reports. After some fits and starts, folks have been able to get it working on GlassFish. While folks were able to get it working, I did not like the "solution". I spent a bit of time with BIRT 2.0.1 and build 41 to see if I could get a better solution.

I have been able to deploy 2.0.1 on GlassFish build 41, by following the instructions for JBoss, with a couple small changes:

  • I used the asadmin deploydir command, instead of copying files to a deploy directory. GlassFish has an autodeploy directory, but it expects archives to be placed there, not "exploded" archives.
  • I did not need to copy the files from Axis 1.2.1, listed in the instructions. It looks like the files are already there in the 2.0.1 release.
  • I created a <BIRT-ROOT>/WEB-INF/sun-web.xml file. It looked like this:
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd">
    <sun-web-app error-url="">
      <context-root>/birt-viewer</context-root>
      <class-loader delegate="false"/>
      <jsp-config>
        <property name="classdebuginfo" value="true">
          <description>Enable debug info compilation in the generated servlet class</description>
        </property>
        <property name="mappedfile" value="true">
          <description>Maintain a one-to-one correspondence between static content and the generated servlet class' java code</description>
        </property>
      </jsp-config>
    </sun-web-app>
    
  • I did need to copy commons-logging-1.0.4.jar from Axis 1.2.1, into <BIRT-ROOT>/WEB-INF/lib.
  • I had to copy the derby.jar from <BIRT-ROOT>/plugins/org.eclipse.birt.report.data.oda.jdbc to <BIRT-ROOT>/WEB-INF/lib

After doing this, I was able to view the "installation report" and the "more complex report".

Saturday Mar 11, 2006

AppFuse and Build 40

This is just a quick note, to let people know that AppFuse 1.9 (Struts/Spring/Hibernate configuration) is working with build 40. Folks will be pleased to note that disabling the security manager made many of the steps I outlined unnecessary.

I am working on entries that provide more details. Look for them in the next couple of days.

Tuesday Mar 07, 2006

Forum posting regarding Adobe's Flex 2.0 Beta on SJSAS 8

Around 1 Feb 2006, folks at Adobe released the Flex 2.0 beta. Since there was a web app associated with it, I decided to try to deploy it to GlassFish.

I wasn't too successful and "real work" diverted my attention from getting Flex 2.0 functional. I was able to share some tips with another Beta tester who was able to make more progress according to this thread.

Friday Mar 03, 2006

Autodeploy classes at your own risk...

I have noticed a number of people having issues with using autodeploy. I think they may be following the "advice" of entries/articles like this or this.

Extending the methodology espoused by these entries hasn't been well tested. It is a great trick for demos and examples, but it doesn't scale. You may want to read through this book for more details about the numerous deployment strategies that are supported by application servers, based on the GlassFish Project's code-base. This section is particularly important. The autodeploy mechanism is designed to work with archive files.

Wednesday Mar 01, 2006

Top of the Pops in Santa Clara; Empathy for Developers

Sorry, Mick, Keith, Brian, Bill, and Charlie. I could not resist.

A number of people have run into issues deploying and running applications on GlassFish, due to the security manager. You can read some of the stories by clicking on the linked blogs and articles that you can find here.

Well, those GlassFish hatchery workers (oft times known as software engineers in other parts of the world) have seen the pains that the security manager has wrought on developers. Since the goal of Java EE 5 is 'Ease of Development', they have decided to use a null default security manager...

This will make deployment and execution of applications that use many popular frameworks MUCH easier. Petr Blaha also discovered another benefit of running the application server without the security manager.

As Ludo commented, look for the this important EOD change in promoted build 39, which is coming soon.

Wednesday Feb 08, 2006

Custom client policies for JWS App Clients

I noticed this thread in the GlassFish forums, this moring. I am sure that Tim will blog about this in greater detail, but this thread has a quick preview for the impatient.

Good news for WebWork users

One of my co-workers has been able to deploy a large app built on WebWork to GlassFish.

He ran into some security policy issues during deployment and testing. His blog entry has the details.

About


Vince Kraemer writes the entries in this blog.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News
Blogroll

No bookmarks in folder

automarks