Marco's Corner

We found out that the Sun Java Enterprise System WebServer 6.1 has a upload limit of 10 MByte for web applications. Apparently we were very close to that limit for some time without knowing about it. But when you add a WebService or EJB client to a Creator application, all the support jar files will bring the size over that limit.

The solution is to reconfigure the WebServer’s admin application to allow bigger uploads. Simply do the following when you see the problem:

• Stop the WebServer admin server.

• Back the <WS_HOME>/bin/https/webapps/admin-app/WEB-INF/web.xml up!

• Add the following init-param to the webappdeploy servlet.

  $ diff -uwb web.xml.orig web.xml
  --- web.xml.orig        2003-08-05 01:47:00.000000000 -0700
  +++ web.xml     2005-09-14 11:40:46.000000000 -0700
  @@ -151,6 +151,10 @@
  <servlet>
  <servlet-name> webappdeploy </servlet-name>
  <servlet-class> com.sun.web.admin.servlets.DeployServlet </servlet-class>
  +    <init-param>
  +      <param-name>maxUploadSize</param-name>
  +      <param-value>20000000</param-value>
  +    </init-param>
  </servlet>
  <servlet>
  

• Start the WebServer admin server and all the target servers.

Thanks to M. Kapur for this information.

I hope this helps a couple of people.

Not too much;-) At least not much the average user will see.

We added Remote Deployment support for the Sun Java System Portal Server 6.3 on top of the Application Server 8.1. If you happen to want to play with that on Solaris or Linux. Remote deployment is not really a good description, because the Portal Server and Creator have to be on the same machine.

We tested it with the Java Enterprise System 3 and the upcomming JES 4. The newer version has a couple of problems fixed so I would suggest to wait for that if you can.

But there is one big problem. The Portal Server was not designed to interact well with tools like Creator. The only way we found to deploy to it, is to run a script as the user under which the Portal Server was originally installed (usually root).

There are two ways to handle that problem:

• Use the sudo command to run the deploy-script. That’s the solution I would prefer. But it needs some preparation. More about that below.

• Run Creator completely as root (root seems to be the default user for Java Enterprise System/Portal Server installs). But Creator was not really intended or tested for that.

Setting up the sudo environment

The sudo setup has to be done by the admin/root of your system! So, please switch to root before you try to do any of the following steps.

Sudo is installed by default on most Linux systems. Or if not, you can usually find it on your installation media.

Solaris does not have sudo out-of-the-box. You can build it yourself (Find the sources here!) or you can find a prebuilt package on the Companion CD (Solaris Freeware download).

The Creator EA2 will look in /usr/bin and /bin for sudo (Sorry, I realized too late that there is the Sun FreeWare package which installs the binary into /opt/sfw/bin. That path is already added for the next version of our sources.), so please make sure, the command is found there (ln -s might be your friend;-)

Use the visudo command to add a line to the sudoers file. It should look like:

<creator_user> ALL = NOPASSWD: <creator_home>/rave2.0/bin/ps6-deploy.sh

<creator_user> should be your normal user and <creator_home> the directory, where this user installed Creator.

That line in the sudoers file will allow the user to run one shell script as root without requiring a password. I suggest that you look at the script to make sure, we did not miss anything bad!

If you don’t add this line and Creator finds the sudo command, Creator will try to use sudo anyhow and that would ask for a password on the terminal where you started Creator, if you started Creator in a terminal! I don’t know what sudowould do when it was not run in a tty!

Deploying to a Portal Server

After sudois set up (or if you are running as root), simply add a Portal Server to the Remote Servers node in the Server Navigator.

Develop and test your portlet as you normally would and in the end, use the Deploy to Remote Server context action and select the added Portal Server. That should do it.

Ok, again: If you want to play with the Portal Server, feel free. But this was not extensively tested for EA2!

Have fun;-)

Creator uses a lot of features in the JDBC 3.0 specification to create a good design time experience. For instance it uses table metadata to prepopulate the columns in the table component. But not all JDBC drivers support everything we would need and especially the Oracle JDBC drivers don’t give us the metadata when we need them.

That’s normally not a problem because Creator comes with a set of JDBC drivers, which will be used at design time and for the internal deployments. But those drivers are licensed only with Creator or with the Sun Java Enterprise System’s Application or Web Server’s. So if you want to deploy the application to a different container, you’ll have to find JDBC driver’s.

You don’t have to use the same drivers for the development and deployment. So it’s ok, to use Creator’s Oracle drivers at design time and Oracle’s set for the deployment. You could even use a completely different DB as long as the table layout etc. is the same;-)

