Oh my ! I can't belive it I'm writting this article, this is my first contributtion ever made at any place on the web; (it was really hard for me, but an XBox it's really an incentive!).
Before the race to linux was started (like 1 month before), i discovered this interesting tool, Grasshoper from MainSoft, trust me; very fine tool avaliable here: http://dev.mainsoft.com/.
I played with it for some time and then, whoa !; the race for linux was announced (i was very excited); I had the 1.60 version which caused me some troubles (that i hadn't noticed at first).
I liked a lot the article from Mark Cafazzo for the Linux race, so i will follow his writting a little.
Notes: The demo project file included here is pretended to be a self-contained package, ready to deploy on a tomcat server. But due to limitations of 2Mb file to the article the files
- System.Drawing.jar (Beta version)
had been ripped of the demo project zip (war) file.
For this article you will need:
- A copy of the report starter kit from the guys at asp.net site (http://www.asp.net/)
- A Sql Server database (or MSDE) to host the Reports DB.
- Mainsoft grasshoper (v1.61) downloadable from their site http://dev.mainsoft.com/
- Mainsoft beta modules (primary the System.Drawing beta) from their site
- A java servlet container (an Apache Tomcat version is included with grasshoper)
- Optionally and for the brave ones, a Linux distro (redhat, suse, debian, etc.) to test the final app
To succesfuly port an ASP.NET app to Linux I know of two possible ways: re-code everything, or use a reimplementation of the .NET framework; (personally I think the second one is better and easier). Mono project aims to port the .Net framework so you can use it on other platforms; also Mainsoft has a similar way (they implement the .NET namespace components into java components so the can run in a java enabled environment).
Mainsoft provides us with effective aproach, compiled MSIL assemblies are converted to their similar at java (java bytecode); perfomance is not affected due the fact that they are not recompiled or modified, only translated to that of java.
Once our code is java-enabled bytecode, grasshoper will package it for us to deploy it via a WAR file (basically a zip renamed file which contains the files and assemblies needed for the app to run).
So basically, while our java framework components are named equal to that of the .NET (System, System.Data and so on) we can produce the same app for a java environment.
To port any app from ASP.NET to java i would recommend the following steps:
- Generate J2EE project (via convert or new deployment copy/paste style)
- Familiarize with the code in a sufficient manner to determine what components will need to be reimplemented or to be complemented by a java component. Also analize what of the .NET framework has not been implemented or is not supported.
- Add neccesary components and overcome the missing pieces.
- Compile and see if no warnings or errors are thrown, if they do, repeat the above steps.
- Test you app completely, maybe some pieces may take a different behaviour than expected, if something breaks or malfunction do a DEBUG, get to the point where the code produces an error. Also READ the logs of the server, this can give you very important information of missing and required references or configurations.
- Repeat until your app behaves as the way you need.
- Once the app is working well on the testing environment, create the deployment package and test on at least other server (and preferrably on the final conditions environment).
- Once the problems had been overcome, test again in the final environment.
- Remember to download the System.Drawing beta from mainsoft, instructions on updating this references are here: http://dev.mainsoft.com/Default.aspx?tabid=136, copy the new System.Drawing to the jgac folder and update in your Visual Studio.
- The first thing noticed was the unsupported tags of web.config, for this project this tags weren't neccesary (sessionstate, pages validaterequest, customerrors), so I decided to comment them. Problem solved.
- If you have problems of complaining classes not found also check that the project namespace is correct, my generated project had a generated namespace of Reports_J2EE, so be aware that the project namespace is BLANK in this project.
- Be aware that the debbuging environment in grasshoper has ALL the dependencies at the server level. If you don't set references to the MSSQL jars it will function anyway; BUT for the deployment war file they will not be included. Make sure to add references to msbase.jar and msutil.jar; also when you create the final deployment war make sure you select Create self-contained package.
- Change the connection string in web.config so it points to the real db server and recompile, i was getting errors because my db was hosted on an other machine.
- At ChartGenerator.aspx.vb line 33 reads "Environment.UserDomainName.ToLower", if this function is causing troubles comment it.
- At the time of the first deployment i had this ugly representation because in Linux files are CASE SENSITIVE, make sure to rename Docs to docs, Images to images, and so on with the things you would think are not displayed correctly.
- I had a problem with the chart (visual report), that was caused by a version problem of grasshoper, I was testing on my development environment and didn't produce the graphics at ChartGenerator, MAKE SURE you have 1.61 version of grasshoper and the new System.Drawing component.
- Have an eye on this, if you deploy to a tomcat server on a Linux machine, and it is a windowless enviroment, add CATALINA_OPTS="-Djava.awt.headless=true" to the shell that is launching tomcat. If not you will not see charts and images. This is an issue of java.awt
Configure and deploy to Linux Machine
Installing Linux (at any flavor) is out of the scope of this this article, however you may find it useful if you google for "Installing Linux" or vitis here: http://www.tldp.org/LDP/gs/gs.html
Installing Linux has been made easy by the Linux providers, almost any distro has a graphical interface and should not be very hard to complete the process. As an alternative you can try Linux inside Windows from Mainsoft, avaliable at "Linux Tools" at their download site; as well you may try a virtual machine environment as VMWare if you like.
Virtual Machine environment also has the advantage that you can make a mistake and nothing fatal ocurrs, you just start from beggining.
To install the tomcat server in your linux box depends on the distribution you have chosen, you can use YaST or RPMs which are the package managers for applications on your linux machine.
For Suse you can open the YaST control center an select to install
Which will enable you with the java required environment, if the manager complains about dependencies install them.
After installing tomcat make sure to start the tomcat service, the most generic way is
but also for Redhat/Fedora
will do the job.
If your environment does not support YaST but does RPM this url may also be useful: http://mirrors.sunsite.dk/jpackage/1.5/generic/free/RPMS/
Once your tomcat is running you can test it on http://localhost:8080/, if you see that funny cat you are up and running. Test also the samples given onthe welcome page.
Your server-wide administrator for tomcat can be viewed at http://localhost:8080/admin, be sure to edit the "tomcat-users.xml" file at the config directory and that the groups manager and admin exists.
Your deployment web based tool is at http://localhost:8080/manager/html, you can deploy your war file here or deploy a directoy based app.
Once your war is deployed test it, voila !; your app is up and running in tomcat server.
For the bravest ones one final step is required, make it run on apache with the mod_jk or mod_jk2 connectors to have a real world java based app.
Additional installing instructions for other servers can be found here: http://dev.mainsoft.com/Default.aspx?tabid=32&src=ww_PackagingDistributingModules.html
Happy porting !