hi I've no experience with deployment of java webapps to web servers. The whole servlet/container/enterpriseserver/xml thing always looked scary to me...
Is this easier with fan?
Is there a guide for deploying weblets to tomcat or resin?
thanks ben
brianSun 8 Feb 2009
Is this easier with fan?
I hope so!
Is there a guide for deploying weblets to tomcat or resin?
The way Fan is designed is that the APIs in web define the standard way to process HTTP requests. These APIs are designed to be implemented in various ways such as within a Java servlet or potentially using .NET in IIS. You might consider these APIs Fan's "servlet API" - the core APIs which glue Fan code to a given web server environment.
At one point we had the web APIs mapped to work within a Java servlet so that you could run within Tomcat. However, we don't have this working right now. With the Java FFI this should be much easier to do. If someone wants to do this work, I would love to merge it back into the main trunk.
But Fan includes a default implementation of the web APIs called "wisp". This is a full HTTP 1.1 web server which doesn't require any extra stuff like Tomcat etc. We use wisp directly in our production environments. For example this site is being run with wisp behind an Apache proxy.
When you run the bundled web examples you are using wisp directly.
The web API is the core layer of the web framework stack. It is pretty stable (although I had to make some changes to the Cookie API for next build). The webapp APIs are built upon web to add widgets and a series of reusable steps - this framework is still in development and in flux. Then Andy is working on the ability to compile Fan directly to JavaScript which lets you write your server side and client side in Fan in a single source file (very slick). So its all coming together pretty nicely.
jakbSun 8 Feb 2009
brian, thanks for the info. I know proxy solutions from other environments too (Ruby) and I guess it's a solution where a lot of people are used to. Maybe you could make an article like "Setting up Fan and Apache proxy"
And another thing, is there a chance you could make the code for this site (fandev.org) open? ben
brianMon 9 Feb 2009
I agree, docs on various setup fan websites would be very handy
our plan is to eventually release sidewalk (the code for this site) as open source, but it isn't really in a releasable state right now
jakbMon 9 Feb 2009
I think it would be useful, to have at least one guide for starters. Maybe you could tell us a bit more about your apache/fan setup.
this would be better than nothing :-)
f00biebletchTue 10 Feb 2009
We do need some formal docs on this, too true. Here's a brief overview of how to do it with apache2 in ubuntu; at one point we had fandev behind apache and this is all I did.
I've assumed you've installed apache2. Install and enable the proxy module for apache2
You can put this in a vhost or in the main apache conf file, that is a matter of taste/need. This assumes you have wisp running on 8888, you can of course change the port so long as it does not conflict with apache.
I can put more detailed information in some doc when we get to it, but here are some other sites that may help:
jakb Sun 8 Feb 2009
hi I've no experience with deployment of java webapps to web servers. The whole servlet/container/enterpriseserver/xml thing always looked scary to me...
Is this easier with fan?
Is there a guide for deploying weblets to tomcat or resin?
thanks ben
brian Sun 8 Feb 2009
I hope so!
The way Fan is designed is that the APIs in web define the standard way to process HTTP requests. These APIs are designed to be implemented in various ways such as within a Java servlet or potentially using .NET in IIS. You might consider these APIs Fan's "servlet API" - the core APIs which glue Fan code to a given web server environment.
At one point we had the web APIs mapped to work within a Java servlet so that you could run within Tomcat. However, we don't have this working right now. With the Java FFI this should be much easier to do. If someone wants to do this work, I would love to merge it back into the main trunk.
But Fan includes a default implementation of the web APIs called "wisp". This is a full HTTP 1.1 web server which doesn't require any extra stuff like Tomcat etc. We use wisp directly in our production environments. For example this site is being run with wisp behind an Apache proxy.
When you run the bundled web examples you are using wisp directly.
The web API is the core layer of the web framework stack. It is pretty stable (although I had to make some changes to the Cookie API for next build). The webapp APIs are built upon web to add widgets and a series of reusable steps - this framework is still in development and in flux. Then Andy is working on the ability to compile Fan directly to JavaScript which lets you write your server side and client side in Fan in a single source file (very slick). So its all coming together pretty nicely.
jakb Sun 8 Feb 2009
brian, thanks for the info. I know proxy solutions from other environments too (Ruby) and I guess it's a solution where a lot of people are used to. Maybe you could make an article like "Setting up Fan and Apache proxy"
And another thing, is there a chance you could make the code for this site (fandev.org) open? ben
brian Mon 9 Feb 2009
I agree, docs on various setup fan websites would be very handy
our plan is to eventually release sidewalk (the code for this site) as open source, but it isn't really in a releasable state right now
jakb Mon 9 Feb 2009
I think it would be useful, to have at least one guide for starters. Maybe you could tell us a bit more about your apache/fan setup.
this would be better than nothing :-)
f00biebletch Tue 10 Feb 2009
We do need some formal docs on this, too true. Here's a brief overview of how to do it with apache2 in ubuntu; at one point we had fandev behind apache and this is all I did.
I've assumed you've installed apache2. Install and enable the proxy module for apache2
Now, edit /etc/apache2/sites-available/default and add
You can put this in a vhost or in the main apache conf file, that is a matter of taste/need. This assumes you have wisp running on 8888, you can of course change the port so long as it does not conflict with apache.
I can put more detailed information in some doc when we get to it, but here are some other sites that may help: