RE: [Mav-user] Re: Uploading Files using maverick
My original posting had non-working AbstractController - so here is the
working one.
I has one dependency to PersistenceFilter, but you can remove that.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Aapo
Laakkonen
Sent: Tuesday, February 11, 2003 7:55 AM
To: [EMAIL PROTECTED]; 'Peter Blakeley'
Subject: RE: [Mav-user] Re: Uploading Files using maverick
> Take a look at the upload process in the Punk Image
> Gallery sample app. It uses a modified version of
> Jason Hunter's (O'Reilly ) multipart-mime handling
> code.
Here is my version that Uses Jason Pell's library. Hunter's library has
that ugly licence.
Just extend PublicController, and override execute() method - everything
else is done for you (I use throwaway2 style controllers)!
If you want to access the uploaded files then just look at
multipartRequest field (or you can write public getter method if you
need that), eg.
MultipartContent multipartContent = null;
Iterator i = multipartRequest.iterator();
while (i.hasNext()) {
multipartContent = (MultipartContent) multipartRequest.next();
// Do something with uploaded file!
}
You can also modify the code if you for example like to store files in
disk, instead of memory (It might depend on how big files you are
transferring).
Regards
Aapo
AbstractController.java
Description: Binary data
RE: [Mav-user] Re: Uploading Files using maverick
> Take a look at the upload process in the Punk Image
> Gallery sample app. It uses a modified version of
> Jason Hunter's (O'Reilly ) multipart-mime handling
> code.
Here is my version that Uses Jason Pell's library. Hunter's library has
that ugly licence.
Just extend PublicController, and override execute() method - everything
else is done for you (I use throwaway2 style controllers)!
If you want to access the uploaded files then just look at
multipartRequest field (or you can write public getter method if you
need that), eg.
MultipartContent multipartContent = null;
Iterator i = multipartRequest.iterator();
while (i.hasNext()) {
multipartContent = (MultipartContent) multipartRequest.next();
// Do something with uploaded file!
}
You can also modify the code if you for example like to store files in
disk, instead of memory (It might depend on how big files you are
transferring).
Regards
Aapo
PublicController.java
Description: Binary data
AbstractPreprocessingController.java
Description: Binary data
Controller.java
Description: Binary data
AbstractController.java
Description: Binary data
MultipartContent.java
Description: Binary data
[Mav-user] Re: Uploading Files using maverick
Take a look at the upload process in the Punk Image Gallery sample app. It uses a modified version of Jason Hunter's (O'Reilly ) multipart-mime handling code. Note that PIG is a little dated both architecturally (it uses entity EJBs, yeeech) and versionwise - the Maverick config file format has changed a bit since then. Also, more recent versions of the O'Reilly code probably address the problem that required the modification. I exchanged a few messages with Jason Hunter about filename collision problems on servlet-interest and he said he would fix it. I haven't checked the code since then. Basically, handling file uploads with Maverick is no different than handling file uploads with servlets. Here's a link to the upload controller: http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/mav/pig/src/java/org/infohazard/pig/web/controller/UploadSubm it.java?rev=1.21&content-type=text/vnd.viewcvs-markup A full rewrite of PIG is in the works, but not likely to be done anytime soon. Jeff Schnitzer [EMAIL PROTECTED] > Can anyone point me to an example of uploading files using maverick > > cheers pb.. > -- > --- --- > Peter Blakeley - Attain Consultants - mobile: 0427-723-814 > > SECURITY > Virus-Protection, Firewalls, Auditing, Upgrades, Repairs, Troubleshooting > > NETWORK > Windows 2000, XP, Design, Setup, Management, Troubleshooting > > INTERNET > Web site design, Java programming, JEE2, JSP, Servlets, RMI, EJB, XML, > Workflow, Accounting, Web Services > > [ attainconsult.com ] > [ coolcat.com.au ] > > "Why open source? because I prefer to surf the wave to the beach rather > than swim all the way in." --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com [INVALID FOOTER]
Re: [Mav-user] server side redirects for commands
What a great idea. I suspect will increase speed! Peter At 23:39 10/02/2003 +0100, you wrote: >Hi all, > >Say, I have got a view like: > (I use >.m for Maverik commands). The current version of Maverik does a normal >redirect (response.sendRedirect). Imho it would be great if Maverik would >recognize that it is about to redirect to another Maverik command, and >instead of doing a real redirect, call that other command. And instead of >making a string copy of the objects in the context (stored like >getCtx().setParam(blah, obj)) to request parameters, make (or keep) the >objects available in their original form. > >I have got the case that I want to do a redirect to another command. For >this other command I have some object (which is not of type string!) >available in my first/ calling command. Right now the only way that I can >expose arbitrary objects from the first command to the second command is by >using session objects (or something similar), which is not *that* handy. > >Besides my own little problem (I already implemented the workaround), I >think doing a 'server side' redirect is better because it saves a >client-server roundtrip. Better because it it more efficient, and because it >does not expose variables meant for internal use (which is allways the case >if command1 calls command2?). > >Well, what do you all think? > >Cheers, > >Eelco Hillenius > > > >--- >This SF.NET email is sponsored by: >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! >http://www.vasoftware.com >[INVALID FOOTER] > > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com [INVALID FOOTER]
RE: [Mav-user] server side redirects for commands
The word you are looking for is a "forward", not a "redirect". Redirects are inherently client-side phenomenon; they are the result of an HTTP 302 response. Inside the server, you forward from one request to another. In fact, this is how Maverick executes JSPs (or other "documents") - using the forward mechanism. Try this: This "chains" the first command to the second. Any params are persisted across the invocation... and if you're careful about your controller base class, you can get access to the model as well. Jeff Schnitzer [EMAIL PROTECTED] > -Original Message- > From: Eelco Hillenius [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 10, 2003 2:40 PM > To: [EMAIL PROTECTED] > Subject: [Mav-user] server side redirects for commands > > Hi all, > > Say, I have got a view like: > (I > use > .m for Maverik commands). The current version of Maverik does a normal > redirect (response.sendRedirect). Imho it would be great if Maverik would > recognize that it is about to redirect to another Maverik command, and > instead of doing a real redirect, call that other command. And instead of > making a string copy of the objects in the context (stored like > getCtx().setParam(blah, obj)) to request parameters, make (or keep) the > objects available in their original form. > > I have got the case that I want to do a redirect to another command. For > this other command I have some object (which is not of type string!) > available in my first/ calling command. Right now the only way that I can > expose arbitrary objects from the first command to the second command is > by > using session objects (or something similar), which is not *that* handy. > > Besides my own little problem (I already implemented the workaround), I > think doing a 'server side' redirect is better because it saves a > client-server roundtrip. Better because it it more efficient, and because > it > does not expose variables meant for internal use (which is allways the > case > if command1 calls command2?). > > Well, what do you all think? > > Cheers, > > Eelco Hillenius > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > [INVALID FOOTER] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com [INVALID FOOTER]
[Mav-user] server side redirects for commands
Hi all, Say, I have got a view like: (I use .m for Maverik commands). The current version of Maverik does a normal redirect (response.sendRedirect). Imho it would be great if Maverik would recognize that it is about to redirect to another Maverik command, and instead of doing a real redirect, call that other command. And instead of making a string copy of the objects in the context (stored like getCtx().setParam(blah, obj)) to request parameters, make (or keep) the objects available in their original form. I have got the case that I want to do a redirect to another command. For this other command I have some object (which is not of type string!) available in my first/ calling command. Right now the only way that I can expose arbitrary objects from the first command to the second command is by using session objects (or something similar), which is not *that* handy. Besides my own little problem (I already implemented the workaround), I think doing a 'server side' redirect is better because it saves a client-server roundtrip. Better because it it more efficient, and because it does not expose variables meant for internal use (which is allways the case if command1 calls command2?). Well, what do you all think? Cheers, Eelco Hillenius --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com [INVALID FOOTER]
RE: [Mav-user] maverick and tomcat 4.1.18 combo, security issue
In Tomcat (and probably most other web containers) JSPs are handled by a servlet that is mapped to *.jsp. During shutdown, this JSPServlet is just one more servlet to shut down - although it should be one of the last ones. Here is a set of conditions that I suspect will reproduce this problem (keep in mind I'm just speculating): 1) A request is made to a maverick application. The hypothetical controller takes a long time to execute, doing lots of calculation or database queries or whatnot. 2) Sysadmin shuts down Tomcat. All servlets are unregistered (including the JSPServlet) but existing threads are allowed to complete. 3) The controller completes and then forwards to the JSP for rendering. 4) Since there is no JSPServlet, the JSP is handled as a simple static file. It may be that static content is also handled by a servlet - in which case the race condition is when the controller finishes its perform() after the JSPServlet is unregistered but before the static servlet is unregistered. I'm not familiar enough with Tomcat internals to know. I really don't think there is much you can do about the problem. It's a Tomcat issue, and there is nothing that Maverick can do to get around it. You will have the same problem with Struts or WebWork or even straight JSPs that perform forwards. If you're really worried about it, I suggest posting a bug report to the Tomcat lists. The "ideal" shutdown process would be: 1) Stop taking new requests 2) Wait for all processor threads to finish executing 3) Start destroying servlets I don't think this is what Tomcat currently does. Jeff Schnitzer [EMAIL PROTECTED] > -Original Message- > From: Taavi Tiirik [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 07, 2003 5:19 AM > To: [EMAIL PROTECTED] > Subject: [Mav-user] maverick and tomcat 4.1.18 combo, security issue > > Hello, > > I am running tomcat 4.1.18 on winxp system using "catalina run" > and I happened to stop tomcat (by pressing crtl-c) when there > was an request to maveric command that has not been finished > processing yet. As the result of this, tomcat serves source of my > decorator jsp page. > > I was not quite able to repeat this trick, but it seems like a > security issue. Well, it may be the case that stopping tomcat > using ctrl-c is the reason of this. What do you think? > > My maveric command is simple: > > > > > > > > > > with best wishes, > Taavi > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > [INVALID FOOTER] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com [INVALID FOOTER]
