RE: [Mav-user] jar hell with jdom reloaded
+1 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eelco Hillenius Sent: Thursday, September 29, 2005 3:07 PM To: mav-user@lists.sourceforge.net Subject: Re: [Mav-user] jar hell with jdom reloaded Devs, There has been hardly any use of this list. There have been a couple of feature requests/ bug reports though. As it doesn't look like any of the current committers is going to attend them (I am too involved with Wicket to support Maverick). Travis Reeder would to apply a fix for the JDOM dependency (see http://sourceforge.net/mailarchive/forum.php?thread_id=8339347forum_id=1837 as the message I'm replying to didn't come over correctly). I'm +1 for giving him commit rights. Can we have a vote please? Eelco On 9/29/05, Travis Reeder [EMAIL PROTECTED] wrote: --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl [INVALID FOOTER] --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl [INVALID FOOTER]
RE: [Mav-user] jar hell with jdom reloaded
+1 --jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Hernandez Sent: Thursday, September 29, 2005 5:53 PM To: mav-user@lists.sourceforge.net Subject: Re: [Mav-user] jar hell with jdom reloaded +1 - Original Message - I'm +1 for giving him commit rights. Can we have a vote please? --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl [INVALID FOOTER] --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl [INVALID FOOTER]
RE: [Mav-user] Multiple conditional ${wrapped}?
Why not just put all the javascript functions in a .js file and then just
include that in the pages:
script language=javascript src=functions.js/
--jim
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cyrille Bonnet
Sent: Wednesday, September 01, 2004 10:07 PM
To: [EMAIL PROTECTED]
Subject: [Mav-user] Multiple conditional ${wrapped}?
Hi Maverick users,
I have a simple problem. Of course, I'd like a simple solution :-)
We use a header JSP across many JSP pages. On some of those JSP pages, we
have Javascript functions available (inside the head tag), but not on all
pages.
We use the ${wrapped} and Maverick transformation to replace the body
content on our pages. But we can't have multiple ${wrapped} in one page, so
we can't use Maverick transform to replace the Javascript functions when
needed.
Ideally, we would have something like that in the header JSP:
head
c:out value=${wrapped} escapeXml=false/ -- transform this
to Javascript functions --
/head
body
c:out value=${wrapped} escapeXml=false/ -- transform that
to body content --
/body
At the moment, we have the choice of several (unsatisfying) workarounds:
* have all Javascript functions in all pages,
* create a custom header for each set of Javascript functions
Any pointer would be appreciated.
Cyrille.
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
[INVALID FOOTER]
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
[INVALID FOOTER]
RE: [Mav-user] release Maverick is one year old
The fact that the last maverick release is a year old is more a testament to the stability of maverick than to the developers neglecting to release a new version. There have been a flurry of changes in the past week or so by eelco, but these simple revolve around namespace changes and moving from log4j to apache common's logging. Once all that work is done, there will probably be a new release, but you definitely won't go wrong using the current release. --jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pierre de Soyres Sent: Monday, June 14, 2004 2:56 PM To: [EMAIL PROTECTED] Subject: [Mav-user] release Maverick is one year old hi all, the last Maverick release is now 1 year old. Do you know when a new one will be commited with all the changes ? Or, do I need to update my maverick.jar using the online CVS ? Pierre de Soyres. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- *-*-*-*-*- Les informations contenues dans ce courrier electronique et dans les fichiers qui y sont attachees sont confidentielles et peuvent etre protegees legalement. Elles ne sont adressees qu'au destinataire. L'acces a ce courrier electronique par toute autre personne n'est pas autorise. Si vous n'etes pas le destinataire voulu, toute divulgation, copie ou diffusion de ce courrier electronique est interdite et peut etre illegale. Sauf mention contraire dans le corps du message, la presence de cette note prouve egalement que ce message electronique a ete verifie par un logiciel anti-virus. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- *-*-*-*-*- This email and any attached file are confidential and intended solely for the use of the individual or entity to whom they are addressed. Accessing this email by anyone else than the recipient is forbidden and may be illegal. If you received this email by error please notify the system administrator. This footnote also confirms that this message has been scanned by an anti-virus software. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- *-*-*-*-*- --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 [INVALID FOOTER] --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 [INVALID FOOTER]
RE: [Mav-user] OS dependent while retrieving Dispatcher : the right message
Looking through the cvs history (ain't it grand) I see that
Dispatcher.MAVERICK_APPLICATION_KEY was changed on Feb 12, 2003 from
maverickApplicationKey to mav.dispatcher. You might look in your derived
dispatcher and make sure that you are referencing the constant and not using
the string maverickApplicationKey directly when storing the attribute.
--jim
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pierre de Soyres
Sent: Wednesday, November 26, 2003 12:26 PM
To: [EMAIL PROTECTED]
Subject: Re: [Mav-user] OS dependent while retrieving Dispatcher : the right
message
i made some more logs :
System.out.println(Dispatcher.MAVERICK_APPLICATION_KEY);
- mav.dispatcher
System.out.println(this.getCtx().getServletContext().getAttribute(Dispatcher
.MAVERICK_APPLICATION_KEY));
- null
Enumeration enum = this.getCtx().getServletContext().getAttributeNames();
while (enum.hasMoreElements()) {
String o = (String) enum.nextElement();
System.out.println(o);
}
-
org.apache.catalina.jsp_classpath
javax.servlet.context.tempdir
maverickApplicationKey
org.apache.catalina.resources
org.apache.catalina.Registry
org.apache.catalina.MBeanServer
org.apache.catalina.WELCOME_FILES
We can see that there is the maverickApplicationKey attribute name
(instead of mav.dispatcher)
Pierre
On Wed, 26 Nov 2003 09:38:51 -, jim moore [EMAIL PROTECTED] wrote:
This sounds really odd to me. Have you tried adding a log message or
stepping through with a debugger to inspect the value of
Dispatcher.MAVERICK_APPLICATION_KEY at runtime. It sounds like this
value is
getting lost somewhere...
--jim
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pierre de
Soyres
Sent: Wednesday, November 26, 2003 7:57 AM
To: [EMAIL PROTECTED]
Subject: Re: [Mav-user] OS dependent while retrieving Dispatcher : the
right
message
Hello,
My own AdminDispatcher extends org.infohazard.maverick.Dispatcher. it
overrides the init(ServletConfig) method (from GenericServlet)
in order to set some init-parameters values.
In my controller, (that extends
org.infohazard.maverick.ctl.ThrowawayBean2), the code :
this.getCtx().getServletContext().getAttribute(Dispatcher.MAVERICK_APPLICATI
ON_KEY);
returns null;
But the code :
this.getCtx().getServletContext().getAttribute(maverickApplicationKey);
returns my AdminDispatcher
under linux, with the same code,
this.getCtx().getServletContext().getAttribute(Dispatcher.MAVERICK_APPLICATI
ON_KEY);
works fine.
On Tue, 25 Nov 2003 13:28:54 -0800, Schnitzer, Jeff [EMAIL PROTECTED]
wrote:
Are you sure you have the exact same versions of everything?
When you say doesn't work do you mean the value you get is null?
If this is really happening, it would be a bug in your container. What
container?
3jeff
-Original Message-
From: Pierre de Soyres [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 5:49 AM
To: [EMAIL PROTECTED]
Subject: [Mav-user] OS dependent while retrieving Dispatcher : the
right
message
Hello,
(Sorry for the last message that contained mistakes)
I saw a strange comportment while retrieving the Dispatcher :
- Under Windows XP, this code doesn't work (but it should) and i
still
can't understand why :
protected Dispatcher getDispatcher() {
return
(Dispatcher)this.getCtx().getServletContext().getAttribute(Dispatcher.MA
VE
RICK_APPLICATION_KEY);
}
- but this one works fine (which tooks me a long time before finding
it)
:
protected Dispatcher getDispatcher() {
return
(Dispatcher)this.getCtx().getServletContext().getAttribute(maverickAppl
ic
ationKey);
}
- Under linux : the right one works fine :
protected Dispatcher getDispatcher() {
return
(Dispatcher)this.getCtx().getServletContext().getAttribute(Dispatcher.MA
VE
RICK_APPLICATION_KEY);
}
Strange ! isn't it !!
Any idea ?
Thanks.
---
Pierre de Soyres
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Les informations contenues dans ce courrier electronique et dans les
fichiers
qui y sont attachees sont confidentielles et peuvent etre protegees
legalement.
Elles ne sont adressees qu'au destinataire. L'acces a ce courrier
electronique
par toute autre personne n'est pas autorise. Si vous n'etes pas le
destinataire voulu, toute divulgation, copie ou diffusion de ce
courrier
electronique est interdite et peut etre illegale.
Sauf mention contraire dans le corps du message, la presence de cette
note
prouve egalement que ce message electronique a ete verifie par un
logiciel
anti-virus.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
This email and any attached file are confidential and intended solely
for
the use of the individual or entity to whom they are addressed.
Accessing this email by anyone else than the recipient is forbidden
and
may
be illegal
Re: [Mav-user] PROPOSAL: Move java packaging to net.sf.mav.*
+1 from me too, though we might take a vote from the larger community on this one. A lot of people's code is gonna stop compiling when the package for ThrowawayBean2 changes... --jim - Original Message - From: Schnitzer, Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 4:17 PM Subject: [Mav-user] PROPOSAL: Move java packaging to net.sf.mav.* From: Ted Husted [mailto:[EMAIL PROTECTED] Schnitzer, Jeff wrote: FWIW, I'd like to see everything migrated over to net.sf.mav.* eventually. It would be a pretty big PITA though. Not sure how worthwhile it would be to move the core. If there were interest, I'd be glad to volunteer for the grunt work, as part of my right of passage =:) If you're volunteering, you have my +0.5 :-) Scott, Jim, Mike? I'm still waiting on Anthon's reply regarding the FormProc patch. Jeff's setup my account, and, in the meantime, I have some minor JavaDoc fixes I could apply to the core, if that's all right. No code changes. Please, go for it :-) Jeff --- 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] Opt Fop behavior
what you are describing should work fine--the filename attribute should give you the open/save dialog and without it, the pdf should just open in the browser, but clearly something is going awry. for argument's sake, could you try appending some bogus param to the query string, like: http://localhost:8080/ehs/convert.m?resource=html_file.htmfoo=bar.pdf In the past I've had occassions where ie overrode the mime type I sent it and figured out the mime type itself by looking at the final extension it saw. let me know what happens. --jim - Original Message - From: Sandeep Dath To: [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 1:18 PM Subject: [Mav-user] Opt Fop behavior HI, I was wondering if somebody could explain some opt-fop behavior for me. I have an Html -- FO -- PDF pipeline that I've setup for file conversion using a stylesheet I found at http://www-106.ibm.com/developerworks/xml/library/x-xslfo2app/. When I explicitly specify the "filename='someoutputfile.pdf'" option in the fop transform step, the conversion takes place smoothly popping upthe converted file with the IE (6.0) Open/Save option.However, without this - I end up with a blank page (HTML content) with nothing on the page. My URL syntax works out to be: http://localhost:8080/ehs/convert.m?resource=html_file.htm. I am using M2.2 with opt-fop 1.1 with Tomcat 5.0.3 Alpha. The command definition from maverick.xml is as follows: command name="convert" controller class="ControllerNameDeleted" /view name="success" type="document" path="convert.jsp" transform type="xslt" path="xhtml-to-xslfo.xsl"/ transform type="fop"/ /view /command For the record, my JSP file currently uses out.write() to output file content. I plan to change this to make it cleaner, but that's what happpens now. Thanks! Sandeep
[Mav-user] Opt-Fop 1.1 released
Title: Message Opt-Fop 1.1 has been released. There were no source changes necessary--I just upgraded the jars in the lib folder (fop.jar, batik.jar, and avalon) to the versions shipping with fop 0.20.5, so if you are already using opt-fop you should be able to get away with just upgrading these jars yourself. Since the last version had been in beta for over a year though, I figure its probably about time to do a full release. --jim -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jim mooreSent: Tuesday, August 05, 2003 5:04 PMTo: [EMAIL PROTECTED]Subject: Re: [Mav-user] opt-fop sure--i'll try and look at it over the weekend. thanks for the heads up. --jim - Original Message - From: Bardzil, Timothy J (Timothy) To: [EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 4:58 PM Subject: [Mav-user] opt-fop Can we expect a new release of opt-fop now that FOP 0.20.5 final has been released? Tim
Re: [Mav-user] opt-fop
sure--i'll try and look at it over the weekend. thanks for the heads up. --jim - Original Message - From: Bardzil, Timothy J (Timothy) To: [EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 4:58 PM Subject: [Mav-user] opt-fop Can we expect a new release of opt-fop now that FOP 0.20.5 final has been released? Tim
Re: [Mav-user] PROPOSAL: Add Mike Moulton as committer
+1 from me as well. --jim - Original Message - From: Schnitzer, Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 31, 2003 8:03 PM Subject: [Mav-user] PROPOSAL: Add Mike Moulton as committer I propose adding Mike Moulton as committer. Mike is a longtime user of Maverick, has helped out in the past, and is even responsible for our snazzy logo. He's most recently written an opt-jxv package. I'm +1 Jeff --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 [INVALID FOOTER] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 [INVALID FOOTER]
Re: [Mav-user] Commands vs. Controllers
1. Browser requests an URL (eg. http://localhost/test.m) 2. In maveric terminology it appears that test.m is actually mapped to a test command. 3. Maverick dispatches the request to appropriate Controller that takes care of command execution. Controller also takes care of the flow (eg. returns a view or executes another command). Any controller can serve multiple commands. So commands are just placeholders for specific URLs. this is a good way to look at it--you could easily have a general purpose controller that could you would reuse in different situations--something as simple as: command name=report controller class=foo.ReportCreator/ view path=report.jsp/ /command command name=pdfReport controller class=foo.ReportCreator/ view path=pdf/report.jsp transform type=fop/ /view /command command name=excelReport controller class=foo.ReportCreator/ view path=excel/report.jsp/ /command obviously this could also be done as: command name=report controller class=foo.ReportCreator/ view name=standard path=report.jsp/ view name=pdf path=pdf/report.jsp transform type=fop/ /view view name=excel path=excel/report.jsp/ /command but the point is it is your choice as to how you want to organize your apps. --jim --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php [INVALID FOOTER]
Re: [Mav-user] Commands vs. Controllers
actually--giving this more thought... the command is the wrapper around the whole maverick work unit--it wraps the entire controller - view - transform chain. when you specify a command you are specifying the entire work unit. a controller is more akin to a view than a command in that the controller is just one step in the processing of the command. in fact, it is completely valid to have a command with no controller: command name=foo view path=makeFO.jsp transform type=fop/ /view /command --jim - Original Message - From: jim moore [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 23, 2003 12:49 PM Subject: Re: [Mav-user] Commands vs. Controllers 1. Browser requests an URL (eg. http://localhost/test.m) 2. In maveric terminology it appears that test.m is actually mapped to a test command. 3. Maverick dispatches the request to appropriate Controller that takes care of command execution. Controller also takes care of the flow (eg. returns a view or executes another command). Any controller can serve multiple commands. So commands are just placeholders for specific URLs. this is a good way to look at it--you could easily have a general purpose controller that could you would reuse in different situations--something as simple as: command name=report controller class=foo.ReportCreator/ view path=report.jsp/ /command command name=pdfReport controller class=foo.ReportCreator/ view path=pdf/report.jsp transform type=fop/ /view /command command name=excelReport controller class=foo.ReportCreator/ view path=excel/report.jsp/ /command obviously this could also be done as: command name=report controller class=foo.ReportCreator/ view name=standard path=report.jsp/ view name=pdf path=pdf/report.jsp transform type=fop/ /view view name=excel path=excel/report.jsp/ /command but the point is it is your choice as to how you want to organize your apps. --jim --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php [INVALID FOOTER] --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php [INVALID FOOTER]
RE: [Mav-user] maverick-opt-fop with fop-0.20.5rc3a
I did some testing today and was able to get opt-fop and friendbook-fop running fine with just replacing fop.jar, batik.jar and the avalon-framework jar with the versions shipping with fop-0.20.5rc3a. I didn't have to modify any opt-fop source code at all. Logging was working and pdf's were coming out fine. Eelco, why did you need to patch the files? Were you seeing errors? Assuming I'm not special and simply swapping out the jars works for everyone, I'm not sure if we need a new release now (especially since the opt-fop source files don't seem to need any changes). I'd probably just rather wait until the final version of fop-0.20.5 is released--then we can do a new release with the new jars if people feel it's necessary. --jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of zz-Schnitzer, Jeff Sent: Monday, June 09, 2003 6:29 PM To: [EMAIL PROTECTED] Subject: RE: [Mav-user] maverick-opt-fop with fop-0.20.5rc3a +1 I'm all for pressing forward. Jeff -Original Message- From: jim moore [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2003 9:59 AM To: [EMAIL PROTECTED] Subject: Re: [Mav-user] maverick-opt-fop with fop-0.20.5rc3a Is there any compelling reason to remain backwards compatible? It seems lame that we have to give up configurably logging to work with both versions. Maybe we should just patch it completely (i.e. with logging) for the most recent version and do a new release. People that want the older version can use the previous version of opt-fop but I feel that the release version should be targeted to work with the most recent version of fop. --jim - Original Message - From: Eelco Hillenius [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 09, 2003 12:46 PM Subject: [Mav-user] maverick-opt-fop with fop-0.20.5rc3a Hi all, When using the latest version of FOP (which is the only version that behaves really well with my system) I came across some API changes that breaks FopTransform from maverick-opt-fop. 1. Options are now only supported for command line operations; 2. The Avalon logger now must be set with 'driver.setLogger(log)' instead of 'MessageHandler.setScreenLogger(log)'. I do not think 'options' is supported in any other way now; I could not find any docs about it (though I didn't search the mailing list. As it not really encouraged anyway, imho it's best to just discard it. I've included a path that works with both the older (4) and the 5rc3a versions of FOP. I do not set a logger though (but have the 5rc3a version as a comment), as one of the methods breaks one of the versions. If not set, the default (screen-) logger will be used. Eelco --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. [INVALID FOOTER] --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. [INVALID FOOTER] --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 [INVALID FOOTER]
Re: [Mav-user] maverick-opt-fop with fop-0.20.5rc3a
Is there any compelling reason to remain backwards compatible? It seems lame that we have to give up configurably logging to work with both versions. Maybe we should just patch it completely (i.e. with logging) for the most recent version and do a new release. People that want the older version can use the previous version of opt-fop but I feel that the release version should be targeted to work with the most recent version of fop. --jim - Original Message - From: Eelco Hillenius [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 09, 2003 12:46 PM Subject: [Mav-user] maverick-opt-fop with fop-0.20.5rc3a Hi all, When using the latest version of FOP (which is the only version that behaves really well with my system) I came across some API changes that breaks FopTransform from maverick-opt-fop. 1. Options are now only supported for command line operations; 2. The Avalon logger now must be set with 'driver.setLogger(log)' instead of 'MessageHandler.setScreenLogger(log)'. I do not think 'options' is supported in any other way now; I could not find any docs about it (though I didn't search the mailing list. As it not really encouraged anyway, imho it's best to just discard it. I've included a path that works with both the older (4) and the 5rc3a versions of FOP. I do not set a logger though (but have the 5rc3a version as a comment), as one of the methods breaks one of the versions. If not set, the default (screen-) logger will be used. Eelco --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. [INVALID FOOTER]
Re: [Mav-user] View references
Title: Message i agree. i'm -1 on this as well. --jim - Original Message - From: Schnitzer, Jeff To: [EMAIL PROTECTED] Sent: Monday, March 31, 2003 4:03 PM Subject: RE: [Mav-user] View references Maverick 1.0 worked this way global views did not need to be explicitly referenced in the commands. This resulted in several questions a month on the mailing list from newbies trying to figure out why their application didnt work when they did this: command name=blah controller class=blah.Blah/ view path=blah.jsp/ /command People get used to leaving the view name off when there is only one view listed, even if you need to be able to reference one of the globals. I even found myself making this mistake a few times. After some debate, we changed this behavior in Maverick 2.0, and since then this problem has not come up again. Im -1 on changing this behavior. Its not that much more typing. If you really want to minimize the config file, the transformation facility offers a much more elegant solution. Jeff Schnitzer [EMAIL PROTECTED] -Original Message-From: Taavi Tiirik [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 3:45 AMTo: [EMAIL PROTECTED]Subject: Re: [Mav-user] View references Simen, This is my maverick.xsl file that adds a view named "authentication" to every protected command. command name="..." protected="true" ... /command But yes, i think it would make sense to modify view lookup code to search from amongst global view definitions as well. Would it break anything? with best wishes, Taavi - Original Message - From: jim moore To: [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 9:30 PM Subject: RE: [Mav-user] View references if you want behavior where the global views are referenced by all commands, you can use a transformation on maverick.xml. if specified, maverick will run maverick.xml through an xsl before loading it. This xsl could easily copy all global views for you under each command. actually--this has come up so often on this list that someone may have already written an xsl to do this. --jim
Re: Content-type and transforms (was RE: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick)
- Original Message - From: Schnitzer, Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 7:04 PM Subject: RE: Content-type and transforms (was RE: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick) From: jim moore [mailto:[EMAIL PROTECTED] The nice about moving this functionality into the framework as opposed to the individual transforms is that it gives some regularity--it is very clear when looking at the maverick.xml file what the output of each transform is if necessary (no need to look at source code). Also, all existing transforms and views would work immediately without modification. It would be nice to be able to fix this so that everything works properly even if users don't specify a content-type for every step (something I doubt that most users will do consistently). The only downside is the API change, right? Yes I agree with this. All of the existing transform types in CVS right now extend AbstractTransformStep. All I have to do is add the dummy setContentType() method to AbstractTransformStep in the core and it will be unnecessary to modify any of the optional packages. Sound better? :-) Yes, I think this handles most of my concerns over breaking the api, though we might also need to do something to views as well. I think this discussion originally started over Mike's concern over setting the content-type when maxTransforms=0 (ie, a view, not a transform). I like this approach - it enables SAX-generating steps to specify content-type just like text-generating steps (which can specify the content-type on the HttpServletRequest). Agreed. I'm not going to harp on it too much more, but even with the above changes to the api (which I am now in favor of), I still sort of feel like the optional content-type attribute on views and transforms would be a nice option to offer. If present, it would basically override whatever the transform or view itself did. But I'm not going to press it too much more. If you feel like its overkill or confusing then I'll go along with your judgement. --jim --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en [INVALID FOOTER] --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en [INVALID FOOTER]
Re: Content-type and transforms (was RE: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick)
I wasn't implying that the content-type be mandatory. Just that maverick
would use it if it were there. If not, Maverick would simply behave as it
does currently.
I think this should achieve our goals without any real api break. As the
attribute is not mandatory, existing apps would continue to work as they do
now, but if present, maverick would use it.
The nice about moving this functionality into the framework as opposed to
the individual transforms is that it gives some regularity--it is very clear
when looking at the maverick.xml file what the output of each transform is
if necessary (no need to look at source code). Also, all existing transforms
and views would work immediately without modification.
--jim
- Original Message -
From: Schnitzer, Jeff [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 24, 2003 5:46 PM
Subject: Content-type and transforms (was RE: [Mav-user] [PROPOSAL] Release
v2.2.0 of Maverick)
I would hate to require content-type to be explicitly set on each step.
And without some input from the view or transform code, it's impossible
for the Maverick core to choose a sensible default.
For example, the output of a DomifyView should always be text/xml, but
the output of a DocumentView is probably going to be text/html or
text/plain. The output of an XSLTransform is usually text/xml, unless
it is the last node in an unhalted chain, in which case it is probably
text/html.
Right now DocumentViews and DocumentTransforms have a way of passing the
content-type - they call getResponse().setContentType(). For different
binding types (in particular, the SAX mechanism) there is not currently
any way of passing this information - so it seems that we should add it
to the TransformStep interface.
Yes, this changes the existing API a little, but I haven't thought of a
better way of making this work such that the default is right 90% of the
time. I'm certainly open to other ideas, of course.
Jeff Schnitzer
[EMAIL PROTECTED]
-Original Message-
From: jim moore [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 6:57 AM
To: [EMAIL PROTECTED]
Subject: Re: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
Just as an alternate, maybe it might make sense to use an attributes
in
maverick.xml on views and transforms to support this. Something like
controller class=com.foo.FooController
view name=success content-type=text/xml
transform type=xslt content-type=text/xml/
transform type=fop content-type=application/pdf/
/view
/controller
Maverick can be responsible for reading and applying these attributes
and
then the existing transforms and views won't need to be modified at
all.
If
the attribute is missing, maverick can just behave as it does
currently.
--jim
- Original Message -
From: Schnitzer, Jeff [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, March 23, 2003 4:44 PM
Subject: RE: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
Good point. In fact, it seems to me that the contract between
transform
steps is currently insufficient - each step should probably make an
attempt to communicate to the subsequent step what the appropriate
content type is. That way no matter what type of transform you have,
halting should provide the appropriate content-type.
I'll try adding a setOutputType() method to the TransformStep
interface. Calling it will be recommended but optional. At the
moment
I imagine that only the LastStep will do anything with it.
Jeff Schnitzer
[EMAIL PROTECTED]
-Original Message-
From: Mike Moulton [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 5:28 PM
To: [EMAIL PROTECTED]
Subject: Re: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
Before releasing 2.2 there is a bug I noticed a while ago that
doesn't
seem to have been fixed.
The problem is that the UNFINISHED_CONTENTTYPE isn't explicitly set
when maxTransforms=0. This caused problems on some browsers,
primarily
IE 5.2 for Mac.
To fix this I add the following lines to the getNextStep() method in
MaverickContext.java.
if (this.transformCount == 0)
this.getRealResponse().setContentType(UNFINISHED_CONTENTTYPE);
These lines were added within the 'if' statement. The new 'if'
statement looks as follows.
if (this.nextTransform = this.transformCount)
{
if (this.transformCount == 0)
this.getRealResponse().setContentType(UNFINISHED_CONTENTTYPE);
this.log.debug(...which is the LastStep);
return new LastStep(this);
}
There is also a patch attached for the version contained in the
2.1.2
release.
Note: This may not be the best solution to the problem.
-- Mike
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin
Re: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
Just as an alternate, maybe it might make sense to use an attributes in
maverick.xml on views and transforms to support this. Something like
controller class=com.foo.FooController
view name=success content-type=text/xml
transform type=xslt content-type=text/xml/
transform type=fop content-type=application/pdf/
/view
/controller
Maverick can be responsible for reading and applying these attributes and
then the existing transforms and views won't need to be modified at all. If
the attribute is missing, maverick can just behave as it does currently.
--jim
- Original Message -
From: Schnitzer, Jeff [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, March 23, 2003 4:44 PM
Subject: RE: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
Good point. In fact, it seems to me that the contract between transform
steps is currently insufficient - each step should probably make an
attempt to communicate to the subsequent step what the appropriate
content type is. That way no matter what type of transform you have,
halting should provide the appropriate content-type.
I'll try adding a setOutputType() method to the TransformStep
interface. Calling it will be recommended but optional. At the moment
I imagine that only the LastStep will do anything with it.
Jeff Schnitzer
[EMAIL PROTECTED]
-Original Message-
From: Mike Moulton [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 5:28 PM
To: [EMAIL PROTECTED]
Subject: Re: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
Before releasing 2.2 there is a bug I noticed a while ago that doesn't
seem to have been fixed.
The problem is that the UNFINISHED_CONTENTTYPE isn't explicitly set
when maxTransforms=0. This caused problems on some browsers, primarily
IE 5.2 for Mac.
To fix this I add the following lines to the getNextStep() method in
MaverickContext.java.
if (this.transformCount == 0)
this.getRealResponse().setContentType(UNFINISHED_CONTENTTYPE);
These lines were added within the 'if' statement. The new 'if'
statement looks as follows.
if (this.nextTransform = this.transformCount)
{
if (this.transformCount == 0)
this.getRealResponse().setContentType(UNFINISHED_CONTENTTYPE);
this.log.debug(...which is the LastStep);
return new LastStep(this);
}
There is also a patch attached for the version contained in the 2.1.2
release.
Note: This may not be the best solution to the problem.
-- Mike
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
[INVALID FOOTER]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
[INVALID FOOTER]
RE: [Mav-user] problem deploy maverick example (friendbook-jsp) to weblogic
Are you using jdk1.3 or 1.4? If you are using 1.3, you need to have xml-apis.jar in the webapps classpath or Dispatcher wont load, at least on Tomcat. --jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Calvin Ling Sent: Thursday, February 20, 2003 8:03 PM To: [EMAIL PROTECTED] Subject: [Mav-user] problem deploy maverick example (friendbook-jsp) to weblogic deploy the example friendbook-jsp.war app to weblogic 7.0.1, got 404 error in browser when trying .../friendbook-jsp/welcome.m, .../friendbook-jsp/welcome.jsp works just fine, it's not finding the dispatcher servlet I think. I tried rebuild the friendbook-jsp war by adding the dispatcher class to the ../classes, update the web.xml DTD. Any other leads? thanks. Calvin Feb 20, 2003 4:33:20 PM PST Error Management 14 InvocationTargetExc eption getting attribute ServletPath on MBean mydomain:Location=myserver,Name=my server_myserver_friendbook-jsp_weblogic.webservice.server.servlet.WebServiceServ let_760,ServerRuntime=myserver,Type=ServletRuntime. Method: public java.lang.Str ing weblogic.servlet.internal.ServletRuntimeMBeanImpl.getServletPath() java.lang.NullPointerException at weblogic.servlet.internal.WebAppServletContext.findMappings(WebAppSer vletContext.java:5089) at weblogic.servlet.internal.WebAppServletContext.findPath(WebAppServlet Context.java:5108) at weblogic.servlet.internal.ServletStubImpl.getServletPath(ServletStubI mpl.java:1028) at weblogic.servlet.internal.ServletRuntimeMBeanI! mpl.getServletPath(Serv letRuntimeMBeanImpl.java:102) at java.lang.reflect.Method.invoke(Native Method) at weblogic.management.internal.DynamicMBeanImpl.getAttribute(DynamicMBe anImpl.java:567) at com.sun.management.jmx.MBeanServerImpl.getAttribute(MBeanServerImpl.j ava:1183) at com.sun.management.jmx.MBeanServerImpl.getAttribute(MBeanServerImpl.j ava:1153) at weblogic.management.internal.RemoteMBeanServerImpl.getAttribute(Remot eMBeanServerImpl.java:844) at weblogic.management.internal.MBeanProxy.getAttribute(MBeanProxy.java: 246) at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:176) ! nbsp; at $Proxy78.getServletPath(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at weblogic.management.console.info.ReflectingAttribute.doGet(Reflecting Attribute.java:110) Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more
Re: [Mav-user] ModelLifeTime / discard() not guaranteed
- Original Message - From: Aapo Laakkonen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 11:48 AM Subject: RE: [Mav-user] ModelLifeTime / discard() not guaranteed Though I haven't given it a extensive testing, using document views that point to other commands seems to work for me. Is this not sufficient? But I think that it uses client side redirection. Think about 10 actions in a chain. no--redirect views use client side redirection. document views basically use a RequestDispatcher include so it is all server-side. Of course you can extend commands, or call different commands directly from other commands, but that ties commands together. I'd like to see them independend that can be configured runtime with mapping. So I could possibly change the behavior of execution by only editing mapping XML file. Other things: I saw you talking in a forum about FormProc integration or example that takes advantage of FormProc, what is it's state? Is this directed to me or jeff? If me, I don't remember this? Do you have a link to the forum page to refresh my memory? --jim --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ [INVALID FOOTER] --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ [INVALID FOOTER]
Re: [Mav-user] Java XML View open source project
Hi Gal, I'm not too concerned about the xsl not running correctly--I was expecting these to be broken, but I couldn't write correct ones until I could see the xml being procuced by jxv. To halt mav's transform chain, you can use the maxTransforms param: i.e. http://localhost:8080/Friendbook/friends.m would show you the standard output, but http://localhost:8080/Friendbook/friends.m?maxTransforms=0 would show you the output before any transforms had been run (in other words, this would just dump the raw xml produced by jxv to the browser). As for the unclosed tag, you are right--looking my working copy it is correct, but I packed up a brokenone.oops. --jim - Original Message - From: Gal Binyamini To: [EMAIL PROTECTED] ; jim moore Sent: Wednesday, November 20, 2002 9:15 PM Subject: Re: [Mav-user] Java XML View open source project Hi Jim, Thanks for your reply. I took a look at your example and the first problem was simply that I didn't include the Map factory support in the 0.2 release, because I didn't think it was very usefull and I wanted to test it a little more. Anyway, I have it working in my CVS working copy and I will make another release including this soon. After correcting this no exception is thrown. But the XSLT template is not running correctly, presumably because the XML generated by JXV is not the same as that generated by Domify. If you could show me a piece of XML code demonstrating what type of XML you expect to get, I can configure JXV to produce it. p.s.Icame across a suspicious line in the maverick config file: !-- set default-transform-method to "dom" to use dom instead of sax--view-factory type="jxv" provider="org.infohazard.maverick.opt.view.JXVViewFactory" default-transform-method="sax" You don't seem toclose this config element. I guess you had it right in your working copy but forgot to pack the correct version in the JAR. By the way, in the view factory you don't have to check for nulls. JXVhandles them. Gal - Original Message - From: jim moore To: [EMAIL PROTECTED] Sent: Monday, November 18, 2002 7:38 PM Subject: Re: [Mav-user] Java XML View open source project Hi Gal, I started playing around with making a custom view for Maverick that uses JXV but it seems to blow up pretty readily (JXV that is, not the custom view). If you want to see how far I've gotten, you can download what I have here and play around with it: http://www.scolamoore.com/jim/opt-jxv-20021118.zip --jim - Original Message - From: Gal Binyamini To: [EMAIL PROTECTED] Sent: Sunday, November 17, 2002 8:25 PM Subject: Re: [Mav-user] Java XML View open source project Heh, forgot the address... it's http://jxv.sf.net. - Original Message - From: Gal Binyamini To: [EMAIL PROTECTED] Sent: Monday, November 18, 2002 3:06 AM Subject: [Mav-user] Java XML View open source project Hello all. I have recently released version 0.2 of JXV, an open source project aimed to convert Java objects into "XML views". JXV supports the same type of dynamic DOM tree implemented in Domify, and also implements a SAX-based approach which is usually more scalable. Here is a copy of the release announcement: -- start of quote I am pleased to announce the first public release of JXV. JXV is a library which allows for Java objects to be given "XML Views", and for those views to be read back into objects. JXV supports both SAX and DOM output, and can read XML input from any SAX-compliant parser. Resulting DOM trees are dynamic, and reflect changes made to the object model even after they were created. JXV fully supports namespaces in it's XML views, and can correctly parse and read XML content with namespaces. JXV uses a pluggable architecture which allows XML view factories to be configured and loaded at runtime. The JXV configuration mechanisms also leverage XML namespaces to allow the configurations for those different view factories to be inlined within the JXV configuration file. In this release, JXV comes pre-configured with view factories for JavaBeans, collections, array, and "flat objects" such as Strings, primitives, etc. These factories support a wide variety of configuration options, and are sufficient for most object models. Future versions of JXV will include pre-conf
Re: [Mav-user] Integrating Maverick into an existing project
Hi Victor, I just started doing this on a project as well. So far everything is going very smoothly--just replacing servlets one at a time with mav controllers. Session sharing is no problem (maverick has access to the standard HttpSession). --jim - Original Message - From: Victor Rodriguez [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 11:08 AM Subject: [Mav-user] Integrating Maverick into an existing project Hello all, I want to integrate Maverick into an existing project. Unfortunately, recoding everything to use Maverick at once is not an option, so Maverick will have to co-exist with our own MVC framework which uses servlets and jsps to generate content. Has anyone done something like this? Do you think it is possible? Is there anything I should watch out for? At the very least, Maverick should use a session created by the other framework, and not use a new one. Can this be done? Thanks in advance for your suggestions! Best Regards, Victor. -- victor m. rodriguez | ximis | telephone 915.832.0134 | fax 915.832.0135 6006 north mesa st. | suite 902 | coronado tower | el paso | tx | 79912 --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en [INVALID FOOTER] --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en [INVALID FOOTER]
Re: [Mav-user] Large sites, performance issues?
- Original Message - From: Al Butler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 11:17 AM Subject: RE: [Mav-user] Large sites, performance issues? I'm not using Maverick per se' but my experience with apps using XSL is that it's the servlet container that takes time. I use Xalan. Do you cache the XSL docs in memory? I don't know if you can get away with doing this under Maverick. Yes maverick supports this. Actually has 3 settings for xsl templates caching: preload , lazy, and disabled disabled disables template caching and is very helpful on a dev server, but should never be used on a production server. On a production server, use preload or lazy. preload will load all the templates at startup or when the reload command is issued. This is the default setting. lazy will load the templates when they are first called. This will make startup and reload much faster, but will cause pages to load slower the first time they are accessed as the template will have to be loaded. Magnus, I suspect that you may want to experiment with the lazy setting to fix your slow reload problem. Use it like so: transform-factory type=xslt provider=org.infohazard.maverick.transform.XSLTransformFactory template-caching value=lazy/ /transform-factory Is the XML data up in memory or does it go to a disk first before the parse? Grab O'Reilly's book Java XSLT. It's got some good chapters and also I think that their performance chapter is free on the web somewhere. Again, don't know if it pertains to Mac. Also, does Orion really make a difference ? thank al -Original Message- From: [EMAIL PROTECTED] [mailto:mav-user-admin;lists.sourceforge.net]On Behalf Of Magnus Rosenquist Sent: Thursday, October 31, 2002 10:40 AM To: Maverick user mailinglist Subject: [Mav-user] Large sites, performance issues? Hello, I've been using Maverick for a couple of months now, building an SMS-sending application. First of all, I must say I'm very impressed with the Maverick package and it has worked extremely well during the development cycle. Since I'm using Maverick and Domify to produce XML from the controllers and transforming using XSLT, my biggest obstacle was to get aquainted with transforming XSLT in a nice and efficient way. I don't think that I've managed to write very efficient XSLT transforms though, but they work... I've been developing on Tomcat 4.0.4 and 4.1.12 on Linux using Sun's Jdk 1.4.01 and I recently switched to Orion to see if I get any performance boost. Now, to my issues. The application consists of about 68 commands, and about 200 views for displaying. The number of views are very high I know, but this is a localized site (english and swedish). Question: Is 68 commands and 200 views a lot ? The reason I'm asking is that Tomcat seems to choke on the number of views when reloading the application. This seems happens mostly when I use the reload command in Maverick to reload config. At startup it loads the commands and views fine, but when I reload it takes forever. I've experienced the same phenomena in Orion as well, but Orion is still a monster of speed compared to Tomcat (I guess I already knew that). It starts the application and loads the commands and view really fast, but experiences the same problem when reloading. Could this be a Maverick issue? Another question: The actual bulk of processing a view seems to be in the XSLT transformations. Processing the controller and all database-stuff usually takes milliseconds compared to the XSLT transformation which can take about a second or so. This is quite ok and I understand why it takes that much time, but what I wonder is if anybody has tried another (and hopefully faster) XSLT-processor than Xalan. I tried using Saxon but it didn't work, it loaded all the views ok (almost) but it didn't manage to transform any XML (I got empty pages). Thanks for a great package! regards, /Magnus -- Magnus Rosenquist Zyneo http://www.zyneo.com --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en [INVALID FOOTER] --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en [INVALID FOOTER] --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en [INVALID FOOTER]
Re: [Mav-user] accessing Request from domify
Should be able to add a method getParameterMap() (or whatever you wanna call
it) to your model as below:
public Map getParameterMap() {
//this.getRequest() will also have to be defined, but you probably want
it
//as private so that domify doesn't domify the whole thing
HttpServletRequest request = this.getRequest();
return request.getParameterMap();
}
domify should domify a Map just fine.
--jim
- Original Message -
From: Charles N. Harvey III [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 25, 2002 5:08 PM
Subject: [Mav-user] accessing Request from domify
Hello.
I would like all the values in the HttpServletRequest to be placed in the
model in domify. I can access all the request values if I am using
velocity because the VelocityViewServlet already puts the request object
in the context. $request.getServerRoot(), $request.getParameter('name').
I think all I have to do is turn all the parts of the request object into
a map and create a public method for get(ting) it. Has anybody else done
this some other way?
Thanks.
Charlie
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
Re: [Mav-user] init error
If you look at the bottom of the stack trace, you will see that the root cause is: - Original Message - From: Charles N. Harvey III [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 20, 2002 4:01 PM Subject: [Mav-user] init error I have a webapp with domify in the WEB-INF/lib directory and the usual maverick stuff at the top of my web.xml file. When I start up Tomcat I am getting this error. Its as if the Dispatcher class isn't there. But I know it is. Any ideas? Thanks a lot. Charlie -- -- -- 2002-09-20 15:51:47 StandardContext[/staffingauthority]: Servlet /staffingauthority threw load() exception javax.servlet.ServletException: Error instantiating servlet class org.infohazard.maverick.Dispatcher at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:89 3) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:808) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java: 3266) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3395) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:785) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:454) at org.apache.catalina.core.StandardHost.install(StandardHost.java:714) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:300) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:389) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:232) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:155) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343) at org.apache.catalina.core.StandardService.start(StandardService.java:388) at org.apache.catalina.core.StandardServer.start(StandardServer.java:506) at org.apache.catalina.startup.Catalina.start(Catalina.java:781) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) - Root Cause - java.lang.NoClassDefFoundError: javax/xml/transform/TransformerException at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
Re: [Mav-user] init error
If you look at the bottom of the stack trace, you will see that the root cause is: java.lang.NoClassDefFoundError: javax/xml/transform/TransformerException My guess is you are using jdk1.3 and don't have xml-apis.jar in your classpath. Or maybe you don't have xerces.jar or xalan.jar in there. --jim - Original Message - From: Charles N. Harvey III [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 20, 2002 4:01 PM Subject: [Mav-user] init error I have a webapp with domify in the WEB-INF/lib directory and the usual maverick stuff at the top of my web.xml file. When I start up Tomcat I am getting this error. Its as if the Dispatcher class isn't there. But I know it is. Any ideas? Thanks a lot. Charlie -- -- -- 2002-09-20 15:51:47 StandardContext[/staffingauthority]: Servlet /staffingauthority threw load() exception javax.servlet.ServletException: Error instantiating servlet class org.infohazard.maverick.Dispatcher at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:89 3) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:808) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java: 3266) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3395) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:785) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:454) at org.apache.catalina.core.StandardHost.install(StandardHost.java:714) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:300) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:389) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:232) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:155) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343) at org.apache.catalina.core.StandardService.start(StandardService.java:388) at org.apache.catalina.core.StandardServer.start(StandardServer.java:506) at org.apache.catalina.startup.Catalina.start(Catalina.java:781) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) - Root Cause - java.lang.NoClassDefFoundError: javax/xml/transform/TransformerException at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
Re: [Mav-user] init error
They just have to be on the the classpath. Dropping them (all 3 of them) into the lib folder of your web app (everything in there will be on the classpath) should do it. Alternately you could put them in tomcat's lib folder, then all webapps would have access to them. Your call. --jim - Original Message - From: Charles N. Harvey III [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 20, 2002 4:13 PM Subject: RE: [Mav-user] init error Bingo. That is exactly what is at the bottom of the stacktrace. Should I put xalan or xerces in the lib? Or do I just need to put xml-apis.jar in the lib? Or should they all be in the classpath as well as the lib? Thanks so much for the help. Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of jim moore Sent: Friday, September 20, 2002 4:07 PM To: [EMAIL PROTECTED] Subject: Re: [Mav-user] init error If you look at the bottom of the stack trace, you will see that the root cause is: java.lang.NoClassDefFoundError: javax/xml/transform/TransformerException My guess is you are using jdk1.3 and don't have xml-apis.jar in your classpath. Or maybe you don't have xerces.jar or xalan.jar in there. --jim - Original Message - From: Charles N. Harvey III [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 20, 2002 4:01 PM Subject: [Mav-user] init error I have a webapp with domify in the WEB-INF/lib directory and the usual maverick stuff at the top of my web.xml file. When I start up Tomcat I am getting this error. Its as if the Dispatcher class isn't there. But I know it is. Any ideas? Thanks a lot. Charlie -- -- -- 2002-09-20 15:51:47 StandardContext[/staffingauthority]: Servlet /staffingauthority threw load() exception javax.servlet.ServletException: Error instantiating servlet class org.infohazard.maverick.Dispatcher at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:89 3) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:808) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java: 3266) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3395) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:785) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:454) at org.apache.catalina.core.StandardHost.install(StandardHost.java:714) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:300) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:389) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:232) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:155) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343) at org.apache.catalina.core.StandardService.start(StandardService.java:388) at org.apache.catalina.core.StandardServer.start(StandardServer.java:506) at org.apache.catalina.startup.Catalina.start(Catalina.java:781) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) - Root Cause - java.lang.NoClassDefFoundError: javax/xml/transform/TransformerException at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com
Re: [Mav-user] init error
Try moving them into tomcat's lib folder just as an experiment. I seem to remember having this problem before myself. I think web-apis.jar might need to be in tomcat's lib folder, but xalan can be in the webapp's lib I believe, but I'm not completely sure, so you might just play around with different combinations. I think it might be a load order thing. i.e. tomcat's trying to load xalan (which requires classes in xml-apis.jar) before xml-apis.jar has been loaded. --jim - Original Message - From: Charles N. Harvey III [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 20, 2002 4:51 PM Subject: RE: [Mav-user] init error Argh. I put all three in my buid.xml so they get copied into the WEB-INF/lib directory. And they have definately been copied. I fire-up tomcat and I still get the exact same stacktrace. Do I maybe have the wrong versions? I just got the newest xalan (which comes with xml-apis.jar) from xml.apache.org. Thanks again. This is helping a lot. Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of jim moore Sent: Friday, September 20, 2002 4:17 PM To: [EMAIL PROTECTED] Subject: Re: [Mav-user] init error They just have to be on the the classpath. Dropping them (all 3 of them) into the lib folder of your web app (everything in there will be on the classpath) should do it. Alternately you could put them in tomcat's lib folder, then all webapps would have access to them. Your call. --jim - Original Message - From: Charles N. Harvey III [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 20, 2002 4:13 PM Subject: RE: [Mav-user] init error Bingo. That is exactly what is at the bottom of the stacktrace. Should I put xalan or xerces in the lib? Or do I just need to put xml-apis.jar in the lib? Or should they all be in the classpath as well as the lib? Thanks so much for the help. Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of jim moore Sent: Friday, September 20, 2002 4:07 PM To: [EMAIL PROTECTED] Subject: Re: [Mav-user] init error If you look at the bottom of the stack trace, you will see that the root cause is: java.lang.NoClassDefFoundError: javax/xml/transform/TransformerException My guess is you are using jdk1.3 and don't have xml-apis.jar in your classpath. Or maybe you don't have xerces.jar or xalan.jar in there. --jim - Original Message - From: Charles N. Harvey III [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 20, 2002 4:01 PM Subject: [Mav-user] init error I have a webapp with domify in the WEB-INF/lib directory and the usual maverick stuff at the top of my web.xml file. When I start up Tomcat I am getting this error. Its as if the Dispatcher class isn't there. But I know it is. Any ideas? Thanks a lot. Charlie -- -- -- 2002-09-20 15:51:47 StandardContext[/staffingauthority]: Servlet /staffingauthority threw load() exception javax.servlet.ServletException: Error instantiating servlet class org.infohazard.maverick.Dispatcher at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:89 3) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:808) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java: 3266) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3395) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:785) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:454) at org.apache.catalina.core.StandardHost.install(StandardHost.java:714) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:300) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:389) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:232) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:155) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343) at org.apache.catalina.core.StandardService.start(StandardService.java:388) at org.apache.catalina.core.StandardServer.start(StandardServer.java:506) at org.apache.catalina.startup.Catalina.start(Catalina.java:781) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method
[Mav-user] jxv and betwixt views
So I spent a little while this morning screwing around with making jxv and
betwixt views. JXV contains DOMSource and SAXSource objects (not the exact
names, but close enough) that should be able to passed to TransformSteps
though step.go(source). Unfortunately, both break in different ways.
Betwixt has a SAXBeanWriter object that is created from a SAX
ContentHandler, so theoretically we should be able to use it in maverick as
so:
TransformStep next = vctx.getNextStep();
SAXBeanWriter sbw = new SAXBeanWriter(next.getSAXHandler());
try {
sbw.write(vctx.getModel());
} catch (SAXException ex) {
throw new ServletException(ex);
} catch (IntrospectionException ex) {
throw new ServletException(ex);
}
next.done();
Unfortunately this too blows up with some pretty cryptic errors.
The problem with both packages does not seem to be with Maverick but rather
with jxv and betwixt themselves. Neither has release versions available (I
had to build both from cvs) and I think for now they are still too unstable
to be useful.
On the upside though, once they are stable, it shouldn't take too long to
write maverick views for them (it took me about 30 minutes total to write
both views, basing them on opt-domify).
--jim
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
[Mav-user] opt-betwixt
Okay a little more playing around and I've gotten a betwixt view working.
The trouble seemed to be with their SAXBeanWriter. They have another
BeanWriter that simply writes to a stream. Using this I got it to work. I
assume that it's not going to be as efficient as the SAXBeanWriter, but it
works. And it should prove a good place holder until their SAXBeanWriter is
working. Once it is, we should be able to simply update opt-betwixt. I
assume that the xml produced will be the same, so no one should even have to
update their projects.
You can get it here:
http://www.scolamoore.com/jim/opt-betwixt-20020910.zip
It's pretty heavily based on opt-domify, so Jeff and Scott deserve much of
the credit.
There is a friendbook-betwixt in there that works if you want an example.
--jim
- Original Message -
From: jim moore [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 10, 2002 12:39 PM
Subject: [Mav-user] jxv and betwixt views
So I spent a little while this morning screwing around with making jxv and
betwixt views. JXV contains DOMSource and SAXSource objects (not the exact
names, but close enough) that should be able to passed to TransformSteps
though step.go(source). Unfortunately, both break in different ways.
Betwixt has a SAXBeanWriter object that is created from a SAX
ContentHandler, so theoretically we should be able to use it in maverick
as
so:
TransformStep next = vctx.getNextStep();
SAXBeanWriter sbw = new SAXBeanWriter(next.getSAXHandler());
try {
sbw.write(vctx.getModel());
} catch (SAXException ex) {
throw new ServletException(ex);
} catch (IntrospectionException ex) {
throw new ServletException(ex);
}
next.done();
Unfortunately this too blows up with some pretty cryptic errors.
The problem with both packages does not seem to be with Maverick but
rather
with jxv and betwixt themselves. Neither has release versions available (I
had to build both from cvs) and I think for now they are still too
unstable
to be useful.
On the upside though, once they are stable, it shouldn't take too long to
write maverick views for them (it took me about 30 minutes total to write
both views, basing them on opt-domify).
--jim
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
Re: [Mav-user] opt-betwixt
No problem at all. I've actually had cyclical problems myself with
opt-domify. Don't ask me for a psychological analysis of why I finally got
around to doing this when someone else needed it but not when I did
myself :-)
As for the fast coder bit, I think most of the credit in this case is due to
Jeff's excellent design and mav's pluggability.
--jim
- Original Message -
From: Johan Lundberg [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 10, 2002 6:23 PM
Subject: Re: [Mav-user] opt-betwixt
Jim
What can I say? Thanks a lot! You must be a fast coder... It doesn't
look to difficult, but isn't that always the case when you have the
answer in front of you? I'll try to use it in my application right away.
thank you
/johan
jim moore wrote:
Okay a little more playing around and I've gotten a betwixt view
working.
The trouble seemed to be with their SAXBeanWriter. They have another
BeanWriter that simply writes to a stream. Using this I got it to work.
I
assume that it's not going to be as efficient as the SAXBeanWriter, but
it
works. And it should prove a good place holder until their SAXBeanWriter
is
working. Once it is, we should be able to simply update opt-betwixt. I
assume that the xml produced will be the same, so no one should even
have to
update their projects.
You can get it here:
http://www.scolamoore.com/jim/opt-betwixt-20020910.zip
It's pretty heavily based on opt-domify, so Jeff and Scott deserve much
of
the credit.
There is a friendbook-betwixt in there that works if you want an
example.
--jim
- Original Message -
From: jim moore [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 10, 2002 12:39 PM
Subject: [Mav-user] jxv and betwixt views
So I spent a little while this morning screwing around with making jxv
and
betwixt views. JXV contains DOMSource and SAXSource objects (not the
exact
names, but close enough) that should be able to passed to TransformSteps
though step.go(source). Unfortunately, both break in different ways.
Betwixt has a SAXBeanWriter object that is created from a SAX
ContentHandler, so theoretically we should be able to use it in maverick
as
so:
TransformStep next = vctx.getNextStep();
SAXBeanWriter sbw = new SAXBeanWriter(next.getSAXHandler());
try {
sbw.write(vctx.getModel());
} catch (SAXException ex) {
throw new ServletException(ex);
} catch (IntrospectionException ex) {
throw new ServletException(ex);
}
next.done();
Unfortunately this too blows up with some pretty cryptic errors.
The problem with both packages does not seem to be with Maverick but
rather
with jxv and betwixt themselves. Neither has release versions available
(I
had to build both from cvs) and I think for now they are still too
unstable
to be useful.
On the upside though, once they are stable, it shouldn't take too long
to
write maverick views for them (it took me about 30 minutes total to
write
both views, basing them on opt-domify).
--jim
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
Re: [Mav-user] opt-betwixt
I would vote for letting them co-exist for a while. At least until betwixt
is officially released. (I'm kind of nervous about deprecating production
code and replacing it with pre-release code).
Once jakarta officially releases betwixt, then we can re-examine how (or if)
to deprecate opt-domify.
As for all of the optional packages, I agree that it seems to be getting a
bit unwieldy (and I'm probably heavily responsible). Maybe we should do
something like nant (http://nant.sourceforge.net) does and have a separate
project on sourceforge--mavcontrib or opt-mav or something--for all of the
optional files. Then people new to maverick wouldn't be overwhelmed by all
the optional stuff on the files page, but it would all still be pretty
readily available should they need it.
On the other hand, having the optional packages in the maverick project
probably keeps its sourceforge activity statistics higher than they would
be, so from a public relations point of view, maybe its better to keep them
together.
--jim
- Original Message -
From: Schnitzer, Jeff [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 10, 2002 4:31 PM
Subject: RE: [Mav-user] opt-betwixt
Cool!
I didn't realize that betwixt had a SAX (or stream) generator in it.
That is really nice.
Any suggestions for a deprecation strategy for Domify? Thoughts:
1. Publish opt-betwixt (or opt-saxify?) and let them coexist.
2. Add the betwixt adapter to opt-domify and let them coexist in the
same package.
3. Replace the domify adapter with the betwixt adapter inside
opt-domify.
4. ?
I'm a little worried that people are getting confused by all the
optional packages. Putting an explanation in the docs would probably
help (maybe this weekend). I'm somewhat partial to putting all the
stuff for people interested in using XSL as a templating technology in
one package.
Jeff Schnitzer
[EMAIL PROTECTED]
-Original Message-
From: jim moore [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 10, 2002 12:32 PM
To: [EMAIL PROTECTED]
Subject: [Mav-user] opt-betwixt
Okay a little more playing around and I've gotten a betwixt view
working.
The trouble seemed to be with their SAXBeanWriter. They have another
BeanWriter that simply writes to a stream. Using this I got it to
work. I
assume that it's not going to be as efficient as the SAXBeanWriter,
but it
works. And it should prove a good place holder until their
SAXBeanWriter
is
working. Once it is, we should be able to simply update opt-betwixt. I
assume that the xml produced will be the same, so no one should even
have
to
update their projects.
You can get it here:
http://www.scolamoore.com/jim/opt-betwixt-20020910.zip
It's pretty heavily based on opt-domify, so Jeff and Scott deserve
much of
the credit.
There is a friendbook-betwixt in there that works if you want an
example.
--jim
- Original Message -
From: jim moore [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 10, 2002 12:39 PM
Subject: [Mav-user] jxv and betwixt views
So I spent a little while this morning screwing around with making
jxv
and
betwixt views. JXV contains DOMSource and SAXSource objects (not the
exact
names, but close enough) that should be able to passed to
TransformSteps
though step.go(source). Unfortunately, both break in different ways.
Betwixt has a SAXBeanWriter object that is created from a SAX
ContentHandler, so theoretically we should be able to use it in
maverick
as
so:
TransformStep next = vctx.getNextStep();
SAXBeanWriter sbw = new SAXBeanWriter(next.getSAXHandler());
try {
sbw.write(vctx.getModel());
} catch (SAXException ex) {
throw new ServletException(ex);
} catch (IntrospectionException ex) {
throw new ServletException(ex);
}
next.done();
Unfortunately this too blows up with some pretty cryptic errors.
The problem with both packages does not seem to be with Maverick but
rather
with jxv and betwixt themselves. Neither has release versions
available
(I
had to build both from cvs) and I think for now they are still too
unstable
to be useful.
On the upside though, once they are stable, it shouldn't take too
long
to
write maverick views for them (it took me about 30 minutes total to
write
both views, basing them on opt-domify).
--jim
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r
RE: [Mav-user] opt-betwixt
Yes, you are right. the betwixt xml is not identical to the domify xml. One thing I noticed when converting Friendbook was that in Domify, collections have item nodes under them like: friends item.../item item.../item item.../item /friends But betwixt seems to use the name on the class of the item and produces: friends Friend.../Friend Friend.../Friend Friend.../Friend /friends Similarly in domify, phoneList item.../item item.../item /phoneList In betwixt looks like: phoneList String.../String String.../String /phoneList This was the only difference I noticed (though obviously friendbook is a pretty small example), so it may be pretty easy to do the conversion (just look for item tags in your domify xsl's and fix them). When I said I assume that the xml produced will be the same, I meant the xml produced by betwixt's BeanWriter vs. betwixt's SAXBeanWriter, not the xml produced by domify vs. betwixt. Actually I was pretty happily surprised how close the xml produced by the two libraries was. --jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Johan Lundberg Sent: Tuesday, September 10, 2002 9:05 PM To: [EMAIL PROTECTED] Subject: Re: [Mav-user] opt-betwixt I have to agree with Jim on this. Having done the first tests with opt-betwixt it seems that the Bean - XML doesn't render identical XML. Most parts of my app looks fine but the opt-domify compatible XSL templates have in some nodes trouble with the Betwixt XML. I don't think that it is difficult to adjust the XSL templates but imposing a XSL template rewrite on other developers might not be a good thing. Most people seem happy with opt-domify... at the moment. The problem for me right now it to make the 'maxTransforms' to work for me now that Betwixt has taken over. Any hints would be welcome ;) I have not come to the point where I can test the cyclic reference graphs, but I'll get back on that when I have tested this. /johan jim moore wrote: I would vote for letting them co-exist for a while. At least until betwixt is officially released. (I'm kind of nervous about deprecating production code and replacing it with pre-release code). Once jakarta officially releases betwixt, then we can re-examine how (or if) to deprecate opt-domify. As for all of the optional packages, I agree that it seems to be getting a bit unwieldy (and I'm probably heavily responsible). Maybe we should do something like nant (http://nant.sourceforge.net) does and have a separate project on sourceforge--mavcontrib or opt-mav or something--for all of the optional files. Then people new to maverick wouldn't be overwhelmed by all the optional stuff on the files page, but it would all still be pretty readily available should they need it. On the other hand, having the optional packages in the maverick project probably keeps its sourceforge activity statistics higher than they would be, so from a public relations point of view, maybe its better to keep them together. --jim - Original Message - From: Schnitzer, Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 10, 2002 4:31 PM Subject: RE: [Mav-user] opt-betwixt Cool! I didn't realize that betwixt had a SAX (or stream) generator in it. That is really nice. Any suggestions for a deprecation strategy for Domify? Thoughts: 1. Publish opt-betwixt (or opt-saxify?) and let them coexist. 2. Add the betwixt adapter to opt-domify and let them coexist in the same package. 3. Replace the domify adapter with the betwixt adapter inside opt-domify. 4. ? I'm a little worried that people are getting confused by all the optional packages. Putting an explanation in the docs would probably help (maybe this weekend). I'm somewhat partial to putting all the stuff for people interested in using XSL as a templating technology in one package. Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: jim moore [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 10, 2002 12:32 PM To: [EMAIL PROTECTED] Subject: [Mav-user] opt-betwixt Okay a little more playing around and I've gotten a betwixt view working. The trouble seemed to be with their SAXBeanWriter. They have another BeanWriter that simply writes to a stream. Using this I got it to work. I assume that it's not going to be as efficient as the SAXBeanWriter, but it works. And it should prove a good place holder until their SAXBeanWriter is working. Once it is, we should be able to simply update opt-betwixt. I assume that the xml produced will be the same, so no one should even have to update their projects. You can get it here: http://www.scolamoore.com/jim/opt-betwixt-20020910.zip It's pretty heavily based on opt-domify, so Jeff and Scott deserve much of the credit. There is a friendbook-betwixt
RE: [Mav-user] opt-betwixt
Yes. maxTransforms worked perfectly for me in friendbook-betwixt. --jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Schnitzer, Jeff Sent: Tuesday, September 10, 2002 7:24 PM To: '[EMAIL PROTECTED]' Subject: RE: [Mav-user] opt-betwixt All good points. Sure, let everything coexist. maxTransforms should work no matter what view/transformation technology you use. Are you defining the servlet init-param properly in your web.xml? !-- This allows an extra query parameter to be added to any request which halts the transformation process after that number of steps, e.g. blah.m?maxTransforms=0 -- init-param param-namelimitTransformsParam/param-name param-valuemaxTransforms/param-value /init-param Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Johan Lundberg [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 10, 2002 6:05 PM To: [EMAIL PROTECTED] Subject: Re: [Mav-user] opt-betwixt I have to agree with Jim on this. Having done the first tests with opt-betwixt it seems that the Bean - XML doesn't render identical XML. Most parts of my app looks fine but the opt-domify compatible XSL templates have in some nodes trouble with the Betwixt XML. I don't think that it is difficult to adjust the XSL templates but imposing a XSL template rewrite on other developers might not be a good thing. Most people seem happy with opt-domify... at the moment. The problem for me right now it to make the 'maxTransforms' to work for me now that Betwixt has taken over. Any hints would be welcome ;) I have not come to the point where I can test the cyclic reference graphs, but I'll get back on that when I have tested this. /johan jim moore wrote: I would vote for letting them co-exist for a while. At least until betwixt is officially released. (I'm kind of nervous about deprecating production code and replacing it with pre-release code). Once jakarta officially releases betwixt, then we can re-examine how (or if) to deprecate opt-domify. As for all of the optional packages, I agree that it seems to be getting a bit unwieldy (and I'm probably heavily responsible). Maybe we should do something like nant (http://nant.sourceforge.net) does and have a separate project on sourceforge--mavcontrib or opt-mav or something--for all of the optional files. Then people new to maverick wouldn't be overwhelmed by all the optional stuff on the files page, but it would all still be pretty readily available should they need it. On the other hand, having the optional packages in the maverick project probably keeps its sourceforge activity statistics higher than they would be, so from a public relations point of view, maybe its better to keep them together. --jim - Original Message - From: Schnitzer, Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 10, 2002 4:31 PM Subject: RE: [Mav-user] opt-betwixt Cool! I didn't realize that betwixt had a SAX (or stream) generator in it. That is really nice. Any suggestions for a deprecation strategy for Domify? Thoughts: 1. Publish opt-betwixt (or opt-saxify?) and let them coexist. 2. Add the betwixt adapter to opt-domify and let them coexist in the same package. 3. Replace the domify adapter with the betwixt adapter inside opt-domify. 4. ? I'm a little worried that people are getting confused by all the optional packages. Putting an explanation in the docs would probably help (maybe this weekend). I'm somewhat partial to putting all the stuff for people interested in using XSL as a templating technology in one package. Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: jim moore [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 10, 2002 12:32 PM To: [EMAIL PROTECTED] Subject: [Mav-user] opt-betwixt Okay a little more playing around and I've gotten a betwixt view working. The trouble seemed to be with their SAXBeanWriter. They have another BeanWriter that simply writes to a stream. Using this I got it to work. I assume that it's not going to be as efficient as the SAXBeanWriter, but it works. And it should prove a good place holder until their SAXBeanWriter is working. Once it is, we should be able to simply update opt-betwixt. I assume that the xml produced will be the same, so no one should even have to update their projects. You can get it here: http://www.scolamoore.com/jim/opt-betwixt-20020910.zip It's pretty heavily based on opt-domify, so Jeff and Scott deserve much of the credit. There is a friendbook-betwixt in there that works if you want an example
RE: [Mav-user] cyclic reference graphs in opt-domify
Ah, gotcha. I was assuming betwixt was comparable to domify. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Schnitzer, Jeff Sent: Monday, September 09, 2002 7:01 PM To: '[EMAIL PROTECTED]' Subject: RE: [Mav-user] cyclic reference graphs in opt-domify From: jim moore [mailto:[EMAIL PROTECTED]] I wasn't suggesting writing a DOM façade (agreed that would be difficult). I just meant it should be trivial to write a custom view that wraps betwixt. I don't think betwixt by itself can be used for a view; it's just a way of defining the mapping from Java-XML, not a tool which provides the mapping to DOM/SAX/whatever itself. As for the SAX event idea, wouldn't this suffer from the same cyclical reference difficulty as domify? Seems to me that you would end up firing an infinite set of open element tag events on cyclical references. Not to say that a SAX event firing view isn't a good idea, just that it is probably a project in itself. Yup, SAX events would suffer the same cyclical problem as domify - which is why something like Betwixt is necessary to exclude the paths that have the cycles. At the moment, Domify isn't that smart because we expected XSLT processors to be intelligent about how they navigate the DOM. Xalan 2.1 was, but more recent versions aren't :-( A quick solution to the cycle problem might be to switch to Xalan 2.1. A more satisfying solution would be to replace Domify with a betwixt-based Saxify. Still pretty easy to build, but probably not a couple hours work, unfortunately. Jeff Schnitzer [EMAIL PROTECTED] --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=urceforge1refcode1=3390 ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
RE: [Mav-user] cyclic reference graphs in opt-domify
It seems to me that complicating your application (the dual model layers) just to get Maverick to work for you is a bad way to go (the whole point of Maverick is to simplify web application development). Particularly when there is a far more workable solution that would have the added benefit of adding to the project/community, namely creating a custom view to use betwixt or java xml view. Despite your never having looked under the hood, I don't think you'll have too much trouble writing a custom view--I think it took me about 2 or 3 hours at most to write the first iteration of opt-fop (which was originally a custom view--now it is a transform). And that time included figuring out what was going on under the hood --jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Johan Lundberg Sent: Sunday, September 08, 2002 5:11 PM To: [EMAIL PROTECTED] Subject: [Mav-user] cyclic reference graphs in opt-domify Hi Background: I am using Maverick in combination with Torque (Jakarta project), which is a Java layer that simplifies DB-access for a Java programmer. Torque automagically gives me Java beans from a DB-schema. I am using the opt-domify package that is provided together with Maverick. The problem: The problem occurs when my torque generated Java beans have cyclic reference graphs or methods like getCopyOfBean(). The XML-tree that is generated will appear to continue on and on and on and on, until I get a 'out of memory error'. Possible solutions: Jeff hinted me about the possibility to implement a new ViewFactory for Betwixt (Jakarta project) or 'Java XML View' (Sourceforge). These two packages can solve the issue with cyclic reference graphs. I am just a Maverick user and have never looked under the hood, so I don't know what kind of effort that takes but it seems scary ;) The other solution could be to have a model of beans for the Maverick WEB-layer and one model for the DB-layer. Then it would be easier to avoid cyclic reference graphs since the Maverick WEB-layer beans could be filled with data in a controlled way. Unfortunately, this would create some overhead and also slow down the application. Why ask the list?: I am sure that some of you have run into the same problem, which should also occur when using EJBs which are referencing each other. I am curious to get info about what would be the best way to solve this. /johan --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
Re: [Mav-user] Why : URL param sent to the next URL with strange URL param build ing
done. its in cvs now. --jim - Original Message - From: Schnitzer, Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Feutrier Olivier [EMAIL PROTECTED]; Bocquet Stéphane [EMAIL PROTECTED] Sent: Tuesday, August 20, 2002 9:32 PM Subject: RE: [Mav-user] Why : URL param sent to the next URL with strange URL param build ing Yup, that looks like a bug. If you can wait until Friday (when my DSL gets installed), I'll fix it before I run off to Burning Man. Unfortunately Scott's already out at the site doing prep work for the DPW. Jim, do you want to tackle this right now? I think you can just check to see if the value instanceof Object[] and add multiple parameters if that's the case. Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Feutrier Olivier [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 5:21 AM To: [EMAIL PROTECTED] Cc: Bocquet Stéphane Subject: [Mav-user] Why : URL param sent to the next URL with strange URL param build ing Hi, The method RedirectView.addQueryParams() builds the next URL parameter thanks to the previous URL parameters (entries). Why do you sent these URL parameters to the next URL with different URL param building, what are the concept, the usage ? See, I have a default page (default.m) with the link : http://localhost/common/testsecurity.m?login=testpassword=testetacode=ME TZ 01D I click it and I return SUCCESS. The URL returned by Maverick is : http://localhost/common/default.m?etacode=%5BLjava.lang.String%3B%405780d9 p assword=%5BLjava.lang.String%3B%40c4795elogin=%5BLjava.lang.String%3B%40c af 083 The request parameters are different, why ? The maverick XML file content is : commands command name=default controller class=fr.delta_diffusion.common.j2ee.ui.ctl.test.Default param name=idpage value=1/ /controller view path=/jsp/common/accueilModel.jsp type=document transform type=document path=/jsp/common/accueil.jsp/ param name=ismenu value=true/ param name=isoutil value=true/ param name=isnavigation value=true/ /view /command command name=testsecurity controller class=fr.delta_diffusion.common.j2ee.ui.ctl.test.TestControllerDispatchOu t param name=idpage value=3/ /controller view name=error type=redirect path=error.m/ view name=success type=redirect path=default.m/ /command ... In fact, the problem is in the class RedirectView method addQueryParams(). The line : url.append(URLEncoder.encode(entry.getValue().toString())) where entry.getValue() is an array. With this instruction, entry.getValue().toString(), we cannot retreive the original parameter value. We obtain : [Ljava.lang.String;@5780d9 something like this... The solution would be to iterate in entry.getValue() to build the URL parameters and have : login=test;value2passord=test ... Is there something to do ? Do you have noticed that ? Best regards Oliver ** Ce message et ses éventuels fichiers attachés sont confidentiels et sont uniquement à l'attention de la personne physique ou morale destinatrice. Si vous avez reçu ce message par erreur, merci d'en avertir l'expéditeur. Ce bas de page assure également que ce message a été vérifié par un anti- virus ** --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=urceforge1refcode1=3390 ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
Re: [Mav-user] still not getting it
The easiest thing to do in this case is have Hello extend ThrowawayBean2.
Then your Hello class is itself your bean--all its setters will be set with
any form parameters, and its getters will be the methods your view uses.
The simplest case would probably be something like:
public class Hello extends ThrowawayBean2 {
private String message = Hello World!;
public String getMessage() {
return message;
}
public void setMessage(String msg) {
this.message = msg;
}
}
Also, if you are planning on using xsl transforms, you probably want to set
your view type to domify (see the opt-domify package and friendbook-domify).
--jim
- Original Message -
From: Charles N. Harvey III [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, August 21, 2002 10:55 AM
Subject: [Mav-user] still not getting it
I have been playing with Maverick for about a week and I love it.
I took apart the friendbook example and have made my own app using
its pieces and it is very well designed. The thing that I'm still
not getting though is a basic 'hello world' example.
I would like to have something like this in my mav.xml file:
command name=hello
controller class=Hello/
view
transform path=hello.xsl/
transform path=outside.xsl/
/view
/command
Whether its XSLT, Velocity or JSP doesn't really concern me, just
the concept.
Then I have WEB-INF/classes/Hello.java.
What does this class have to implement? Should it look like the
FormBeanUser.java file and implement ControllerSingleton? All I
want to do is put text like Hello Maverick in a bean and then print
it out in my view layer. I have done this by using the friendbook
example but can't seem to do it from scratch.
Any help with this would be great. I really want to get this.
Thanks.
Charlie
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
Re: [Mav-user] Using decorator pattern on controllers
This shouldn't be too difficult. Just have your decorator implement ControllerSingleton, then you will get an init method in which the controller node from maverick.xml is passed in. If you had a controller node that looked like: controller class=com.foo.bar.MyControllerDecorator decorated class=com.foo.bar.SomeExistingController /controller Your decorator could hold an internal controller. When the decorator's go method was called, it could call go on the decorated controller, read the result and the model, and still do its own thing. This is actually similar to what I just sent as the CompositeController. --jim - Original Message - From: Roy Truelove [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 09, 2002 12:04 PM Subject: [Mav-user] Using decorator pattern on controllers Hey all, I'm looking into the feasablity of using the Decorator pattern* to create Controllers. In the friendbook example, each controller inherits from another controller which inherits from another controller, each one adding a little functionality. The problem with this is that you can't pick and choose which controllers you want to use, you have to use extentions of extentions. This would certainly help with the composite view issues that are being discussed, as well as securing controllers, etc. The problem is .. how can this be done while keeping Maverick backwards compatable *and* keeping configuration to a minimum? Any ideas? Since controllers are instantiated using reflections and not explicitly, is the Decorator pattern even possible? *Decorator pattern info : http://www.javaworld.com/javaworld/jw-12-2001/jw-1214-designpatterns.html -Roy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
Re: [Mav-user] Using decorator pattern on controllers
On a related note, I'm wondering if we should make ControllerFactory a public class. That way decorators would be free to use it's createController() method. There's a lot of good functionality in there, and I don't really see a reason to hide it away. What do you think Jeff? --jim - Original Message - From: jim moore [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 09, 2002 12:23 PM Subject: Re: [Mav-user] Using decorator pattern on controllers This shouldn't be too difficult. Just have your decorator implement ControllerSingleton, then you will get an init method in which the controller node from maverick.xml is passed in. If you had a controller node that looked like: controller class=com.foo.bar.MyControllerDecorator decorated class=com.foo.bar.SomeExistingController /controller Your decorator could hold an internal controller. When the decorator's go method was called, it could call go on the decorated controller, read the result and the model, and still do its own thing. This is actually similar to what I just sent as the CompositeController. --jim - Original Message - From: Roy Truelove [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 09, 2002 12:04 PM Subject: [Mav-user] Using decorator pattern on controllers Hey all, I'm looking into the feasablity of using the Decorator pattern* to create Controllers. In the friendbook example, each controller inherits from another controller which inherits from another controller, each one adding a little functionality. The problem with this is that you can't pick and choose which controllers you want to use, you have to use extentions of extentions. This would certainly help with the composite view issues that are being discussed, as well as securing controllers, etc. The problem is .. how can this be done while keeping Maverick backwards compatable *and* keeping configuration to a minimum? Any ideas? Since controllers are instantiated using reflections and not explicitly, is the Decorator pattern even possible? *Decorator pattern info : http://www.javaworld.com/javaworld/jw-12-2001/jw-1214-designpatterns.html -Roy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
RE: [Mav-user] Problem with friendbook-jsp
Hi Thomas, Just so I have a bit more info, this happened simply when you dropped friendbook-jsp.war (from the maverick/build directory) into tomcat's webapps folder and then restarted tomcat? You didn't make any changes to any files? This seems peculiar (which certainly does not mean it is not possible). I haven't tried to run friendbook under tomcat 4.04, but I have run it successfully under 4.01, 4.02, and 4.03. If this is the case, I will try installing Tomcat 4.04 and see if I can replicate it. If you had installed friendbook another way, remove the friendbook folder from webapps, drop the friendbook-jsp.war file in there, restart tomcat and see how it goes. Either way, let us know. --jim - Original Message - From: Thomas Wheeler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 31, 2002 2:45 PM Subject: **SPAM** RE: [Mav-user] Problem with friendbook-jsp Is anyone reading this list? Is anyone using Maverick? Seems like a nice framework if I could get it to work... I'd sure like to know what I'm doing wrong here. -Thomas -Original Message- From: Thomas Wheeler Sent: Tuesday, July 30, 2002 5:12 PM To: '[EMAIL PROTECTED]' Subject: RE: [Mav-user] Problem with friendbook-jsp More details. It seems that for an URL ending in .m (processed by Maverick), it's appending the .jsp path to the .m path. For example, clicking the signup.m link causes it to look for /signup.msignup.jsp. -Thomas -Original Message- From: Thomas Wheeler [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 30, 2002 5:02 PM To: '[EMAIL PROTECTED]' Subject: [Mav-user] Problem with friendbook-jsp I'm getting the following exception after deploying the friendbook-jsp in Tomcat 4.0.4, Maverick 2.1.1. What am I missing? javax.servlet.ServletException: /default.jspwelcome.jsp at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:212) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher. java:683) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatch er.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher .java:497) at org.infohazard.maverick.view.DispatchedViewFactory$DispatchedView.go(Dispatc hedViewFactory.java:104) at org.infohazard.maverick.view.DocumentView.go(DocumentView.java:52) at org.infohazard.maverick.flow.ViewWithTransforms.go(ViewWithTransforms.java:3 9) at org.infohazard.maverick.flow.CommandBase.go(CommandBase.java:50) at org.infohazard.maverick.Dispatcher.service(Dispatcher.java:179) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher. java:683) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatch er.java:431) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher .java:355) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:414) at org.apache.jsp.default$jsp._jspService(default$jsp.java:61) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:202) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:190) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve. java:170) at
Re: [Mav-user] Opt-fop and Content-Disposition header
- Original Message - From: Philip Meier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 22, 2002 5:28 PM Subject: Re: [Mav-user] Opt-fop and Content-Disposition header Hello everyone, I am not very active on this list, but now I start a project implementing Maverick and I would be very pleased if the ideas of Jim could be converted in the next version. So I guess that's one +1 How is the priority of several transform types? view name=success type=document path=queryResult.jsp transform type=xslt path=lookAndFeel.xsl/ transform type=fop/ /view The priority is strictly linear based on the order in the maverick.xml file. The view will always run first, the the transforms will be run in the order they appear. In this case, the jsp queryResult.jsp will run first. The output of that jsp will be run through the stylesheet lookAndFeel.xsl. Then the output of that transformation will serve as the input for the fop transform. Couple of things to note. Since the result of queryResult.jsp will serve as the input to lookAndFeel.xsl, you need to make sure that queryResult.jsp produces a valid xml document. Then you need to make sure that the input to fop is a valid fo document. The maxTransforms param is excellent for debugging this as you can use it to halt the transform process at a given step. Which will the client see, if he requests the page? The client will see a pdf. Sorry for my bad english.. ;-) No worries. I'm struggling to learn portuguese right now, so I understand how it is. --jim Regards, Phil --- jim moore [EMAIL PROTECTED] schrieb: Right now it is possible to set the content-dispostion header directly from the controller. You can get the Response from the ControllerContext and then just call response.setHeader() on it. Even when the repsonse is wrapped, the setHeader() calls are passed through to the real underlying response. I think this is pretty straightforward and intuitive, so I don't think there is really a need to change it (though I am open to hearing other thoughts on this). If people still think its worthwhile to have this defined in maverick.xml, I have a couple of ideas. We could add two optional attributes to the fop transform node: filename and content-type. Filename is pretty self-explanatory. Content-type would take either inline (which would be the default) and attachment. Together these two would produce a content-disposition header something like: Content-disposition: attachment; filename=myfile.pdf So you would have a node that looked something like: transform type=fop output=pdf content-type=attachment filename=myfile.pdf/ Even if we add this, I still think the controller should take precedence. Since it runs before the transform, opt-fop could check for the presence of the content-disposition header. It would only set it if it didn't find it. Does this make sense? What are everyone's thoughts? Do you think setting the header from the controller is sufficient, or should we add these params to the transform node? --jim - Original Message - From: Mike Moulton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 22, 2002 4:35 AM Subject: [Mav-user] Opt-fop and Content-Disposition header I started playing with opt-fop for use on an upcoming project and I had a couple comments / questions I would like to ask. First I would like to thank all those involved in producing opt-fop, I think is a very valuable tool. From my quick over of the source I notice that the content type is specified based on the fop render type, however there doesn't seem to be any support for setting a Content-Disposition header. I'm sure there are many cases where the browser will automatically launch an app for the given content type, however for my use I need the browser to prompt the user to save the file with a suggested filename. Currently on browsers that don't have a handler for the supplied content type the file is saved as the name of the command executed, 'friendsPdf.m' in the case of the friendbook-fop example. Is there need by others to do the same thing? If so how should it be handled? I was thinking that we could supply a param to the transform with a filename keyword, or possibly adding an attribute to the transform tag for the filename. What about dynamically producing the filename in the controller; how could this be handled cleanly? -- Mike Moulton [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
Re: [Mav-user] specifying redirects in the maverick.xml file
Personally I think this may just confuse things. Right now the behavior of a redirect is pretty straightforward--its sending a physical redirect to the browser, telling it to ask for the new url you specify (this could be a .html, .jsp, .m, .fo, .pdf, /servlet/foo, whatever). I'm not sure I see what we would achieve be redirecting to a logical view. Are you trying to avoid the roundtrip to the browser and do something closer to a RequestDispather.include() or RequestDispather.forward()? Either way, I don't think I'm in favor of compromising the straightforwardness of the standard redirect view as right now it does exactly what one would expect. That is not to say however that there is no room for this functionality if you need it. Rather than modifying RedirectView, why not take a stab at creating your own LogicalRedirectView, which would take a maverick command as the path attribute, like so: view name=success type=logicalRedirect path=welcome/ Maverick is remarkably pluggable, so plugging in new view types is pretty straigtforward. Check out opt-domify as an example of plugging in a custom view type. --jim - Original Message - From: Roy Truelove [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 03, 2002 11:24 AM Subject: [Mav-user] specifying redirects in the maverick.xml file Hello all, I have a proposal to deal with redirects in the maverick.xml file. Right now redirect paths to commands have to be hardcoded, insofar as you have to specify the redirect not as a logical command name but as a physical URL, i.e.: view name=success type=redirect path=welcome.m/ I'd like to write a patch that would support this type of functionality : view name=success type=redirect path=welcome param name=isCommand value=true/ /view As well as a standard redirect to a non-command: view name=success type=redirect path=somePage.html/ This way all references to commands are logical references rather than physical. If this sounds like a good idea, please let me know, and I'll get cracking. Thanks, Roy --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
RE: [Mav-user] Struts/Maverick
I've been giving this idea of mav merging with struts some thought and while I agree with Jeff's doubt that Maverick-as-Struts-2.0 will ever happen, simply because of Not Invented Here is almost definitely true, I still think it may be worthwhile to try and find a way to move mav to jakarta. If for no other reason, moving mav to jakarta will give maverick major street cred and almost assuredly boost its user base, and as we all know, a strong user base is the life blood of an open source project. There are a lot of organizations that would immediately be willing to consider maverick if it had the apache stamp of approval. I think its pretty clear that replacing struts with mav is an impossibility, and merging it would probably lead to a political mess. I don't think its odd to propose that the two live side-by-side, however. I think the arguement could be made that the two are not mutually exclusive. I personally feel that with its shunting and transforming abilities, mav's major strength is as a presentation framework, while one could argue that Struts is primarily an application framework. While it does offer some application framework functionality, mav has been specifically built to be pluggable, so as Jeff points out, it should be possible to build a ControllerSingleton base class that *exactly* mimics the Struts Action API. When Struts applications run without recompilation on Maverick, that might raise some eyebrows. I think the fact that struts can run inside maverick is a strong mark in our favor that the two can exist simultaneously as separate projects within the same organization without necessarily stepping on each other's toes. Any thoughts, --jim --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
[Mav-user] perl transform
So I was talking to a friend the other night about maverick. He was looking for something very similar for a project he was working on (he needs to pipe output through a number of transforms), and it seemed maverick might fit the bill. The only catch--he needed to transform his stylesheets not only through xsl, but he also needed to run them through a couple of perl scripts. Anyway, I accepted the challenge. The result: http://www.scolamoore.com/jim/opt-perl-20020626.zip You'll need perl installed on on the system path for it to work, but I've tested it in tomcat 4 on linux and win2k and it seems to run fine. There's a friendbook-perl.war in there that you can test out. The download is about 1.1mb. --jim --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
Re: [Mav-user] Heterogeneous transforms are here!
If anyone is feeling adventurous, try out the CVS version of Maverick. Heterogeneous transforms work great! Excellent! Yes, we definitely want to put the FOP transform in an opt-fop package... Jim, would you like CVS access to maintain it? Maybe add a little documentation or a sample webapp? :-) CVS acccess would be great. I've already expanded FopTransform actually to support all of the output formats fop supports (http://xml.apache.org/fop/output.html) that make sense in a web environment (pdf, postscript, svg, mif, xml, text). AWT says it pops open an AWT window, and print is for printing from the command line, so I left those out. I also left out PCL, but can add it if there is demand. So far I have only got results with pdf and postscript. I'm getting a class not found exception with SVG so I'm probably one of the batik jars. xml and text are both throwing index out of bounds exceptions--I'm pretty sure that is a problem with FOP itself. I don't have Adobe Framemaker, so I can't even test mif. Anyway--I'll keep plugging along--I still need to port it to the new interfaces. Hopefully I'll have a little sample web app and some basic documentation ready this weekend or by early next week. The config changes to support the new outputs are minimal: This will still work and will produce pdf's (pdf is the default): transform type=fop/ but now you can also do: transform type=fop output=ps/ valid output options are pdf, postscript, ps (postscript), svg, xml, txt, text, and mif --jim ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
RE: [Mav-user] lazy-load-templates
Yes, I believe this is different than the way the 1.0 version work (by using preloadTemplates). In 1.0, this indicated that the template should be loaded from the file system on each request, instead of cached. This made it read the file on each request. Jim, Is that what you were expecting? yes--this is what I was expecting, that the file would be read on each request. I know this destroys performance, but the performance hit is a small price to pay when developing. It's really annoying to have to hit reload.m everytime you change that spacer gif from a 1 pixel width to 2 to 3 to 4 trying to get the layout right. --jim ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
[Mav-user] problem with beta 2
So I just tried to switch to mav 2 beta 2. Didn't make any changes to my app or maverick.xml (I'm guessing that was my problem), just replaced maverick.jar. Anyway, as soon as I try anything, I get the ServletException below. Any ideas? I'm not sure where this null controller bit is coming from. My controller should be returning success as the view name. --jim javax.servlet.ServletException: Controller specified view null controller, but no view with that name is defined. at org.infohazard.maverick.flow.CommandBase.go(CommandBase.java:54) at org.infohazard.maverick.Dispatcher.service(Dispatcher.java:148) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at com.oreilly.servlet.MultipartFilter.doFilter(MultipartFilter.java:57) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:190) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:2 46) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve. java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :174) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java: 1012) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107 ) at java.lang.Thread.run(Thread.java:536) ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
Re: [Mav-user] problem with beta 2
yep--that's the problem. out of curiosity, why was it deprecated? though now with the possibility of xsl transformation of maverick.xml via configTransform i guess i could still do it this way and let xsl take care of it. BTW, i think the idea of allowing xsl transform on the config file is a great idea. --jim - Original Message - From: Jeff Schnitzer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 21, 2002 8:26 AM Subject: RE: [Mav-user] problem with beta 2 Looks like Maverick doesn't think you have a controller defined. Just a guess, but are you still defining your controller with an attribute? This syntax, which only showed up in 2.0-b1, has been deprecated: command name=foo controller=org.foo.Bar You must specify a controller child element like this: command name=foo controller class=org.foo.Bar/ I forgot to mention that in the changelog :-( If that's not your problem, post your snippet of configuration file and I'll take a look. In any case, this error should have a better message. Sorry. Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: jim moore [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 21, 2002 9:14 AM To: [EMAIL PROTECTED] Subject: [Mav-user] problem with beta 2 So I just tried to switch to mav 2 beta 2. Didn't make any changes to my app or maverick.xml (I'm guessing that was my problem), just replaced maverick.jar. Anyway, as soon as I try anything, I get the ServletException below. Any ideas? I'm not sure where this null controller bit is coming from. My controller should be returning success as the view name. --jim javax.servlet.ServletException: Controller specified view null controller, but no view with that name is defined. at org.infohazard.maverick.flow.CommandBase.go(CommandBase.java:54) at org.infohazard.maverick.Dispatcher.service(Dispatcher.java:148) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica ti on FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt er Ch ain.java:193) at com.oreilly.servlet.MultipartFilter.doFilter(MultipartFilter.java:57) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica ti on FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt er Ch ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv e. ja va:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va :5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 72 ) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv e. ja va:190) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va :5 66) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja va :2 46) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va :5 64) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 72 ) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:234 3) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java :1 80 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va :5 66) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa lv e. java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va :5 64) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java :1 70 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va :5 64) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va :5 64) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 72 ) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. ja va :174) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va :5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 72 ) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j av a: 1012) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java: 11 07 ) at java.lang.Thread.run(Thread.java:536) ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
[Mav-user] global views
I've finally ported both maverick projects I'm working on to mav 2, and so far I think it is great. The one small detail I don't quite get is the reasoning behind the way the global views are set up. In mav 1, a global view was truly global--every command got it by default. Now in mav 2, I need to explicitly declare a reference to the global view in each command: command name=main controller=com.foo.foo view name=loginRequired ref=loginRequired/ view name=success path=/main.jsp / /command Why is this? I have 20 or so commands and 4 global views so far. That means I have to add 80 seemingly unncessary lines to my maverick.xml file. Is this to support shunting or something else that I haven't come across yet (so far I have just done the basic port from mav 1 to mav 2--haven't used any new functionality)? ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
Re: [Mav-user] global views
i just noticed i forgot to close the view tags in the commands. should be: command name=admin controller=com.foo.Admin !-- this will include all views grouped in protected -- view group=protected / view id=success path=/admin.jsp / /command command name=welcome controller=com.foo.Welcome view id=success ref=someotherview / /command - Original Message - From: jim moore [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 14, 2002 3:31 PM Subject: Re: [Mav-user] global views I think the param in the config file may be too black and white. I kind of like the direction Gerald is thinking. You could have something like: views group name=global view id=error path=/error.jsp/ /group group name=protected view id=loginInRequired path=/login.jsp/ !-- include someotherview in this group-- view id =someotherview ref=someotherview/ /group view id=someotherview path=/foo.jsp/ /view command name=admin controller=com.foo.Admin !-- this will include all views grouped in protected -- view group=protected view id=success path=/admin.jsp /command command name=welcome controller=com.foo.Welcome view id=success ref=someotherview /command Group global could be a standard group--anything in there gets automagically included in every command (though you are free not to use it if you want to keep the commands self contained). Views in group protected get included in a command if they specifically include that group (view group=protected) under the command. The example above also shows a way to allow multiple groups to share the same view by including it by ref. This was obviously put together pretty quickly, so it deserves some debate, but its just what I was thinking right now... --jim ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
[Mav-user] skinning and mav
(Jeff and Scott, there is more general mav question for you guys at the bottom, so please skim down or keep reading). Hi Dan, Maybe I still misunderstand, but it seems that if all you are providing is an engine (controllers and java classes) but no jsp's, xsl's, graphics, etc, then the war is overkill. Why not just jar your stuff and instruct you clients to make their own war with your jar in that web-apps lib directory. Or ship them a skeleton war, with only your jar, maverick.jar, etc. in the lib directory, and some instructions on how to fill it out. You could also ship a basic exampleapp.war that had your jar in it along with config files, templates, and graphics to illustrate how to set things up. It just seems that if the customer is defining maverick.xml, all templates, and the graphics, then you are not sending them a fully working webapp anyway, so there is no reason to expect there app to live separately from your war. --general question This does raise the question of how to set up easily configurable skins in maverick though. Currently I believe it would be difficult to have multiple skins that were configurable with a single param (i.e. skinskinA/skin or skinskinBskin). This is somewhat the same problem as i18n where you want to say, if the user's language is english, use these templates. if french, use these other templates. Skins are similar. If the user has selected skinA, use these templates, if they chose skinB, use these other templates. --jim - Original Message - From: Dan Finkelstein [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 12:26 AM Subject: Re: [Mav-user] 2.0 Installation Issues Jim, Let me explain my _exact_ requirements... I want to package up a war which can be distributed to a number of customers. Alongside each war, the customers will develop front end pages in order to control the page layout, the graphics, and the navigation between pages. Basically, a customer can create any look and feel he wants, simply calling into our underlying engine, which in this case based on Maverick. My idea is that the maverick.xml file, the velocity templates, any html files and gifs would be accessed from some specified directory and the war was made aware of that directory -- probably through a configuration parameter of some sort. (Jeff, I'm really not sure about your shunting idea -- I really don't understand shunting and will just wait for the docs to understand it.) Does that make sense? Or is there a simpler way to do this? Dan At 05:13 PM 2/6/02 -0500, jim moore wrote: As for point 3, if I understand you correctly, you want to put skin folders on the same level as web app folders. I personally think this is a bad idea. For one, the container will think of that new skin folder as a web-app. Better would be to have a skins folder inside the web app where you could drop additional skins. - Original Message - From: Dan Finkelstein [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 06, 2002 5:02 PM Subject: [Mav-user] 2.0 Installation Issues Hi -- I'm using 2.0 beta 1. When you're writing the doc for 2.0, the problems I've been having might be useful to document. 1. On loading, I get errors that log4j isn't properly configured. I added a log4j initialization call in Dispatcher.init() and that seemed to do the trick. (I grepped the sources but didn't see any explicit initialization occurring. I also added simple properties file that log4j needed.) 2. When running friendship-velocity, it gave me errors that were only resolved when I added in xalan.jar and xml-apis.jar. I had to download xalan from jakarta since it wasn't in the distribution. The readme note says to put them in the web server's lib directory. Could the friendship war have been built with these files inside, which is more typical? 3. I'm interested in distributing different skins which would run alongside the war file. Thus, I would like maverick.xml, the vm files, html files, gif files, etc to live in a separate directory. I think maverick is wired to expect them inside right now. What do you think of this idea? I'll probably have more questions later Thanks for any help, Dan ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
RE: [Mav-user] Flexible controller factories
I definitely would give this a thumbs up. The ability to plug custom controller functionality to handle multipart requests alone would make it worthwhile, plus I think the ability to put in global bean validation would be nice. For instance, on the project I am working on, I want to populate String properties with null across the board if they are empty strings. It would be nice to be able to centralize this functionality in a logical place. --jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Schnitzer Sent: Sunday, January 27, 2002 11:01 PM To: [EMAIL PROTECTED] Subject: [Mav-user] Flexible controller factories As I was putting in place the code for populating controllers with extra parameters specified in the configuration file, I realized that I'm not especially happy with the way controllers are created. I'm wondering if there would be value in allowing the ControllerFactory to be configured in much the same way that ViewFactory and TransformFactory objects are. The upside of doing this would be that the bean population (and validation, etc) code can be eliminated from the controller base classes and placed in the pluggable factory modules instead. Presumably the factories would be free to do all kinds of crazy things... including build Struts Actions, which would be pretty weird but I'm sure somebody will think it's cool :-) The downside of doing this would be a little extra complexity, and it would be necessary to eliminate the ability to specify the controller using an attribute on the command element. I'm starting to think that it would be a good idea to eliminate this anyways just to simplify validation and allow for more future flexibility. Right now you can specify a controller in two ways. command name=foo controller=org.foo.Bar view... /command command name=foo controller value=org.foo.Bar/ view... /command Both of these currently work. Of course, if you want to add extra initialization parameters to the controller, the second approach is necessary so that the controller element can have subnodes. I'm wondering if, even without the extra pluggable ControllerFactory feature, it wouldn't be better to just eliminate the first option. Thoughts? +1/-1/+0? Anyone like the idea of pluggable ControllerFactory implementations? Jeff Schnitzer [EMAIL PROTECTED] ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
