From: lloyd <sub...@tw...> - 2005-01-29 20:29:51
|
hello all - these questions are based on my recent experiences with webware 0.8.1 1) is there a facility for running code on server start-up, and storing application-wide data (eg, say, a database connection pool manager)? 2) in a java servlet container like tomcat, each context is analagous to a separate application. in webware, this separation doesn't seem to exist. each context appears to be, basically, just a mapping of a URL segment to a directory. should i run a separate application server instance for each application that needs "separation" from other applications? 3) are there examples or documentation for using webware, formkit, and cheetah together in an optimal way? 4) if one is using cheetah, are the separate writeXXX() methods in a servlet really useful, considering that most of that information may be in the templates? thanks! |
From: Sam N. <sa...@se...> - 2005-01-29 22:16:45
|
lloyd wrote: > hello all - > > > these questions are based on my recent experiences with webware 0.8.1 > > 1) is there a facility for running code on server start-up, and storing > application-wide data (eg, say, a database connection pool manager)? > > 2) in a java servlet container like tomcat, each context is analagous to > a separate application. in webware, this separation doesn't seem to > exist. each context appears to be, basically, just a mapping of a URL > segment to a directory. should i run a separate application server > instance for each application that needs "separation" from other > applications? > > 3) are there examples or documentation for using webware, formkit, and > cheetah together in an optimal way? Hi lloyd, I'm still pretty green with webware, and python as well, so I can't say much about your first two questions. As far as documenting the webware/formkit/cheetah convergence, I find bits and pieces here and there between manuals, tutorials, wikis and the mailing list archives, but no silver bullet. Bringing the tech together is a "creative" thing at this point ;-). That's not to say that it doesn't all fit well and work great together, just that there are so many ways to use these tools together, but no clear resounding 'right way'. One 'issue' is that cheetah recommends that you inherit from a cheetah template. This is incompatible (I can't remember exactly how) with the normal webkit Page inheritance system. Inheriting from Page is one of my favorite things about webkit, so I don't use that method. Instead I call templates from different levels of my Webkit->Page->SitePage->etc. hierarchy. The thing is there are so many different ways you can use cheetah, it seems hard (i.e. takes a long time) to settle into a well rounded sensible system. > 4) if one is using cheetah, are the separate writeXXX() methods in a > servlet really useful, considering that most of that information may be > in the templates? This is the trickiest thing for me: how to keep my apps sensible while mixing Page inheritance with cheetah templates. Here are some starting points from the mailing lists: https://sourceforge.net/mailarchive/message.php?msg_id=5624068 http://sourceforge.net/mailarchive/message.php?msg_id=8736015 https://sourceforge.net/mailarchive/message.php?msg_id=7728701%3E Personally, I'm still experimenting. So far I'm finding that having two parallel inheritance trees (one for webkit servlets, one for cheetah templates) is too confusing. I think for bigger projects, that I'll continue to control layout from Servlets, and build Controller objects to offload the 'business logic'. I'll still use cheetah templates, but only for layout intensive sections. Cheetah provides a friendly fast clean and compact way to write text output of all kinds, which is very handy, but I prefer to keep my logic and control in webware. Cheetah is so flexible that it works great either way. BTW, if you haven't used SQLObject (sqlobject.org), I highly recommend it. For me, it is an incredible framework, and it is only getting better. Good luck, - Sam |
From: Winston W. <win...@ca...> - 2005-01-29 22:52:18
|
On Jan 29, 2005, at 3:29 PM, lloyd wrote: > 1) is there a facility for running code on server start-up, and > storing application-wide data (eg, say, a database connection pool > manager)? I don't know, but what I do is have my page base class create some singletons when first instantiated. That is, all pages in my website inherit from SitePage. The SitePage.__init__() creates my DB store on the first call only. > 2) in a java servlet container like tomcat, each context is analagous > to a separate application. in webware, this separation doesn't seem > to exist. each context appears to be, basically, just a mapping of a > URL segment to a directory. should i run a separate application > server instance for each application that needs "separation" from > other applications? I think the answer is No. But I'm curious what kind of separation would you like? I haven't used Tomcat and I am thinking about if contexts should be removed from Webware since it doesn't do anything useful at the moment. Is there something good about contexts in Tomcat that we should build up? > 3) are there examples or documentation for using webware, formkit, and > cheetah together in an optimal way? FormKit I would say is pretty straight forward. Cheetah is a problem though, because as Sam Nilsson mentioned, Cheetah.Template does not work well with WebKit.Page. The issue is that Cheetah.Template tries to inherit from WebKit.Servlet if it exists in the sys.path. The inheritence of WebKit.Page is: WebKit.Page > WebKit.HTTPContent > WebKit.HTTPServlet > WebKit.Servlet. So Cheetah.Template inherits from lower on the tree than WebKit.Page, but there are some functions like callMethodOfServlet() that are handy in WebKit.Page that you lose when your CheetahTemplate is a servlet. Sam Nilsson's way around this is to have his Page object just use Cheetah.Template objects. I.e. his page "has a" template instead of "is a" template. My solution was to remove the hack in Cheetah.Template that conditionally inherits from WebKit.Servlet. Yuck. Another thing you will encounter using Cheetah is how to compile them. Since there is not a standard way to use them, I don't want to put my way into the Webware repository. I have two utilities that I use. One is a CheetahServletFactory that will load .tmpl files and compile them when requested. That only compiles templates that are referenced as pages though. If your template inherits from another template, then the second one is never called directly and is never recompiled. So for that case, I have a second utility that that searches for new .tmpl files every 3 seconds, and compiles them. I only start it when I am developing. > 4) if one is using cheetah, are the separate writeXXX() methods in a > servlet really useful, considering that most of that information may > be in the templates? Not really. You can use WebKit.HTTPContent which is one level below WebKit.Page, and it doesn't have all those convenience methods that you won't use. -winston _________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating |
From: lloyd <sub...@tw...> - 2005-01-30 15:58:53
|
Winston Wolff wrote: >> 2) in a java servlet container like tomcat, each context is analagous >> to a separate application. in webware, this separation doesn't seem >> to exist. each context appears to be, basically, just a mapping of a >> URL segment to a directory. should i run a separate application >> server instance for each application that needs "separation" from >> other applications? > > I think the answer is No. But I'm curious what kind of separation would > you like? I haven't used Tomcat and I am thinking about if contexts > should be removed from Webware since it doesn't do anything useful at > the moment. Is there something good about contexts in Tomcat that we > should build up? it might just be a difference in architecture. i still don't quite get how the server and applications/contexts relate to each other in webware. let's say i have two unrelated applications, "inventory" and "human-resources", to be hosted on the same physical machine. would i run MakeAppWorkDir for each: MakeAppWorkDir -c inventory /usr/local/webapps/inventory MakeAppWorkDir -c human-resources /usr/local/webapps/human-resources ...and then create two init scripts, run two ThreadedAppServer instances on different ports, add entries for each in the apache config files, etc...? if so, it seems it would become unwieldy once you start getting into dozens of applications on the same box. or, use MakeAppWorkDir once, and just create additional context directories manually: MakeAppWorkDir -c inventory /usr/local/webapps mkdir /usr/local/webapps/human-resources ...and just put the human resources servlets etc in that directory? while i have the opportunity, an unrelated question (which may stem from my conception of contexts as isolated applications): in servlets, is it possible (or even desirable) to have paths interpreted relative to the context root? eg, using the example above, when i reference a cheetah template i have to do something like this: template = Template(file="inventory/stock-levels.tmpl") this feels awkward to me - again, perhaps because i think that the context is the application root, and therefore the application shouldn't have to know the name of the directory that its files are in. thanks |
From: Winston W. <win...@ca...> - 2005-01-30 23:37:22
|
> it might just be a difference in architecture. i still don't quite > get how the server and applications/contexts relate to each other in > webware. I'm not sure of the original intention for contexts either. Ian Bicking said they wanted to allow different configuration settings in different contexts but that was never implemented. At the moment, a context is just a way to specify multiple folders to store your HTML files in. As far as "web applications" go, with Webware, there is one Python interpreter and that runs the Application Server, and your servlets. The Application Server may create multiple instances of each servlet to handle heavy loads. You can specify multiple places to store your "logic layer" python code just by adding to sys.path. So contexts here don't really do much. > let's say i have two unrelated applications, "inventory" and > "human-resources", to be hosted on the same physical machine. would i > run MakeAppWorkDir for each: > > MakeAppWorkDir -c inventory /usr/local/webapps/inventory > MakeAppWorkDir -c human-resources /usr/local/webapps/human-resources > > ...and then create two init scripts, run two ThreadedAppServer > instances on different ports, add entries for each in the apache > config files, etc...? if so, it seems it would become unwieldy once > you start getting into dozens of applications on the same box. > > or, use MakeAppWorkDir once, and just create additional context > directories manually: > > MakeAppWorkDir -c inventory /usr/local/webapps > mkdir /usr/local/webapps/human-resources > > ...and just put the human resources servlets etc in that directory? What is your goal in making separate "applications"? If your goal is to isolate a severe crash in one from crashing the other, then you would want to run separate instances of Webware. The downside is more administration of multiple application servers and more ports to configure with Apache. If your goal is to organize the files relevant to a particular application, I would say put it all in one webware instance, and just use different sub-folders for each "application". I have had few problems with page crashes bringing the whole system down. I would do it all with one AppServer first, and then if you start to feel the need for it, separate them into multiple instances. > while i have the opportunity, an unrelated question (which may stem > from my conception of contexts as isolated applications): in servlets, > is it possible (or even desirable) to have paths interpreted relative > to the context root? > > eg, using the example above, when i reference a cheetah template i > have to do something like this: > > template = Template(file="inventory/stock-levels.tmpl") > > this feels awkward to me - again, perhaps because i think that the > context is the application root, and therefore the application > shouldn't have to know the name of the directory that its files are > in. I always have file paths either relative to the current page, or relative to a global HTTP_ROOT variable. I check the hostname to determine what I set HTTP_ROOT to. -winston _________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating |
From: deelan <de...@in...> - 2005-01-31 08:46:06
|
lloyd wrote: (...) > i have the opportunity, an unrelated question (which may stem from > my conception of contexts as isolated applications): in servlets, is it > possible (or even desirable) to have paths interpreted relative to the > context root? > > eg, using the example above, when i reference a cheetah template i have > to do something like this: > > template = Template(file="inventory/stock-levels.tmpl") > > this feels awkward to me - again, perhaps because i think that the > context is the application root, and therefore the application shouldn't > have to know the name of the directory that its files are in. for this specific task you may want to experiment with Application.serverSidePath (resolves relative paths from the *application* root), Page.serverSidePath (resolves relative paths from the current servlet), Request.serverSideContextPath and Request.contextName. |
From: andrea <and...@in...> - 2005-01-31 08:46:03
|
lloyd wrote: (...) > i have the opportunity, an unrelated question (which may stem from > my conception of contexts as isolated applications): in servlets, is it > possible (or even desirable) to have paths interpreted relative to the > context root? > > eg, using the example above, when i reference a cheetah template i have > to do something like this: > > template = Template(file="inventory/stock-levels.tmpl") > > this feels awkward to me - again, perhaps because i think that the > context is the application root, and therefore the application shouldn't > have to know the name of the directory that its files are in. for this specific task you may want to experiment with Application.serverSidePath (resolves relative paths from the *application* root), Page.serverSidePath (resolves relative paths from the current servlet), Request.serverSideContextPath and Request.contextName. |
From: jose <jo...@cy...> - 2005-01-31 02:03:40
|
> -----Original Message----- > From: web...@li...=20 > [mailto:web...@li...] On=20 > Behalf Of lloyd > Sent: Saturday, January 29, 2005 12:30 PM > To: web...@li... > Subject: [Webware-discuss] several questions about webware >=20 >=20 > hello all - >=20 >=20 > these questions are based on my recent experiences with webware 0.8.1 >=20 > 1) is there a facility for running code on server start-up,=20 > and storing=20 > application-wide data (eg, say, a database connection pool manager)? There is a database connection manager, but I've not used it before, = sorry not much help on this point >=20 > 2) in a java servlet container like tomcat, each context is=20 > analagous to=20 > a separate application. in webware, this separation doesn't seem to=20 > exist. each context appears to be, basically, just a mapping=20 > of a URL=20 > segment to a directory. should i run a separate application server=20 > instance for each application that needs "separation" from other=20 > applications? This is one of the big differences between a java servlet container and webware (beside the fact that its python and not java). Essentially if = you want to isolate your "applications" form each other, then yes you need = to run multiple App servers from different applications directories. That = is essentially what Makeappdir is for. Basically what I do is keep related applications together in a given app server, this way if for some reason = I have to restart a particular server not all of my webkit servlets need = to go down, only those in that particular group. It really is a very nice = feature once you start using it >=20 > 3) are there examples or documentation for using webware,=20 > formkit, and=20 > cheetah together in an optimal way? Sorry no single source of documentation, this list is probably the best single place to look, I've gotten lots of very good advice just by = trolling this list. As for Cheetah, the point it is, is that there is no single = best way to use it. It is a very good template engine and can be integrated = with Webware very nicely in a number of ways >=20 > 4) if one is using cheetah, are the separate writeXXX() methods in a=20 > servlet really useful, considering that most of that=20 > information may be=20 > in the templates? >=20 >=20 I can only tell you what I did, and it is only one way to use cheetah = with webware. What I did was write my own cheetahPage which inherits from = Page. To it I added all the "special" methods that I use to make cheetah work = the way I think it should. I also added some things to the basic Page which also make my life easier. Then I have all my servlets inherit from my cheetahPage (or I have a sitePage inherit from cheetahPage first, you = get the idea) and my servlet then calls the compiled template. I try to put most of my code in the servlets and then call what I need in the = template, as a result my compiled templates will not run by themselves most of the time, because they would be missing many of the methods and variables = that the servlets expose to them. I find that this keeps my presentation = code nicely separated from my program code, and keeps the templates very = clean. I would be happy to share my cheetahPage with anyone if there is = interest. To answer your question about the writexxx methods, I have writeTemplate (basically just an overwrite of writeContent, I could have use = writeContent, but didn't) and then I have a method called cheetahTemplate('templatename').render() which returns the rendered = template as a string. I usually pass that to write in my servlet. This way I = never use the template directly but indirectly though my servlets. This way = works very well for me. Like I said above there is no single best way to do = it, and lots of ways that work well. Jose > thanks! >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive=20 > Reporting Tool for open source databases. Create drag-&-drop=20 > reports. Save time by over 75%! Publish reports on the web.=20 > Export to DOC, XLS, RTF, etc. Download a FREE copy at=20 > http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Webware-discuss mailing list Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss >=20 >=20 |
From: michelts <mic...@gm...> - 2005-01-31 10:49:40
|
> > 3) are there examples or documentation for using webware, > > formkit, and > > cheetah together in an optimal way? You can use the inheritance approach, as Jose, I have a base servlet, but I not extend Page, I extend Cheetah.Template, this base servlet has some special methods to save my life. I put it in a Module inside webware, I call BaseSite so I can do in my servlets: from BaseSite.BaseServlet import BaseServlet or I can do in my templates: #extend BaseSite.BaseServlet #implements writeHTML Then, all my templates extends BaseServlet... I must compile each servlet, but this way I can have Servlets extending Templates... I can use the "block" statement of cheetah to define method to change... I hope I could help. Look at the cheetah documentation, you will understand what I trying to say :) Sorry my poor english... -- Michel Thadeu Sabchuk Curitiba - PR - Brasil |
From: John D. <jdi...@te...> - 2005-01-31 15:02:31
|
> these questions are based on my recent experiences with webware 0.8.1 > > 1) is there a facility for running code on server start-up, and > storing application-wide data (eg, say, a database connection pool > manager)? There is a DBPool module included in Webware, but it has been expanded upon. Look through this list's archives for DBConnectionPool. If you can't find it, let me know and I can get it to you. > > 2) in a java servlet container like tomcat, each context is analagous > to a separate application. in webware, this separation doesn't seem > to exist. each context appears to be, basically, just a mapping of a > URL segment to a directory. should i run a separate application > server instance for each application that needs "separation" from > other applications? > I have not used tomcat, but we do use webware contexts to separate "applications" from one another. Others on the list may think this is a bad idea (and if it really is a bad idea, I'd love to know why), but it seems to work for us. We have four instances of webware running: develop, model, demo, and prod. Develop is where we do all of our developing. Model and demo are for relatively stable versions for additional testing and demonsration purposes, and prod is where our production versions live. All four have the same (or similar) directory/context structure. So there may be a dozen different contexts in each of develop, model, etc., and each context is its own separate application. As each project (application) is developed, it moves through our four webware instances from develop to prod. I don't know if this system meets your needs for "separation," but it works for us. --John |
From: Winston W. <win...@ca...> - 2005-01-31 15:16:40
|
Hi John- I'm curious about what the context does for you that you like? I'm wondering if you just had different directories inside one context, wouldn't that be about the same as different contexts? > idea (and if it really is a bad idea, I'd love to know why), but it > seems to I don't see it as a really bad idea, only that it's not that useful and there is a lot of special-case code to handle it. -winston On Jan 31, 2005, at 10:06 AM, John Dickinson wrote: > I have not used tomcat, but we do use webware contexts to separate > "applications" from one another. Others on the list may think this is > a bad idea (and if it really is a bad idea, I'd love to know why), but > it seems to work for us. We have four instances of webware running: > develop, model, demo, and prod. Develop is where we do all of our > developing. Model and demo are for relatively stable versions for > additional testing and demonsration purposes, and prod is where our > production versions live. All four have the same (or similar) > directory/context structure. So there may be a dozen different > contexts in each of develop, model, etc., and each context is its own > separate application. As each project (application) is developed, it > moves through our four webware instances from develop to prod. I don't > know if this system meets your needs for "separation," but it works > for us. > > --John |
From: John D. <jdi...@te...> - 2005-01-31 15:46:36
|
I suppose several directories in one context would do about the same thing. I'm not sure that a context does anything special per se, but grouping several applications under one webware instance eases administration--only one server to restart/maintain, don't have to deal with opening/setting up ports for each application (lots of red tape). Webware can gracefully handle restarts (maintains active sessions), so restarting an app server is not such a big deal (and by the time code gets to out production server, it should be bullet-proof and virtually never require a restart). Winston Wolff wrote: > Hi John- > > I'm curious about what the context does for you that you like? I'm > wondering if you just had different directories inside one context, > wouldn't that be about the same as different contexts? > >> idea (and if it really is a bad idea, I'd love to know why), but it >> seems to > > > I don't see it as a really bad idea, only that it's not that useful > and there is a lot of special-case code to handle it. > > -winston > > > On Jan 31, 2005, at 10:06 AM, John Dickinson wrote: > >> I have not used tomcat, but we do use webware contexts to separate >> "applications" from one another. Others on the list may think this is >> a bad idea (and if it really is a bad idea, I'd love to know why), >> but it seems to work for us. We have four instances of webware >> running: develop, model, demo, and prod. Develop is where we do all >> of our developing. Model and demo are for relatively stable versions >> for additional testing and demonsration purposes, and prod is where >> our production versions live. All four have the same (or similar) >> directory/context structure. So there may be a dozen different >> contexts in each of develop, model, etc., and each context is its own >> separate application. As each project (application) is developed, it >> moves through our four webware instances from develop to prod. I >> don't know if this system meets your needs for "separation," but it >> works for us. >> >> --John > > > > ______________________________________________________________________ > This e-mail has been scanned by MCI Managed Email Content Service, > using Skeptic(tm) technology powered by MessageLabs. For more > information on MCI's Managed Email Content Service, visit > http://www.mci.com. > ______________________________________________________________________ > > |
From: Ben P. <be...@we...> - 2005-01-31 23:45:17
|
Contexts are really thin in Webware/WebKit right now. I mean really thin. The only time they've come into play for me is acting as a container for how WebKit instantiates servlets. Unless you do a lot of intra-context servlet inheriting, you've probably never had occasion to read that code. It's kind of woeful that contexts don't "wrap" a mini-application better to allow for more configurability. The stickler for me is having to use the same Session class across all contexts. If the Session class could be assigned on a per-context basis, then I would consider running separate applications under a single Webware server. As it stands now, if we tried to do that then the Session class would be huge in order to support different applications making heavy use of their own particular session needs. Instead we just run different instances of Webware (each with one context) and MixIn a different custom Session class for each one. This works out fine anyway considering that restarting the appserver for builds or bugfixes then doesn't affect the other apps. It seems like the roadmap for Webware should include either making Contexts more like an application, or just ditching the concept completely. Tavis Rudd made some progress years ago towards allowing the appserver to run multiple Applications instead of just one, but it was a tangential project that seems to have been pretty much ignored. Caveat - I'm way out of the loop with the latest development version. Too busy developing with the last production version. :) > -----Original Message----- > From: web...@li... > [mailto:web...@li...]On Behalf Of John > Dickinson > Sent: Monday, January 31, 2005 7:51 AM > To: Winston Wolff > Cc: web...@li... > Subject: Re: [Webware-discuss] several questions about webware > > > I suppose several directories in one context would do about the same > thing. I'm not sure that a context does anything special per se, but > grouping several applications under one webware instance eases > administration--only one server to restart/maintain, don't have to deal > with opening/setting up ports for each application (lots of red tape). > Webware can gracefully handle restarts (maintains active sessions), so > restarting an app server is not such a big deal (and by the time code > gets to out production server, it should be bullet-proof and virtually > never require a restart). > > Winston Wolff wrote: > > > Hi John- > > > > I'm curious about what the context does for you that you like? I'm > > wondering if you just had different directories inside one context, > > wouldn't that be about the same as different contexts? > > > >> idea (and if it really is a bad idea, I'd love to know why), but it > >> seems to > > > > > > I don't see it as a really bad idea, only that it's not that useful > > and there is a lot of special-case code to handle it. > > > > -winston > > > > > > On Jan 31, 2005, at 10:06 AM, John Dickinson wrote: > > > >> I have not used tomcat, but we do use webware contexts to separate > >> "applications" from one another. Others on the list may think this is > >> a bad idea (and if it really is a bad idea, I'd love to know why), > >> but it seems to work for us. We have four instances of webware > >> running: develop, model, demo, and prod. Develop is where we do all > >> of our developing. Model and demo are for relatively stable versions > >> for additional testing and demonsration purposes, and prod is where > >> our production versions live. All four have the same (or similar) > >> directory/context structure. So there may be a dozen different > >> contexts in each of develop, model, etc., and each context is its own > >> separate application. As each project (application) is developed, it > >> moves through our four webware instances from develop to prod. I > >> don't know if this system meets your needs for "separation," but it > >> works for us. > >> > >> --John > > |
From: lloyd <sub...@tw...> - 2005-02-01 20:58:55
|
Ben Parker wrote: > Contexts are really thin in Webware/WebKit right now. I mean really thin. > The only time they've come into play for me is acting as a container for how > WebKit instantiates servlets. Unless you do a lot of intra-context servlet > inheriting, you've probably never had occasion to read that code. > > It's kind of woeful that contexts don't "wrap" a mini-application better to > allow for more configurability. The stickler for me is having to use the > same Session class across all contexts. do you mean having a single session across contexts? if so, thanks for reminding me of this, since it's a perfect example of the separation i'm referring to. if contexts are "applications", as i understand them to be, shouldn't they maintain separate state in sessions? or maybe there is a preferred way to achieve this that i'm not aware of? |
From: Ben P. <be...@we...> - 2005-02-02 00:21:33
|
lloyd wrote: > Ben Parker wrote: > > Contexts are really thin in Webware/WebKit right now. I mean > really thin. > > The only time they've come into play for me is acting as a > container for how > > WebKit instantiates servlets. Unless you do a lot of > intra-context servlet > > inheriting, you've probably never had occasion to read that code. > > > > It's kind of woeful that contexts don't "wrap" a > mini-application better to > > allow for more configurability. The stickler for me is having to use the > > same Session class across all contexts. > > do you mean having a single session across contexts? if so, thanks for > reminding me of this, since it's a perfect example of the separation i'm > referring to. > As of Webware 0.8.1 the Session class used by all contexts is still the one defined in WebKit (Session.py). All contexts use the same session class, and if the browsing user moves between contexts, the same session object is used. If you use a MixIn to combine a custom session class with the default one, all Contexts are affected. You may think that mixing-in a custom session inside a Context's __init__ file will affect only that context, but it don't. :) > if contexts are "applications", as i understand them to be, shouldn't > they maintain separate state in sessions? > > or maybe there is a preferred way to achieve this that i'm not aware of? > Webware developers tend to think of separate contexts as separate applications, but they are definitely not. Once you understand the relationship, you can hand-wave it and go about building your app, most likely ignoring contexts entirely aside from the one you set up to contain the servlets. Don't get me wrong though, I'm not particularly pushing for contexts to change. It's just one of these issues that comes up on the list from time to time. To be honest, the decision between running several AppServers with one Application each (as we do now) or several Applications under one AppServer (each with it's own Context and configurable Session class) is really a "six of one, 1/2 dozen of the other" situation for me. |
From: lloyd <sub...@tw...> - 2005-02-02 10:02:38
|
Ben Parker wrote: > Webware developers tend to think of separate contexts as separate > applications, but they are definitely not. Once you understand the > relationship, you can hand-wave it and go about building your app, most > likely ignoring contexts entirely aside from the one you set up to contain > the servlets. currently the few webware applications i've created each reside in a context, and each context contains its servlets, templates, etc. again, aknowledging my java servlet hang-over: in tomcat, each context is a separate web application, with its own class hierarchy, its own /lib, its own configuration like security settings, ip restrictions, etc. the same user visiting two contexts will receive a separate session for each context. so, to achieve this in webware, i must run separate instances of AppServer and change the apache config each time i add one, right? thanks a lot for your patience laying this out for me. maybe a "webware for java servlet developers" page might be nice to have in the wiki. fwiw, i just finished my first pair of webware applications, and i'm definitely liking it. if nothing blows up once they go into production i'll be a convert :-) |
From: Warren S. <wa...@wa...> - 2005-01-31 16:55:21
|
John Dickinson said: >> 1) is there a facility for running code on server start-up, and >> storing application-wide data (eg, say, a database connection pool >> manager)? > > There is a DBPool module included in Webware, but it has been expanded > upon. Look through this list's archives for DBConnectionPool. If you > can't find it, let me know and I can get it to you. Here it is. http://cvs.sourceforge.net/viewcvs.py/webware-sandbox/Sandbox/wsmith323/DbConnectionPool.py?rev=1.16&view=auto -- Warren Smith wa...@wa... |