[Mav-user] additional configuration for commands
Please enlighten me :-) I would like to specify some additional configuration parameters for my maverick commands in maverick.xml. Something like this is what I came up with: command name=orgunit controller class=ee.tvi.eris.ctl.orgunit.Orgunit param name=required-roles value=role1/ /controller ... /command This required-roles specifies that user must be authenticated and have role1 assigned to his/her account. Now this works but if I use views of type=redirect then this required-roles becomes an url parameter. Ie. if I define input view for this command like this: view name=input type=redirect path=orgunit-search.m/ then request to orgunit.m is redirected to: orgunit-search.m?required-roles=role1 I do not need this required-roles to go along with the redirect. Is there a better way to specify configuration parameters for a command. I do not want to have any additional config files, etc. with best wishes, Taavi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com [INVALID FOOTER]
RE: [Mav-user] additional configuration for commands
Jeff, It would be easy enough to split up the params collection into three separate collections. I'd be interested in hearing more about why we'd want these separate since seperating them adds complexity to the API. If we need the sperate names spaces, great. If not, why bother? John-Mason Shackelford Software Developer Pearson Educational Measurement - eMeasurement Group 2510 North Dodge St. Iowa City, IA 52245 ph. 319-354-9200x6214 [EMAIL PROTECTED] http://etest.ncspearson.com This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
Re: [Mav-user] additional configuration for commands
Jeff, I have no problem with that. -- Mike On Wednesday, February 12, 2003, at 12:10 PM, Schnitzer, Jeff wrote: Ah, right now there is just one set of params and each place that defines params (controller, view, transform) just adds to the pile. Perhaps different behavior is desirable. It would be easy enough to split up the params collection into three separate collections. This would change the ControllerContext interface so that instead of setParam() it would have setControllerParam(), setViewParam(), setTransformParam(), etc. Does this seem like a good idea to everyone? Jeff -Original Message- From: Taavi Tiirik [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 5:18 AM To: [EMAIL PROTECTED] Subject: [Mav-user] additional configuration for commands Please enlighten me :-) I would like to specify some additional configuration parameters for my maverick commands in maverick.xml. Something like this is what I came up with: command name=orgunit controller class=ee.tvi.eris.ctl.orgunit.Orgunit param name=required-roles value=role1/ /controller ... /command This required-roles specifies that user must be authenticated and have role1 assigned to his/her account. Now this works but if I use views of type=redirect then this required-roles becomes an url parameter. Ie. if I define input view for this command like this: view name=input type=redirect path=orgunit-search.m/ then request to orgunit.m is redirected to: orgunit-search.m?required-roles=role1 I do not need this required-roles to go along with the redirect. Is there a better way to specify configuration parameters for a command. I do not want to have any additional config files, etc. with best wishes, Taavi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com [INVALID FOOTER] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
RE: [Mav-user] additional configuration for commands
The problem just brought up was that the redirect view interprets params as actual request parameters to append to the URL. Setting parameters to the controller inadvertently causes them to show up in a redirect. That seems like a compelling reason for separate namespaces. Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Shackelford, John-Mason [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 11:23 AM To: '[EMAIL PROTECTED]' Subject: RE: [Mav-user] additional configuration for commands Jeff, It would be easy enough to split up the params collection into three separate collections. I'd be interested in hearing more about why we'd want these separate since seperating them adds complexity to the API. If we need the sperate names spaces, great. If not, why bother? John-Mason Shackelford Software Developer Pearson Educational Measurement - eMeasurement Group 2510 North Dodge St. Iowa City, IA 52245 ph. 319-354-9200x6214 [EMAIL PROTECTED] http://etest.ncspearson.com ** ** This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. ** ** --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
RE: [Mav-user] Specifying external maverick.xml
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 the
Re: [Mav-user] additional configuration for commands
I have no problem with this. As for me, though behaviour isn't what is expected, the case is too uncommon to introduce new methods. Maybe there is a way to change behaiviour to what it should be without changing API? I don't see it, but maybe it's possible... Cheers, Yura. - Original Message - From: Schnitzer, Jeff [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: Wednesday, February 12, 2003 10:10 PM Subject: RE: [Mav-user] additional configuration for commands Ah, right now there is just one set of params and each place that defines params (controller, view, transform) just adds to the pile. Perhaps different behavior is desirable. It would be easy enough to split up the params collection into three separate collections. This would change the ControllerContext interface so that instead of setParam() it would have setControllerParam(), setViewParam(), setTransformParam(), etc. Does this seem like a good idea to everyone? Jeff --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