I (or our SQA) tested the following drivers with a Oracle 9i database:

• The Oracle JDBC drivers version 10.2.0.1.0 against a SJS Application Server PE 8.1 and Tomcat 5.5.9. They work fine but need a bit more preparation for updates. Try the following steps if you see

  java.sql.SQLException: attempt to update a row that has been updated or deleted by another user
  

  in the server’s log from the commitChanges() call:

  • After you’ve dropped your DataSource onto the project, go to the SessionBean source of that project and expand it’s constructor.

  • Add something like to following code after the Creator inserted initialization code:

    try {
    RowSet.setColumnTableNames(new String[]
    { ", ... });
    } catch(Exception e) {
    throw e instanceof FacesException ?
    (FacesException) e :
    new FacesException(e);
    }
    

  That should help for the update problem. Please let us know here or better in the Creator forum, if you still have problems.

• The JDBC drivers included with the BEA WebLogic 8.1.4. They work similar to the Oracle drivers above and you might also need the little extra code.

• The Oranox drivers from i-net software. I tested them in my Tomcat 5.5.9 installation. They did not seem to need the extra code for the DB updates.

I configured Tomcat in it’s global server.xml. I don’t know if that’s the best way, but it was certainly the easiest way. It looked like:

<!--
-->

Of cource, Oracle is only one database but I believe the general idea of possibly using different JDBC drivers will work for others as well.

This came up in the forum over the last week.

The easiest way to get access to native code from a Creator application is when that code can be handled as a global resource similar to a JDBC driver jar.

I created a little test case today (on Linux) and that seemed to work after the following steps:

• Created a libmarco.so and libmarco.jar, The Java code does a

  static { System.loadLibrary("marco"); }

• Copied both into /SunAppServer8/lib to make the appserver happy. This might be a different directory for other containers!

• For Creator set the LD_LIBRARY_PATH to the directory where the libmarco.so is. (Is this PATH for Windows?)

• For the project, add the libmarco.jar as library for the design time only! I believe that can somehow be added to a customized template if it’s needed in more than one project.

• Use the library (mine just returns a String from the native side;-) and deploy the application.

That worked for me;-)

Trying to handle a native library as part of a WebApplication is probably a lot harder. Things to watch out for would at least include:

• The Java wrapper code has to find the native library relative to it’s classloader.

• The security manager of the container will probably have to be changed to allow loading of native libraries from applications.

• The initialization code on the native side and the Java side have to be able to handle `redeployments’.

• What would the container do when an undeploy attempt tries to delete a loaded native library?

So overall I don’t think that would be a good idea.

I hope this helps a bit;-)

Ok, first off: We don’t claim to support FC4 but since Creator and it’s components are mostly Java, it should still work, right? I don’t know if my SuSE Linux systems are officially supported either. But I know that people try different flavors of Linux until they find one they like. So why not help them a bit?

The solution is a bit long, because FC4 doesn’t really like the J2SE 1.4, so a couple of steps normally done at the end of the install, have to be done by hand.

1. Make sure, you have the following packages installed. Otherwise the installer will not even start.

   • xorg-x11-deprecated-libs
   • compat-libstdc++

2. Install Creator 2ea. That will complain, that it can’t start the AppServer etc. That’s ok for now.

3. Add the -Djava.net.preferIPv4Stack=true option to the following files:

   • <CREATOR_HOME>/SunAppServer8/pointbase/tools/serveroption/startserver.sh – last line
   • <CREATOR_HOME>/SunAppServer8/bin/asadmin – last line
   • <CREATOR_HOME>/SunAppServer8/domains/creator/config/domain.xml – As a new <jvm-options/> element
   • <CREATOR_HOME>/SunAppServer8/imq/bin/imqbrokerd – to the _jvm_args variable
   • <CREATOR_HOME>/rave2.0/startup/bin/run-sql-bundled.sh – last line
   • <CREATOR_HOME>/etc/netbeans.conf – to the netbeans_default_options with the -J prefix!!

4. Populate the examples etc:

   • Go to <CREATOR_HOME>/bin
   • run ./pe-start.sh
   • run ./db-start.sh
   • run ./create-travel-db.sh
   • run ./deploy-ejbs.sh
   • run ./deplo-ws.sh

5. Finally, run ./creator and enjoy!

I hope that helps a bit.

Update for Creator 2 Final (Wed Jan 25 11:15:31 PST 2006):

We switched to JSE 5.0 for Creator 2 EA2 and Final. So all the hand editing is not needed any longer!

Have fun.
– Marco