On 10/14/2010 12:53 PM, Raj Saini wrote:
So how this is going to work one code is deployed inside a application server? For example as a war or ear or let us say inside the component folder of OFBiz?
The top-level ofbiz-component.xml defines the top-level webapp. The web.xml configured there then has WebslingerServlet configured, mapped to /*.
All requests, for *all* hostnames, are then sent to webslinger. It has entities in the database to map multiple hostnames to a single WebslingerServer instance. There is a suffix table, that chops of domain name parts from the end, then a mapping table that takes what is left to a particular instance. There is also support for * mapping as a prefix, plus different top-level webapp context paths have their own configuration. $siteName.localhost/, $siteName.$desktopName/, www.$domainName.com/ are mapped by having 'localhost', '$desktopName' in WebslingerHostSuffix, then in WebslingerHostMapping, having '$siteName'/, 'www.$domainName.com'/ in WebslingerHostMapping.
WebslingerServer then has a commons-vfs file url. We generally have it as 'file:///job/$clientName-$jobName/pages/${CLIENT-NAME}-${JOB-NAME}'. In that folder, there tends to be a www/, Config/, and Var/. www/ then as a WEB-INF/, and the rest of the content files. (we'd created commons-vfs compatible lookups for standard ofbiz 'location' urls too, ie: ofbiz-component://ecommerce/webslinger-site)
The parent servlet container is *not* used at all to serve *any* files. The only thing used from the parent container is http processing, and logging. Webslinger does everything else itself.
This is done by making webslinger into a servlet container; a container that can be installed into *other* containers. We call this a nested container. This has meant that webslinger's code base is rather larger than other content systems. But it allows us to install standard servlets, and still make use of the overlay filesystem feature.
For instance, we have the jsp servlet installed inside webslinger, and when it needs to parse a .jsp file, the actual location of the file can come from any of a number of overlayed directories.
Then, we have a git repository configured at /job/$clientName-$siteName. In there, there is the above mentioned pages folder, and as a sibling there is an ofbiz folder, that has a standard component. That is linked into the ofbiz hot-deploy folder. We can then use that to add job-specific entity definitions, services, scripts, etc. Because ofbiz doesn't support runtime addition of components, it does require restarting, which is a little annoying.
Webslinger itself does support adding new sites and mappings at runtime tho.
Does that help answer your question? Or is it just a bunch of greek, or too much information?
Here is an example of what I mean by overlay: == doo...@host:/job/brainfood-standard-base/pages/BASE/www/account$ tree . ├── Actions.whtml ├── left.vm ├── left.vm@ │ └── no-edit ├── Menu.whtml ├── newsletters │ ├── Header.whtml │ ├── index.groovy │ ├── index.groovy@ │ │ ├── is-filter │ │ └── require-login │ ├── List.vm │ ├── SuccessMessage.whtml │ ├── Title.whtml │ ├── View.vm │ └── View.vm@ │ └── no-edit ├── password │ ├── index.groovy │ ├── index.groovy@ │ │ ├── is-filter │ │ └── require-login │ ├── SuccessMessage.whtml │ ├── Title.whtml │ ├── View.vm │ └── View.vm@ │ └── no-edit ├── profile │ ├── contact-action-EMAIL_ADDRESS.vm │ ├── contact-action-POSTAL_ADDRESS.vm │ ├── contact-action-TELECOM_NUMBER.vm │ ├── contact-edit-EMAIL_ADDRESS.vm │ ├── contact-view-EMAIL_ADDRESS.vm │ ├── contact-view-POSTAL_ADDRESS.vm │ ├── contact-view-TELECOM_NUMBER.vm │ ├── index.groovy │ ├── index.groovy@ │ │ ├── is-filter │ │ └── require-login │ ├── Title.whtml │ ├── View.vm │ └── View.vm@ │ ├── no-edit │ └── PageStyle └── Title.whtml doo...@host:/job/brainfood-shop-base/pages/SHOP/www/account$ tree . ├── contactmech │ ├── index.groovy │ ├── index.groovy@ │ │ └── is-filter │ ├── PostalAddress.vm │ └── TelecomNumber.vm ├── destinations │ ├── index.groovy │ ├── index.groovy@ │ │ ├── is-filter │ │ └── require-login │ ├── NotYetCreated.whtml │ ├── Orders.vm │ ├── RelationDisplay.vm │ ├── Rename.vm │ ├── Rename.vm@ │ │ └── no-edit │ ├── Title.whtml │ ├── View.vm │ └── View.vm@ │ └── no-edit ├── order │ ├── Actions.whtml │ ├── index.groovy │ ├── index.groovy@ │ │ ├── is-filter │ │ └── require-login │ ├── Print.vm │ ├── Print.vm@ │ │ └── no-edit │ ├── View.vm │ └── View.vm@ │ └── no-edit ├── orders │ ├── index.groovy │ ├── index.groovy@ │ │ ├── is-filter │ │ └── require-login │ ├── NoOrders.whtml │ ├── View.vm │ └── View.vm@ │ └── no-edit └── paymentmethods ├── index.groovy ├── index.groovy@ │ ├── is-filter │ └── require-login ├── Title.whtml ├── View.vm └── View.vm@ └── no-edit doo...@host:/job/content-site/pages/CONTENT/www/account$ tree . ├── destinations │ └── View.vm@ │ ├── PageStyle │ └── section-Left ├── Menu.whtml ├── newsletters │ └── View.vm@ │ ├── PageStyle │ └── section-Left ├── order │ └── View.vm@ │ ├── PageStyle │ └── section-Left ├── orders │ └── View.vm@ │ ├── PageStyle │ └── section-Left ├── password │ └── View.vm@ │ ├── PageStyle │ └── section-Left ├── paymentmethods │ └── View.vm@ │ ├── PageStyle │ └── section-Left └── profile └── View.vm@ ├── PageStyle └── section-Left == You'll note that standard-base and shop-base have different account folders. base has completely generic screens, while shop has screens that only make sense for online shopping sites. Then, the content folder has the same directories that exist in both of the bases, but is very light-weight, and only sets certain configuration parameters. All three of these directory structures are then merged at runtime, to provide a unified view. A higher-level tree can add new files, or replace files. It's also possible to delete a file in a lower level; the standard term for this is called a whiteout. Each main top-level folder(/job/foo is the root) is a separately maintained git repository. This has allowed us to share code between all of our sites, so that features and fixes can be rapidly deployed, while allowing the customer's content site to only contain what is required to configure the bases.
