Thanks for the advise... At least in my situation it did not break anything we currently have. And we do not use Tomahawk file upload, so I guess I can go with this approach, even though it may not be an ideal solution. I'll let you know if I observe any other tomahawk features failing because of this configuration.
Samba On Mon, Mar 17, 2008 at 10:30 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Simon, you are exactly correct on your comments. Putting Trinidad's > filter first means that *IT* takes priority. This would certainly break > Tomahawk's file uploads and maybe even some other stuff. We definitely > need to handle this and although I wouldn't say it's necessary to unite > the file-upload "components" in all the various render kits, I'm > certainly advocating consistent Multi-part for handling so that all the > various components are compatible with one another. > > Samba: Looking at it again, the Trinidad filter does force execution of > the Configurators earlier in the request. So yes, switching the order > will work because the Trinidad bits will get processed first. > > Scott > > [EMAIL PROTECTED] wrote: > > I think it's important to track this, so I've created an issue > > (severity=minor): > > TOMAHAWK-1213 > > > > Putting trinidad's filter first has probably now broken any tomahawk > > fileUpload components. If you don't have any in your app then that is > > not a problem of course, but it is something that the library does need > > to fix sometime, whether via Scott's "configurator" module or otherwise. > > > > Samba: code duplication is a problem everyone is aware of. But tomahawk > > and trinidad cannot just be merged together. Some people want one but > > not the other. And anyway, people also combine these projects with other > > component libs created outside apache so all the apache libs need to be > > compatible with others as best they can. > > > > Regards, > > Simon > > > > Samba schrieb: > > > >> hey, > >> It worked now... > >> > >> The trick is to put Tomahawk Extension Filter below Trinidad Filter.... > >> > >> Thanks for your help.. > >> Samba > >> > >> P.S. > >> One more thing.. Is ther any planned date for the release of the > >> Unified approach for file uploading in myfaces ? > >> Actually I feel a lot duplicate effort is being put on JSF ... it > >> would be better if , at least in MyFaces Project .... combine all the > >> work into one stream so that these kind of incompatibilites won't > >> arise, and also the users need not have to bother about configuring > >> different and diverse pieces . > >> > >> > >> > >> > >> On Mon, Mar 17, 2008 at 12:02 PM, Samba <[EMAIL PROTECTED] > >> <mailto:[EMAIL PROTECTED]>> wrote: > >> > >> Hey.. Scott, I did not notice.. > >> > >> You are referring to *Tobago Filter ---* where as I am using > >> Tomahawk's extension Filter... > >> > >> I know that tobago filter is incompatible with trinidad.... > >> > >> But is Tomahawk Filter also incompatibile with Trinidad? > >> > >> thanks once again, > >> > >> On Sat, Mar 15, 2008 at 12:43 AM, Scott O'Bryan > >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > >> > >> Samba, this will not work because Tobago's filter is doing the > >> multi-part form handling. The two mechanisms are incompatible > >> with each other and will be until we have uniform handling of > >> the multi-part form request. (I know Matthias, yes the > >> configurator commons is comming... :) ). > >> > >> Adding the TrinidadFilter mapping BEFORE the Tobago Filter > >> will probably fix the issue. > >> > >> Scott > >> > >> > >> On Fri, Mar 14, 2008 at 5:37 AM, Samba <[EMAIL PROTECTED] > >> <mailto:[EMAIL PROTECTED]>> wrote: > >> > >> Hi! Mathew, > >> > >> Below I pasted the code of the method referrred; > >> > >> * > >> > >> public > >> > >> *String doUpload(){ *try* { > >> > >> BufferedInputStream bis = > >> > >> *new* > >> > BufferedInputStream(((UploadedFile)fileOne).getInputStream()); > >> > >> > >> OutputStream os = > >> > >> *null*; > >> > >> System. > >> > >> /out/.println("ContentType : > >> "+fileOne.getContentType()+"$$$$$$$$$$" + > >> fileOne.getFilename() ); > >> > >> os = > >> > >> *new* > >> FileOutputStream("C:\\temp\\"+fileOne.getFilename()); > >> *int* element; *while*((element=bis.read())!=-1){ > >> > >> os.write(element); > >> > >> } > >> > >> } > >> > >> *catch* (IOException e) { // *TODO* Auto-generated catch > >> block > >> > >> e.printStackTrace(); > >> > >> } > >> > >> *return* *null*; > >> > >> } > >> > >> > >> It is working fine even if I have Tomahawk jars and > >> commons-fileupload jar in my lib, but the moment I add the > >> ExtenstionFilter configuration entries in the web.xml, it > >> is failing by throwing a NPE.. > >> > >> hope this is not a bug and will get a solution to the > >> problem soon, > >> Samba > >> On Fri, Mar 14, 2008 at 4:35 PM, Matthias Wessendorf > >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > >> > >> Hi, > >> > >> .... > >> > > >> > > >> > root cause java.lang.NullPointerException > >> > > >> demo.backing.FileUploadTest.doUpload( > FileUploadTest.java:84) > >> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >> > > >> > > >> sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:39) > >> > > >> > > >> sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) > >> > >> *snip* > >> can you provide the code of the doUpload() ? > >> > >> > Is there any known issues of incompatibility of > >> Trinidad FileUploader with > >> > Tomahawk Extension Filtter? > >> > >> not that I know... > >> > >> -Matthias > >> > >> > > > > > > -- Regards... Samba.
