Stream ended unexpectedly Problem using FileUpload
Hi, I have the following exception using the common FileUpload 1.0 library on WebSphere 4.0 and Apache 1.3 : Processing of multipart/form-data request failed. Stream ended unexpectedly This problem occurres when I try to upload a picture having size 1Ko. I have the problem only when the Apache HTTP Server is not on the same host than the application server. And I must have the Web server on a different host. Does anybody know this problem and have an idea about a possible solution ? Cédric Gérard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] parent and child tags
On 8-Mar-04, at 20:08 Uhr, Volkmann, Mark wrote: Parent tag objects cannot, in their doTag method, locate their child tag objects and invoke methods on them to pull data up. I'm really hoping, I'm wrong about this. Mark, I think Daryl is right about the children: your taglib (you may have missed that one can define a taglibrary that produces each of the tags, they can all be the same class). They can then quietly call their parent methods. I think this is actually the way it is done in the ant tag-library and probably even in ant itself. Think about the fileset children of a jar ant task and you can probably get this easily. In general, it's an important design-decision in jelly to let the children do the processing and not let the parents do it: that was I can use j:forEach inside ant:jar and many other mix-matching which makes the delicious character of jelly. Tags in a Jelly script that are not mapped to a class with define:jellybean .../ are ignored. This is wrong. They are passed through as static XML which is very very very different. It may not yet be the case, but it is planned that taglibs should not pass-through the XML content if they don't find their element. This way, only the elements of namespaces that are not registred will actually produce this effect (which is often caused by a typo in the element-name). paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Daily builds fails
What do you mean by in the archive? For ant compatibility, I am wondering if we should put the configuration files in /src/test/ directory? Would that solve the problem...? Basically, the Maven Ant plugin attempts to boil all the dynamism of Maven down to a simple build.xml, which works some of the time, but not all! Also, by putting stuff in /srt/test/conf it might make it easier for users to understand they are test resources? ERic -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 7:57 AM To: Jakarta Commons Users List; [EMAIL PROTECTED] Subject: RE: [Configuration] Daily builds fails Craig R. McClanahan wrote on Tuesday, March 09, 2004 2:20 AM: Quoting Eric Pugh [EMAIL PROTECTED]: Stephane, Thanks for the email with the error list.. I am not surprised the ant build fails.. [configuration] along with many other commons projects is primarily built using Maven. This means support for Ant builds sometimes is somewhat lacking.. I'll take a look at the errors and see what I can do. Most of the time, all that's needed is to use Maven to regenerate the build.xml file and check it in. The nightly build will pick that up. Does not work for configurations though. They have extensivly resources items that are not all properly transfered to the generated build.xml. Eric, is there a special reason, that all the test configuration files are also in the archive? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Daily builds fails
Eric Pugh wrote on Tuesday, March 09, 2004 11:35 AM: What do you mean by in the archive? Well, have a look into the current generated commons-configuration-1.0-dev-?.jar You'll see all the test configurtions in there and I wondered why. I have (at home so I cannot send a patch now) a modified project.xml that will not do so and all the junit tests were successful. OTOH I never worked with cactus and since there are some also in the repository I wonder, what I have to do to run them and if possibly they are the reason for bundling this test stuff. For ant compatibility, I am wondering if we should put the configuration files in /src/test/ directory? Would that solve the problem...? Basically, the Maven Ant plugin attempts to boil all the dynamism of Maven down to a simple build.xml, which works some of the time, but not all! Comparing the generated ant rules and the rules for the resources in Maven, you'll notice a difference. Not all files will be copied using the generated ant file. Also, by putting stuff in /srt/test/conf it might make it easier for users to understand they are test resources? Not sure about the recommended project structure of Maven here. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Stream ended unexpectedly Problem using FileUpload
I had the same problem, for webphere 4.1 and apache 1.3.21 in sun solaris environment. This problem is due to plugin redirector. It seems there is patch which is available to solve this problem. i will try to get the site name where we downloaded the patch Thanks Chad -Original Message- From: Gerard Cedric [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 03:33 AM To: '[EMAIL PROTECTED]' Subject: Stream ended unexpectedly Problem using FileUpload Hi, I have the following exception using the common FileUpload 1.0 library on WebSphere 4.0 and Apache 1.3 : Processing of multipart/form-data request failed. Stream ended unexpectedly This problem occurres when I try to upload a picture having size 1Ko. I have the problem only when the Apache HTTP Server is not on the same host than the application server. And I must have the Web server on a different host. Does anybody know this problem and have an idea about a possible solution ? Cédric Gérard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jxpath] problem with Container interface
I'll look into this. I haven't tried putting a collection in a container -
it's quite possible there is a bug there.
Out of curiosity - what purpose does the container serve in your situation?
Why don't you use the contents of the container as the context object?
Thanks,
- Dmitri
- Original Message -
From: Uwe Janner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 08, 2004 1:38 PM
Subject: Re: [jxpath] problem with Container interface
to describe my problem more precisely, i also append this test;
i dont understand why it evaluates correcty with index [1], but not with
index [2].
both ctx.getValue(/a) and ctx.getValue(/b) correctly evaluate to the
whole arraylist [x,y];
thank you in advance for any help, uwe!
public class XpathUtilTest extends TestCase {
public void testEval(){
JXPathContext ctx = JXPathContext.newContext(new MyObject());
// this test succeeds:
assertEquals(x, ctx.getValue(/a[1]));
// this test fails because of:
// JXPathException: No value for xpath: /a[2]
assertEquals(y, ctx.getValue(/a[2]));
}
public class MyObject implements Container{
Map map;
public MyObject(){
map = new HashMap();
map.put( a, new ListEntry()); map.put( b, new
ListEntry());
}
public Object getValue() {
return map;
}
public void setValue(Object arg0) {}
}
public class ListEntry implements Container{
private List list;
public ListEntry(){
this.list = new ArrayList();
list.add(x); list.add(y);
}
public Object getValue() {
return list;
}
public void setValue(Object arg0) {}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpClient] Replacing the JDK's HttpClient?
Petite, Currently HttpClient provides a partial implementation of HttpURLConnection. The problem is (at least in my opinion) that HttpURLConnection is so badly broken that this hardly makes a lot of sense to simulate its behaviour. So far nobody has felt compelled to step in and provide a plug-in HttpURLConnection replacement based on HttpClient code Cheers, Oleg On Tue, 2004-03-09 at 15:25, petite_abeille wrote: Hello, Is there a way to replace the JDK's HttpClient with the Common HttpClient? For example, Innovation's HTTPClient [1] can be setup through the java.protocol.handler.pkgs system property. Would it be possible to achieve the same effect with the Common HttpClient? TIA. Cheers, PA. [1] http://www.innovation.ch/java/HTTPClient/getting_started.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DBCP Connection.getDelegate () class cast problem
Hi. After updating tomcat to 5.0, part of our system stopped working. Looked at the source code and found out the line ((PoolableConnection)conn_l).getDelegate() caused java.lang.ClassCastException exception. But the same code works fine for Tomcat 4.1. Any idea what went wrong? Thanks, Lily
Re: [HttpClient] Replacing the JDK's HttpClient?
Hi Oleg, On Mar 09, 2004, at 19:34, Oleg Kalnichevski wrote: Currently HttpClient provides a partial implementation of HttpURLConnection. I saw that. But it seems to be more like a, er, esquisse, than a full blown implementation of a protocol handler [1]. The problem is (at least in my opinion) that HttpURLConnection is so badly broken that this hardly makes a lot of sense to simulate its behaviour. Right... I'm not interested in replicating HttpURLConnection implementation quirks, but rather in a consistent API. So far nobody has felt compelled to step in and provide a plug-in HttpURLConnection replacement based on HttpClient code Bummer :/ Providing a more solid, but API compatible, implementation build on top of Common's HttpClient would be a killer in my opinion :) Oh, well... Cheers, PA. [1] http://java.sun.com/developer/onlineTraining/protocolhandlers/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP Connection.getDelegate () class cast problem
A little more info is needed: Version of DBCP and exact tomcat versions? Do you have a DBCP jar in the WEB-INF/lib directory of your application or only in tomcat/common/lib? Do you create your own pool or use JNDI? (context configuration?) -- Dirk Dong, Lily/Sloan-Kettering Institute wrote: Hi. After updating tomcat to 5.0, part of our system stopped working. Looked at the source code and found out the line ((PoolableConnection)conn_l).getDelegate() caused java.lang.ClassCastException exception. But the same code works fine for Tomcat 4.1. Any idea what went wrong? Thanks, Lily - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BeanUtils SqlConversion
Why not? Can't you just re-register the standard converters with the versions that return default values instead of errors? I'm not familiar with how you can re-register the standard converter with another version. The BeanUtils.populate() method encapsulates the eventual call to the SqlDateConverter class which throws the ConversionException. I don't see any way of specifying in the BeanUtils class how to use a modified SqlDateConverter with a default value enabled. If you know how you can enable this please provide a code snippet. Personally, I would not choose this strategy, because the failed conversions are just hiding a problem that is going to bite you later. Instead, I would set up a validation strategy to check the incoming values to make sure they are syntactically correct and will not cause conversion errors. This is exactly why Struts encourages you to use Strings for form bean properties, for example. I practice this same procedure as well of using Strings for form bean properties. However, in my case it's not performing the conversion from the form bean to some transfer object. Rather, I'm converting data from the transfer object to the form bean. This is causing the exception. A validation strategy works in cases where requirements are not fulfilled. However, you can still have date fields that are nullable. In this case you will still encounter the ConversionException. Robert's solution of subclassing the BeanUtils class will work. I just am leery of doing this because it seems as if the problem should really be addressed in the BeanUtils class. Unless a better solution is proposed, I'll probably subclass it until a fix to the ConversionException is implemented. Does anyone have any thoughts out there about this? Thanks, Amir
Re: [vfs] problem: nightly build distributions are empty
Quoting Jacob Kjome [EMAIL PROTECTED]: Recent .tar.gz distributions of commons-vfs at http://cvs.apache.org/builds/jakarta-commons/nightly/ are completely empty. The site is down right now, so I can't quite verify when the last good one was, but from memory, I think it was 20040301. All since then are empty archives. Might want to get that fixed. That is because running ant clean dist to produce the nightly bundles is getting a compile error: compile: [mkdir] Created dir: /home/craigmcc/Jakarta/jakarta-commons-sandbox/vfs/target/classes [javac] Compiling 102 source files to /home/craigmcc/Jakarta/jakarta-commons-sandbox/vfs/target/classes [javac] /home/craigmcc/Jakarta/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/webdav/WebDavFileSystem.java:80: cannot resolve symbol [javac] symbol : constructor WebdavResource (org.apache.commons.httpclient.HttpURL,int,int) [javac] location: class org.apache.webdav.lib.WebdavResource [javac] final WebdavResource resource = new WebdavResource( url, WebdavResource.NOACTION, 1 ); [javac] ^ [javac] /home/craigmcc/Jakarta/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/webdav/WebdavFileObject.java:67: cannot resolve symbol [javac] symbol : method setHttpURL (org.apache.commons.httpclient.HttpURL,int,int) [javac] location: class org.apache.webdav.lib.WebdavResource [javac] resource.setHttpURL( url, WebdavResource.NOACTION, 1 ); [javac] ^ [javac] 2 errors BUILD FAILED I'm cc'ing COMMONS-DEV in case the [vfs] developers are only watching there. Jake Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] problem: nightly build distributions are empty
Craig, Try using the version of webdav from http://www.ibiblio.org/maven/slide/jars/webdavlib-1.0.16.jar or applying my patch sent to the -dev list on 6th March. Jacob, Hopefully one of the VFS developers will apply my patch soon ;) -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
