Thanks for the update, but I couldn't get the new code to work, maybe
that's what you meant by not supporting the file stuff yet ! grin
I was trying to set enter something like:
getServletContext().setAttribute(Dispatcher.KEY_CONFIG_FILE,
file:///whatever/maverick.xml);
I think that if you add a check for the string starting with file://, and
then call new URL(filepath) instead of getResource(), it would be
fine. Make sense?
Best,
Dan
(Hope you had fun skiing ... I'm going up next week!)
At 03:42 PM 2/6/03 -0800, you wrote:
Actually I was thinking of the application attribute context. A servlet
initialized prior to the dispatcher could do something like this:
this.getServletContext().setAttribute(Maverick.CONFIG_FILE_APPLICATION_KEY,
/WEB-INF/somethingelse.xml);
Of course the value could be obtained from anywhere (jndi, database, http
request, etc). Sound good?
I'm confused about your confusion over the file:// issue :-) Right now
all config file paths are loaded from inside the WAR using
getResource(). You want to be able to load config files which are located
somewhere else in the filesystem, right? Maverick needs some way of
determining whether to use getResource() or to create a URL and load that
directly. Some way of determining if the path is a fully-specified URL
seems like the natural way.
I'm leaving tonight for a ski trip so I'm not sure I'll be able to do
anything about it until Monday, but I'll get this into CVS soon.
Jeff
-Original Message-
From: Dan Finkelstein [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 05, 2003 4:23 PM
To: [EMAIL PROTECTED]
Subject: RE: [Mav-user] Specifying external maverick.xml
Hi Jeff,
Correct -- those are the two goals of this exercise!
To be clear, when you speak of app-context, you mean using JNDI to pull
the property from the servlet.xml file, something like this:
Context context = new InitialContext();
Context envContext = (Context)
context.lookup(java:comp/env);
maverickFile = (String)envContext.lookup(maverickFile);
I suppose that would work.
As far as the ':', Windows uses that in a drive specifier, so that might
be avoided. If I understand right, you're trying to let the user specify
one of:
file:///home/whatever/mav.xml
or
/WEB-INF/mav.xml
and have it work either way? I think the user needn't enter the file://
part -- in fact, it is kind of confusing and would commonly be left off by
mistake anyway. I think you could just assume the property is a file --
why would anyone enter a resource path from _outside_ the war file? It
doesn't make sense, that's what the init parameter is for!!
Regardless, what you're suggesting is reasonable and will certainly
address the two concerns. Can you commit it in cvs?
Thanks a lot,
Dan
At 03:17 PM 2/5/2003 -0800, you wrote:
There are two goals, right?
1) To let your webapp determine at runtime what config file to use.
2) To be able to use a configuration file outside of the WAR.
The use of a static is a little weirdhow about checking an app context
variable instead? Here is what I propose:
If app-context parameter exists, use that
If init parameter exists, use that
Otherwise use maverick.xml
In addition, the logic:
If value contains a :in the first 8 characters, treat it as an absolute URL.
Otherwise treat it as something to look up using getResource().
That seems to cover the two requirements. Is there a better way to
identify absolute URLs than checking for a :?
Jeff
-Original Message-
From: Dan Finkelstein [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 10:51 PM
To: [EMAIL PROTECTED]
Subject: Re: [Mav-user] Specifying external maverick.xml
Jeff,
Can you chime in on what you think of this change? Does it seem
reasonable (enuf!) to add to the source or is there a better way of
incorporating this feature?
Thanks,
Dan
At 07:52 AM 1/26/03 -0800, you wrote:
Howdy,
Yourazlin, I think you and I are thinking the same way in terms of wanting
access to changing maverick.xml from outside the war/ear file. An init
parameter, that is specified is web.xml, doesn't apply to our situations
since web.xml is inside the war file.
My suggestion is that Maverick allow an application to override the file
name in any way it chooses. For example, in my application, this would
allow me to put the file name in my application-specific properties
file. What follows is my suggestion on how to enhance Maverick to handle
this:
To Dispatcher.java, add:
private static String _overriddenMaverickXmlFile = null;
public static void setMaverickXmlFile(String name)
{
_overriddenMaverickXmlFile = name;
}
Also, to Dispatcher.java, modify loadConfigDocument() so that first part
looks like this:
/**
* @return a loaded JDOM document containing
