RE: External resources with a fallback
On Fri, 2003-12-19 at 19:13, Shapira, Yoav wrote: Howdy, I try to figure out how to make Tomcat 5 load resources externally to the webapp, and failing over to loading them from the webapp if they are not present in the external location. I figure I should subclass BaseDirContext (or implement DirContext straight away), setting it in the resources sub-element of the webapp's context. That's one way to go about it. Now, how can I get a handle to the default DirContext from my custom DirContext so that I can fail over? Two options: - Define a normal DirContext in addition to one of your own, and add code in your own custom one to look up other DirContexts in the service. - Have your own custom implementation initialize and configure a normal DirContext in addition to itself, use this internal DirContext if the external resource is not found. By normal above I mean one of the Tomcat-provided implementations of DirContext. Yes, but I would have to get a handle to the containing ServletContext (or the default DirContext for that ServletContext), since I don't know the docBase of the application. How would I do that? Also, if I want to pass any parameters to my DirContext from web.xml, where do I find them? They don't seem to be passed in the constructor...? In the environment (Hashtable) parameter constructor. It's setup via Digester. You also want to take a look at org.apache.catalina.startup.NamingRuleSet. What is the role of this class? Does it register things explicitly named in web.xml in JNDI? This component was not designed for easy extensibility and is not trivial to implement. It's not a common requirement (especially as it goes against the servlet specification spirit that webapps should be self-contained). This solution would be tied to tomcat internals just as much as your other proposition of customizing the ServletContext class. Perhaps you can outline your requirements and we can help you find an alternative design. I am trying to make a themeable web app (a photo album as it happens) where the themes consist of directories of JSPs and static resources. Some of the themes are delivered with the web app, and some are user supplied. The user supplied themes should persist when the web app is upgraded, so they have to be external. The standard and user supplied themes share name space (there is no way to tell them apart by name). Simon Yoav Shapira
RE: External resources with a fallback
Howdy, I try to figure out how to make Tomcat 5 load resources externally to the webapp, and failing over to loading them from the webapp if they are not present in the external location. I figure I should subclass BaseDirContext (or implement DirContext straight away), setting it in the resources sub-element of the webapp's context. That's one way to go about it. Now, how can I get a handle to the default DirContext from my custom DirContext so that I can fail over? Two options: - Define a normal DirContext in addition to one of your own, and add code in your own custom one to look up other DirContexts in the service. - Have your own custom implementation initialize and configure a normal DirContext in addition to itself, use this internal DirContext if the external resource is not found. By normal above I mean one of the Tomcat-provided implementations of DirContext. Also, if I want to pass any parameters to my DirContext from web.xml, where do I find them? They don't seem to be passed in the constructor...? In the environment (Hashtable) parameter constructor. It's setup via Digester. You also want to take a look at org.apache.catalina.startup.NamingRuleSet. This component was not designed for easy extensibility and is not trivial to implement. It's not a common requirement (especially as it goes against the servlet specification spirit that webapps should be self-contained). This solution would be tied to tomcat internals just as much as your other proposition of customizing the ServletContext class. Perhaps you can outline your requirements and we can help you find an alternative design. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
