RE: [id] UUID sending more code and a question or two
That sounds like a PITA and I wonder if we are really thinking about this correctly. Interleaving JNI calls and comparing timestamps will be hard and ultimately inconclusive, IIUC. What exactly did you have in mind here? Why not run the native code, capture the output, and compare? Let me start from what brought me to testing the time against the C code. I was working on UUIDGenerator.java and once far enough along I felt I should compare the string output from a ms-guid to the values I generated. Reversing the time fields should have given me approximate values. It didn't. My next step was to add a test to tell me if the time I was generating was close to the time from someone else's uuid implementation. Going back to the ietf-draft was an easy choice since the appendix contains reference C code. After banging my head against the wall due to the time differences I'd get (which turned out to be an overflow in my C code.) The java time generation was fine, so I need to look elsewhere. I agree the JNI will be a PITA for me, especially since I'm re-learning C. I have a simple program working on Win2K and RH8. I'm not sure if the code would need to be recompiled for each target platform (at least making it an optional test might be good)? Perhaps running the test initially was sufficient? I'm not sure if Phil is minus on the JNI testing or for native code in the range test realizing what I'd proposed wouldn't work anyhow? Regardless, both points above are valid. The sample output (run2) below shows the interleaving calls not working which is logical without some delay in the calls, and as Noel suggests capture the output and compare would probably be the approach. I don't mind doing the jni (learn something new) but Phil are you minus on the jni range testing (past my own sanity tests here) or jni in the unit tests generally speaking? Sample output from my tests; right now I call an .exe using Runtime.exec... //Run 1 From C reference code 13294040293125 From java 13294040293125 From C reference code 132940402931562500 //Run 2 From C reference code 132940403477187500 From java 13294040347718 From C reference code 132940403477343750 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons] archives assistance
Quoting Jung, Eric (Contractor) [EMAIL PROTECTED]: Hi, This is a general question for all commons projects, since they share the same mailing list: 1. Why do they all share the same mailing list? I know you got your specific technical concerns addressed later in this thread, but I'd like to express a personal opinion that the fact that all the commons projects share dev and user mailing lists has been criticial to the overall success of Jakarta Commons. In particular, the cross-fertilization we see of developers picking up on needs in related subprojects would have *never* happened if all the dev lists were separate. 2. (More importantly) I can't find a means to search the archives by project. For example, searching on [Configuration] in mail subjects at http://marc.theaimsgroup.com results in (a) the brackets being removed from the search criteria and (b) all mailing lists (not just jakarta-commons) being searched -- there is no search by subject within mailing list x option. That sounds like an appropriate bug report to the mail archive server you're using :-). I get similar results from http://www.mail-archive.com; brackets are removed from search criteria, so searching on [Configuration] yields results with every email that contains the word configuration -- needless to say, this an overwhelming number and spans all projects in the Commons. Thank you for any suggestions. Eric H. Jung Russell/Mellon Analytical Services 1-617-382-1373 Everett, MA, USA Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] [PROPOSAL] IO Operations
I think that code like this would be a great addition to [io]. There has been a pattern in a number of commons utilities where code starts as static utilities and then becomes beans/classes underneath. One thing to consider at this point is whether to match the names of the Utils classes to the Operation classes. We have a CopyUtils, but maybe we should have a DeleteUtils, and LoadUtils as well. Actually, after thinking a little more, I wonder whether a new component for operation/functor based programming might be applicable. It could cover io, lang, convert, lots of things in a single API style. It could use [functor] for its model and for chaining etc., and call onto Utils classes to do the work. (I know there are some problems with this, partiularly with regards event handling). Well, its an idea... Stephen From: Alban Peignier [EMAIL PROTECTED] So, I'll give others a chance to chime in, but overall I think your ideas are good ones. Not as a replacement to the current static-based API, but as additions. I think the static-based API must be keep available. It might use internally the IO Operation API to perform the wanted task.-- Alban Peignier http://www.tryphon.org/~alban - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: new project proposal: Type Conversion Library
From: Ron Blaschke [EMAIL PROTECTED] Thanks a lot for the pointers to convert and how to get involved. I glanced over convert and it seems the right place to start. I am also willing to help push forward the [convert] project and am willing to apply patches etc. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: new project proposal: Type Conversion Library
I'm sorry I'm coming so late on this but I wanted to point out one interest into this library: Jelly is currently using BeanUtils with a few registred additional converters (for example Jelly-Swing with Dimensions, Rectangles, Colors, Fonts, ...). However the way these converters are registred is not easy to be meta-thought-about which makes the generation of the tag-documentation for such libraries currently impossible. If there was an abstract way of specifying type-converters, then jellydoc could probably use it at the instatiation of the tag-libraries. Thanks. paul On 22-Jan-04, at 10:20 Uhr, Stephen Colebourne wrote: From: Ron Blaschke [EMAIL PROTECTED] Thanks a lot for the pointers to convert and how to get involved. I glanced over convert and it seems the right place to start. I am also willing to help push forward the [convert] project and am willing to apply patches etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: new project proposal: Type Conversion Library
On 22 Jan 2004, at 10:21, Paul Libbrecht wrote: I'm sorry I'm coming so late on this but I wanted to point out one interest into this library: Jelly is currently using BeanUtils with a few registred additional converters (for example Jelly-Swing with Dimensions, Rectangles, Colors, Fonts, ...). However the way these converters are registred is not easy to be meta-thought-about which makes the generation of the tag-documentation for such libraries currently impossible. If there was an abstract way of specifying type-converters, then jellydoc could probably use it at the instatiation of the tag-libraries. hi paul (just to explain the beanutils sort-of-road-map) the route we've been traveling down (slowly) is beanification - replacing the old booch utilities with proper objects and backing the old interfaces with pseudo-singletons (per context classloader). using proper objects has many advantages including better isolation. we'll probably also move towards great use of strategy plugins. in terms of registration, one improvement which i've been planning to make (but have never really felt the itch badly enough) is factor out a register for the conversion types. if this happened then it'd be possible to create a register implementation which could be configured using meta-data and then plugged into the convertutilsbean instance to be used in the next part of the script. if this kind of functionality is needed by jelly, i'd probably be more motivated to implement it. of course, the problem for jelly with this is that it'd mean moving onto CVS HEAD for beanutils and without a realistic chance of a release for some time. (that's not to say that the conversion system in beanutils is any way sufficient for many purposes but then one of the long term aims for both project - for me at least - would be to be able to plug convert into a beanutils.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] release question
On 22 Jan 2004, at 06:07, Steve Cohen wrote: I see. After looking further into this matter, I begin to doubt the correctness of the http://jakarta.apache.org/commons/releases/prepare.html instructions. hi steve IIRC this point has been talked about at a little length in the past. i see to remember something about an ant issue (or at least a good point raised by some of the ant team) which is why the documented standard was adopted. i'd recommend checking the list archive and reading the whole thread. if circumstances have changed and the maven manifest is now more correct than the standard commons one, then probably the documentation should be changed. if (on the other hand) it turns out that maven is less correct then it's better to go with the agreed standard. They recommend this line in the manifest Implementation-Title: org.apache.commons.foo The existing maven system produces Package: org.apache.commons.net To me, Package is a more descriptive key than Implementation-Title for this value anyway. I will stick with what Maven does. commons usually uses the sun standards. Implementation-Title seems to be the sun-favoured name (http://java.sun.com/developer/Books/javaprogramming/JAR/basics/ manifest.html, for example). there doesn't really seem to be any reason why duplicate values should not occur in the manifest and so there really isn't any reason why you couldn't list both. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/introspection CompanyBean.java
rdonkin 2004/01/22 02:59:30 Added: betwixt/src/test/org/apache/commons/betwixt/introspection Tag: REFACTORING-BRANCH_2004-01-13 CompanyBean.java Log: Used in testing isHollow implementation Revision ChangesPath No revision No revision 1.1.2.1 +100 -0 jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/introspection/Attic/CompanyBean.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/introspection TestDeclarativeIntrospection.java
rdonkin 2004/01/22 03:00:03
Modified:betwixt/src/java/org/apache/commons/betwixt Tag:
REFACTORING-BRANCH_2004-01-13 BeanProperty.java
ElementDescriptor.java
betwixt/src/test/org/apache/commons/betwixt/introspection
Tag: REFACTORING-BRANCH_2004-01-13
TestDeclarativeIntrospection.java
Log:
Implementation and tests for isHollow
Revision ChangesPath
No revision
No revision
1.4.2.4 +57 -37
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/BeanProperty.java
Index: BeanProperty.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/BeanProperty.java,v
retrieving revision 1.4.2.3
retrieving revision 1.4.2.4
diff -u -r1.4.2.3 -r1.4.2.4
--- BeanProperty.java 19 Jan 2004 22:38:08 - 1.4.2.3
+++ BeanProperty.java 22 Jan 2004 11:00:03 - 1.4.2.4
@@ -87,9 +87,9 @@
public class BeanProperty {
/** The bean name for the property (not null) */
-private String propertyName;
+private final String propertyName;
/** The type of this property (not null) */
-private Class propertyType;
+private final Class propertyType;
/** The Expression used to read values of this property (possibly null) */
private Expression propertyExpression;
/** The Updater used to write values of this property (possibly null) */
@@ -189,12 +189,10 @@
* @return a correctly configured codeNodeDescriptor/code for the property
*/
public Descriptor createXMLDescriptor( IntrospectionConfiguration configuration
) {
-String name = getPropertyName();
-Class type = getPropertyType();
Log log = configuration.getIntrospectionLog();
if (log.isTraceEnabled()) {
log.trace(Creating descriptor for property: name=
-+ name + type= + type);
++ getPropertyName() + type= + getPropertyType());
}
NodeDescriptor descriptor = null;
@@ -204,7 +202,7 @@
if ( propertyExpression == null ) {
if (log.isTraceEnabled()) {
log.trace( No read method for property: name=
-+ name + type= + type);
++ getPropertyName() + type= + getPropertyType());
}
return null;
}
@@ -216,7 +214,7 @@
// choose response from property type
// XXX: ignore class property ??
-if ( Class.class.equals( type ) class.equals( name ) ) {
+if ( Class.class.equals( getPropertyType() ) class.equals(
getPropertyName() ) ) {
log.trace( Ignoring class property );
return null;
@@ -226,48 +224,39 @@
// on the type
//TODO replace with simple type support
-if ( XMLIntrospectorHelper.isPrimitiveType( type ) ) {
+if ( XMLIntrospectorHelper.isPrimitiveType( getPropertyType() ) ) {
descriptor =
createDescriptorForPrimitive(
configuration,
-name,
-log,
propertyExpression,
propertyUpdater);
-} else if ( XMLIntrospectorHelper.isLoopType( type ) ) {
+} else if ( XMLIntrospectorHelper.isLoopType( getPropertyType() ) ) {
if (log.isTraceEnabled()) {
-log.trace(Loop type: + name);
+log.trace(Loop type: + getPropertyName());
log.trace(Wrap in collections? +
configuration.isWrapCollectionsInElement());
}
-if ( Map.class.isAssignableFrom( type )) {
-descriptor = createDescriptorForMap(configuration,
propertyExpression);
+if ( Map.class.isAssignableFrom( getPropertyType() )) {
+descriptor = createDescriptorForMap( configuration,
propertyExpression );
} else {
-descriptor = createDescriptorForCollective( configuration,
propertyExpression);
+descriptor
+= createDescriptorForCollective( configuration,
propertyExpression );
}
} else {
if (log.isTraceEnabled()) {
-log.trace( Standard property: + name);
+log.trace( Standard property: + getPropertyName());
}
descriptor =
createDescriptorForStandard(
propertyExpression,
-propertyUpdater);
+propertyUpdater,
+
cvs commit: jakarta-commons-sandbox/attributes/compiler/src/java/org/apache/commons/attributes/compiler AttributeCompiler.java
leosutic2004/01/22 03:00:13
Modified:attributes/compiler/src/java/org/apache/commons/attributes/compiler
AttributeCompiler.java
Log:
Need to erase type information to keep the compiler from signalling an error
if the instanceof test can not possibly be true (for example, if _attr is a
java.lang.String).
Revision ChangesPath
1.9 +3 -2
jakarta-commons-sandbox/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java
Index: AttributeCompiler.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- AttributeCompiler.java15 Jan 2004 21:04:13 - 1.8
+++ AttributeCompiler.java22 Jan 2004 11:00:13 - 1.9
@@ -192,8 +192,9 @@
pw.println ({);
outputAttributeExpression (pw, expression, fileName,
tag.getLineNumber (), _attr);
-pw.println (if (_attr instanceof
org.apache.commons.attributes.Sealable) {);
-pw.println (((org.apache.commons.attributes.Sealable)
_attr).seal (););
+pw.println (Object _oattr = _attr; // Need to erase type
information);
+pw.println (if (_oattr instanceof
org.apache.commons.attributes.Sealable) {);
+pw.println (((org.apache.commons.attributes.Sealable)
_oattr).seal (););
pw.println (});
pw.println ( + collectionName + .add ( _attr ););
pw.println (});
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration project.xml
epugh 2004/01/22 03:41:23
Modified:configuration/src/test/org/apache/commons/configuration
TestDatabaseConfiguration.java
configuration project.xml
Log:
Fix tests so that testdb.script not regenerated constantly. fixs cvs wanting to
chck testdb.script in always.
Revision ChangesPath
1.3 +8 -2
jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java
Index: TestDatabaseConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestDatabaseConfiguration.java18 Jan 2004 16:18:56 - 1.2
+++ TestDatabaseConfiguration.java22 Jan 2004 11:41:23 - 1.3
@@ -55,6 +55,7 @@
package org.apache.commons.configuration;
import java.io.FileInputStream;
+import java.sql.SQLException;
import java.util.Iterator;
import javax.sql.DataSource;
@@ -82,11 +83,12 @@
// set up the datasource
BasicDataSource datasource = new BasicDataSource();
datasource.setDriverClassName(org.hsqldb.jdbcDriver);
-datasource.setUrl(jdbc:hsqldb:conf/testdb);
+datasource.setUrl(jdbc:hsqldb:target/test-classes/testdb);
datasource.setUsername(sa);
datasource.setPassword();
this.datasource = datasource;
+
// prepare the database
IDatabaseConnection connection = new
DatabaseConnection(datasource.getConnection());
@@ -100,6 +102,10 @@
{
connection.close();
}
+}
+
+protected void tearDown() throws SQLException{
+datasource.getConnection().close();
}
public void testAddPropertyDirectSingle()
1.8 +2 -1 jakarta-commons/configuration/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/configuration/project.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- project.xml 18 Jan 2004 16:19:04 - 1.7
+++ project.xml 22 Jan 2004 11:41:23 - 1.8
@@ -255,6 +255,7 @@
directoryconf/directory
includes
includetestClasspath.properties/include
+includetestdb.script/include
/includes
/resource
/resources
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] release question
Hmm, thanks, Robert. The Sun docs' example makes a better case for their way of doing it than the Apache example does. In particular Implementation-Version boils down to basically a build number which is not clearly shown in the Apache example. Of course we don't use these in Commons-net and it would be hard in an open source project where we lack a build machine, but at least you see the point of having the key there. You've caught me out. I really did try to do it the Apache way but I couldn't figure out how to make Maven give me an Implementation-Title. I created a manifest file, and put the Implementation-Title key-value pair there, then I defined the property maven.jar.manifest in project.properties to point at the location of this file. Maven docs indicated that this would cause Maven to merge the default manifest with this one, but when I was done, the manifest created was no different. It was then that I noticed the package key containing the same data and got lazy and decided that that was good enough. But if you or someone else can point me at the correct way of making Maven do the right thing, I'll be happy to follow. On Thursday 22 January 2004 4:58 am, robert burrell donkin wrote: On 22 Jan 2004, at 06:07, Steve Cohen wrote: I see. After looking further into this matter, I begin to doubt the correctness of the http://jakarta.apache.org/commons/releases/prepare.html instructions. hi steve IIRC this point has been talked about at a little length in the past. i see to remember something about an ant issue (or at least a good point raised by some of the ant team) which is why the documented standard was adopted. i'd recommend checking the list archive and reading the whole thread. if circumstances have changed and the maven manifest is now more correct than the standard commons one, then probably the documentation should be changed. if (on the other hand) it turns out that maven is less correct then it's better to go with the agreed standard. They recommend this line in the manifest Implementation-Title: org.apache.commons.foo The existing maven system produces Package: org.apache.commons.net To me, Package is a more descriptive key than Implementation-Title for this value anyway. I will stick with what Maven does. commons usually uses the sun standards. Implementation-Title seems to be the sun-favoured name (http://java.sun.com/developer/Books/javaprogramming/JAR/basics/ manifest.html, for example). there doesn't really seem to be any reason why duplicate values should not occur in the manifest and so there really isn't any reason why you couldn't list both. - robert - 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]
[Configuration] Throws ConfigurationException?
Hi all, A while ago we discussed 1.0 requirements that are left. And at this point, all have been finished except changing the api to throw a ConfigurationException. Now, I am thinking about how to implement this, and am not too keen on the idea of ConfigurationException being a non runtime explicit Exception. Primarily because I expect Configuration to always work, and so when I say: String s = Configuration.getString(my.string); I don't want to be surrounding it with try/catch for ConfigurationException. Indeed, I know what will happen, it will join the other methods that all throw Exception because if a ConfigurationException happens, there is no way for me to deal with it, except by crashing out the app! So, if we want a ConfigurationException, why don't we make it a extension of NestableRuntimeException (from commons-lang) and declare that we throw that? Or, if we aren't really sure what the Exception handling of the 1.0 version should be, then skip it (since what we have is good enuf), and move to a release of 1.0 so we can really think about what we want. I think just throwing a ConfigurationException on everything that is explicit is going to make the API harder to use and force bigger changes on everybodies code that wants to use it. Just one more thing.. Having said that about ConfigurationException, I was looking at the ConfigurationFactory and the getConfiguration() method throws an Exception. It really should throw a ConfigurationException that extends NestableException, and then maybe we have ConfigurationException extends NestableException and ConfigurationRuntimeException extends NestableRuntimeException? I really want to get to the 1.0 release of Configuration soon, especially now that we have a database backed exceptions plus all the goodies in ConfigurationFactory! Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JDK 1.1 question
On Thursday 22 January 2004 12:04 am, Steve Cohen wrote: I have built a candidate release for 1.1.1. Testing it is has proven a bit problematical. I found an old Blackdown port of java 1.1.8 for Linux. I don't believe Sun ever released a port of Java 1.1 for Linux. Whether this has ever been tested on RedHat 9.0 which it predates by three years, is dubious. In any case, the behavior I notice is that a sample test application attempts to connect() to an ftp server. The call to connect() takes about 15 minutes to return, and when it returns the connection is no longer valid. Obviously there is some sort of threading mismatch going on. So, the heck with that. Let me try to install jdk118 for Windows. Now the programs experience no delays but throw the following exception: java.lang.NoClassDefFoundError: org/apache/oro/text/regex/Perl5Compiler Now I've looked up and down and there's no way oro-2.0.7.jar is not on the classpath, and furthermore, it does contain org/apache/oro/text/regex/Perl5Compiler I believe I've seen cases where these errors are thrown if there's something in the jar class that cannot be resolved at runtime, even if the class itself can be so resolved. Daniel, do you remember anything about anything in 2.0.7 that is not 1.1 compatible? If that is so, it may be that all our 1.1 efforts for net are for naught. Duh, of course there is a dependency. I was too tired to see it last night. jakarta-oro-2.0.7's perl5 compiler uses HashMaps. Is there perhaps an earlier version of the the oro package we could roll back to for 1.1 compatibility that does not do this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] UUID sending more code and a question or two
--- Tim Reilly [EMAIL PROTECTED] wrote: snip/ I agree the JNI will be a PITA for me, especially since I'm re-learning C. I have a simple program working on Win2K and RH8. I'm not sure if the code would need to be recompiled for each target platform (at least making it an optional test might be good)? Perhaps running the test initially was sufficient? I'm not sure if Phil is minus on the JNI testing or for native code in the range test realizing what I'd proposed wouldn't work anyhow? Regardless, both points above are valid. The sample output (run2) below shows the interleaving calls not working which is logical without some delay in the calls, and as Noel suggests capture the output and compare would probably be the approach. I don't mind doing the jni (learn something new) but Phil are you minus on the jni range testing (past my own sanity tests here) or jni in the unit tests generally speaking? The problem is that I don't see what this is really buying us. If I understand the spec correctly, there are three things to test: format, clock agreement and correct handling of the situation where requests arrive at a rate faster than the clock resolution. The first two we should be able to test in Java. Exact behavior in the third case will likely be machine- and language-dependent, but again should be testable in Java. Sample output from my tests; right now I call an .exe using Runtime.exec... //Run 1 From C reference code 13294040293125 From java 13294040293125 From C reference code 132940402931562500 //Run 2 From C reference code 132940403477187500 From java 13294040347718 From C reference code 132940403477343750 What exactly is this showing that could not be tested in Java or by running a Java test using a pre-generated file of GUIDs made with the C code? What I meant in my earlier response was that the pain of maintaining and distributing C code with the unit tests did not seem justified by the value. Maybe I am missing something? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Configuration] Throws ConfigurationException?
Eric Pugh wrote: Hi all, A while ago we discussed 1.0 requirements that are left. And at this point, all have been finished except changing the api to throw a ConfigurationException. Now, I am thinking about how to implement this, and am not too keen on the idea of ConfigurationException being a non runtime explicit Exception. Primarily because I expect Configuration to always work, and so when I say: String s = Configuration.getString(my.string); I don't want to be surrounding it with try/catch for ConfigurationException. Indeed, I know what will happen, it will join the other methods that all throw Exception because if a ConfigurationException happens, there is no way for me to deal with it, except by crashing out the app! I agree we don't need a checked exception on the various getters. A runtime exception is fine, but i don't think it is required for 1.0. So, if we want a ConfigurationException, why don't we make it a extension of NestableRuntimeException (from commons-lang) and declare that we throw that? Or, if we aren't really sure what the Exception handling of the 1.0 version should be, then skip it (since what we have is good enuf), and move to a release of 1.0 so we can really think about what we want. The exception inconsistency that i noticed was related to the load/save methods in PropertiesConfiguration and DOM4JConfiguration. We should at least harmonize the exceptions there before the 1.0 release. I think just throwing a ConfigurationException on everything that is explicit is going to make the API harder to use and force bigger changes on everybodies code that wants to use it. Just one more thing.. Having said that about ConfigurationException, I was looking at the ConfigurationFactory and the getConfiguration() method throws an Exception. It really should throw a ConfigurationException that extends NestableException, That sounds good. and then maybe we have ConfigurationException extends NestableException and ConfigurationRuntimeException extends NestableRuntimeException? Or ConfigurationRuntimeException ? I really want to get to the 1.0 release of Configuration soon, especially now that we have a database backed exceptions plus all the goodies in ConfigurationFactory! Eric Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
Re: FeedParser in CVS with Atom Support (migrate to Jakarta Commons)
hi kevin On 22 Jan 2004, at 00:12, Kevin A. Burton wrote: I've sent a few emails off to [EMAIL PROTECTED] about this... had a bunch of +1s... You can view the history here: http://www.peerfear.org/rss/permalink/2004/01/11/ FeedParserAPIForJavaSourceAvailable (and here: http://marc.theaimsgroup.com/?l=jakarta-generalm=107390079319871w=2 http://marc.theaimsgroup.com/?l=jakarta-generalm=106924016425883w=2) I would like to migrate this code into jakarta-commons. I don't think it makes sense right now to make this a dedicated sub-project especially until the API is a bit more solid and we have 3 developers working on the code. That and the incubator seems like a lot of bureaucracy which I just don't want to deal with right now. AFAIK since it needs a donation document signing it should probably go through the incubator. in theory since you're already a jakarta committer (burton at apache.org, right?), it should just be a case of being nodded through (but also ensuring that all the legalities have been taken care of). IIRC avalon pushed through a similar incubation with the minimum of fuss very quickly recently but you'll probably need a member to champion it through for this to happen. if it doesn't come through the incubator then i'd say that someone from the pmc would need to nod the acceptance though. So if I get some +1s then I would like to merge this into the jakarta-commons CVS and start moving from there... The current codebase is here.. When we migrate over the package will change to org.apache.commons.feedparser http://www.peerfear.org/rss/permalink/2004/01/21/ FeedParserInCVSWithAtomSupport/ Thoughts? the code should start in the sandbox (just like everything else). this actually serves a useful purpose since it means that the code can be checked and brought in line with the rest of the commons more easily there. since you're already a apache committer, you can request sandbox karma (and have it granted) and start setting up the structure and the website straight away (though you probably shouldn't commit anything of the donated stuff until the all clear comes through.) BTW this should be taken as friendly advice (rather than definitive policy) since i'm no longer on the pmc and (happily) out of the jakarta policy loop now. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
A +1 for Craig's comments. If there are users who still have 1.2 requirements going forward, I say should say to them, you need to take it upon yourself to make the case for an upgrade, or work actively in this community to write components that work with 1.2. The most important phrase in Craig's email was: As such, I'm personally not interested in working on any revolutionary Struts or Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base platform as the minimum requirement. I am of the same persuasion, and if we create a community in which developers do not want to participate, we're working ourselves out of existence. And, I believe that is what we are seeing right now. Tim Craig R. McClanahan wrote: Quoting Gary Gregory [EMAIL PROTECTED]: (1) eventually is, sadly I think, a ways off in the future. See discussions on this list WRT J2ee containers, WebSphere, most common installed base of such containers, etc. personal-viewpoint author=craigmcc As a major proponent of long-term support for existing packages that want to do evolutionary development, this is an important issue. My own experience with Struts (which still supports Servlet 2.2 / JSP 1.1) says that this is important for existing users. And it will continue to be. *Nobody* in the real world can migrate to more current technologies as fast as the developers of those technologies would wish that they could. However, I get really impatient with this reality for *future* users. Many/most Jakarta projects tend to focus on the what is widely deployed now scenario -- but limiting ongoing development to this kind of platform is *very* bad for the Java platform in the long run. Personally, I will continue to invest effort in supporting existing users of the Apache/Jakarta packages I contribute to. But my primary focus for future efforts are going to be focused on leveraging the platforms that are more current in the mainstream ... with the expectation that folks on platforms that don't have this current support *will* be taken care of by the time that the revolutionary software is (if it ever is) ready for general release. As such, I'm personally not interested in working on any revolutionary Struts or Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base platform as the minimum requirement. That's not to say that the needs of exisiting pre-1.4-based users, or non-mainstream platforms that don't support SE/EE 1.4, aren't important --- nothing could be further from the truth! -- but limiting the ongoing development of Jakarta-based software (overall, the convention seems to be to support JDK 1.2 as the minimum platform with some packages supporting 1.1 compatible versions) is going to be very detrimental to the long-term success of the Java platform. The JDK 1.2 environment was *years* ago ... when a 256mHz PC was the tip of the state of the art. Would you willing to accept being required to work on such a hardware system today? It's time for us to recognize that there are *millions* of mainstream users, who *can* provide a 1.4 baseline runtime environmment -- and, as a whole, the Jakarta community is not paying enough attention to what kinds of capabilities can not be assumed. Lets *stop* limiting our revolutionary advances by an assumption that we have to be backwards compatible with what (in computer terms) is now considered the Iron Age of computing. /personal-viewpoint Craig McClanahan - 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: [commons] archives assistance
Howdy, 2. (More importantly) I can't find a means to search the archives by project. For example, searching on [Configuration] in mail subjects at http://marc.theaimsgroup.com results in (a) the brackets being removed from the search criteria and (b) all mailing lists (not just jakarta-commons) being searched -- there is no search by subject within mailing list x option. That sounds like an appropriate bug report to the mail archive server you're using :-). FYI, I've reported this multiple times to various admin addresses at AIMS without response. You can try again, maybe they'll like you better ;) I didn't see fit to complain further as they provide a nice service without cost. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Configuration] Throws ConfigurationException?
Eric Pugh wrote: Or, if we aren't really sure what the Exception handling of the 1.0 version should be, then skip it (since what we have is good enuf), and move to a release of 1.0 so we can really think about what we want. I think just throwing a ConfigurationException on everything that is explicit is going to make the API harder to use and force bigger changes on everybodies code that wants to use it. Just one more thing.. Having said that about ConfigurationException, I was looking at the ConfigurationFactory and the getConfiguration() method throws an Exception. It really should throw a ConfigurationException that extends NestableException, and then maybe we have ConfigurationException extends NestableException and ConfigurationRuntimeException extends estableRuntimeException? I'm not involved in [configuration], but from what I've read, data can be loaded from a number of sources: database, XML, properties files. RuntimeExceptions are typically used to indicate programmer error. There are plenty of exceptions that can occur under the hood that can naturally occur: SQLException, IOException, SAXException. I don't believe that wrapping these in a RuntimeException would be the best idea. One possible solution would be to create a ConfigurationRuntimeException and another class, FailFastConfiguration (or something similar) that wraps a configuration instance and wraps all checked exceptions as runtime ones. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-104) jelly-tags-define: testSuper failing
Message: A new issue has been created in JIRA. - View the issue: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=JELLY-104 Here is an overview of the issue: - Key: JELLY-104 Summary: jelly-tags-define: testSuper failing Type: Bug Status: Unassigned Priority: Minor Project: jelly Components: taglib.define Assignee: Reporter: Ralph Apel Created: Thu, 22 Jan 2004 5:36 AM Updated: Thu, 22 Jan 2004 5:36 AM Description: testSuper in jelly/tags/define/suite.jelly fails with NullPointerException in o.a.c.jelly.tags.define.SuperTag tag.getSuperScript() returns null Previously, and after o.a.c.jelly.tags.define.SuperTag.init, o.a.c.jelly.tags.define.ExtendTag.init is called a (suspicious ?) third time... - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Throws ConfigurationException?
I agree that it would be nice to have for 1.0, on the otherhand, don't want to rush it in! The subclassing was only done to continue to support pre 1.4 jdk's. We actually used a jdk1.4 specific method call at one point and broke some of our users code! Until we are ready to say 1.4 or better, I'd like to keep the older stuff. It does sound like the runtime is the way to go, versus checked. At this point then, does it really matter if we are throwing a ConfigurationRuntimeException on the getters? Since something farther down will? It does seem like ConfigurationSetupException or ConfigurationInitializationException should be thrown by the various places where we know that we can have an error, like when creating the Configuration from the ConfigurationFactory. and, if the DatabaseConfiguration thinks that it may throw SQLExceptions, then it could throw a runtime ConfigurationException.. Eric -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 2:45 PM To: Jakarta Commons Developers List Subject: RE: [Configuration] Throws ConfigurationException? Howdy, Long message, short comments: - A runtime exception, yes, not a checked exception. - Good to have for release 1.0: you wouldn't want to introduce this kind of behavior change from 1.0 to 1.1. - Why subclassing a commons-lang exception as opposed to the normal java RuntimeException? For pre-JDK 1.4 nesting compatability? Yoav Shapira Millennium ChemInformatics -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 6:51 AM To: Commons-Dev (E-mail) Subject: [Configuration] Throws ConfigurationException? Hi all, A while ago we discussed 1.0 requirements that are left. And at this point, all have been finished except changing the api to throw a ConfigurationException. Now, I am thinking about how to implement this, and am not too keen on the idea of ConfigurationException being a non runtime explicit Exception. Primarily because I expect Configuration to always work, and so when I say: String s = Configuration.getString(my.string); I don't want to be surrounding it with try/catch for ConfigurationException. Indeed, I know what will happen, it will join the other methods that all throw Exception because if a ConfigurationException happens, there is no way for me to deal with it, except by crashing out the app! So, if we want a ConfigurationException, why don't we make it a extension of NestableRuntimeException (from commons-lang) and declare that we throw that? Or, if we aren't really sure what the Exception handling of the 1.0 version should be, then skip it (since what we have is good enuf), and move to a release of 1.0 so we can really think about what we want. I think just throwing a ConfigurationException on everything that is explicit is going to make the API harder to use and force bigger changes on everybodies code that wants to use it. Just one more thing.. Having said that about ConfigurationException, I was looking at the ConfigurationFactory and the getConfiguration() method throws an Exception. It really should throw a ConfigurationException that extends NestableException, and then maybe we have ConfigurationException extends NestableException and ConfigurationRuntimeException extends NestableRuntimeException? I really want to get to the 1.0 release of Configuration soon, especially now that we have a database backed exceptions plus all the goodies in ConfigurationFactory! Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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]
DO NOT REPLY [Bug 25598] - MultipartStream\IE 5.5 error.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25598. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25598 MultipartStream\IE 5.5 error. --- Additional Comments From [EMAIL PROTECTED] 2004-01-22 15:51 --- I've created a test script in Jython (attached), which MultipartStream against the stored message bodies, and this can parse the ones from Mozilla as well as the ones from MSIE. This makes me suspect that it has to do with buffering, but setting different buffer sizes like 100, 50, 51, and 99 makes no difference; it still parses fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25598] - MultipartStream\IE 5.5 error.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25598. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25598 MultipartStream\IE 5.5 error. --- Additional Comments From [EMAIL PROTECTED] 2004-01-22 15:51 --- Created an attachment (id=10056) Jython test script - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allow anonymous issue creation in JIRA? (Re: [PROPOSAL] Jakarta Commons moving to JIRA)
-Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 03:10 AM To: 'Jakarta Commons Developers List' Cc: [EMAIL PROTECTED] Subject: RE: Allow anonymous issue creation in JIRA? (Re: [PROPOSAL] Jakarta Commons moving to JIRA) Would having anonymous issues increase the number of reports that don't have a contact email addresses or invalid email addresses. If so then if we had more questions on how to replicate the bug, and no email contact address then there isn't much that could be done. So you would prefer the option to show the Create Issue option, but require them to create an account? I prefer a account be required, but wouldn't insist on it. At the very minimum to make the contact email address manditory, if they don't have an account. Since Bugzilla verifies the email address when an account is created, we know it isn't bogus. If JIRA required an email address reporters could still put in a fake email address, or make a mistake in typing it in. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Oleg Kalnichevski wrote: The most important phrase in Craig's email was: As such, I'm personally not interested in working on any revolutionary Struts or Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base platform as the minimum requirement. Tim Craig, I wish I could agree with you, but unfortunately I have to say that this is a very PC- (or let me say big-time computing) centric point of view. There are still enough platforms that are in a widespread use where even Java 1.2 is not available, for instance MacOS 9 and, more importantly, all sorts of micro devices and embedded systems. True, it does not make sense to run Struts on a PDA or on a mobile phone. However, commons-codec being a low level library may come quite handy when developing applications for PDAs. Same story goes for HttpClient, which has recently become dependent on commons-codec. HttpClient in its turn is a dependency for XML-RPM. Making Codec require Java 1.4 (at this point) will cause a rippling effect on many other projects which are dependent (either directly or indirectly) on this library. IMHO, Commons-Codec as well as Commons HttpClient being low level libraries should target as wider user base as possible. Funny enough, we (HttpClient) still get requests for Java 1.1.8 compatibility once in a while. Some people went ever as far as creating a semi-official Java 1.1.8 fork to cater to their specific needs. The last thing I would like to see is a Java 1.2.x fork in addition to that. I am not saying Codec should not go forward and adopt new features in the Java platform that sense for it. However, we should consider not only the risk of working ourselves out of existence but also the risk of ending up working just for ourselves. At the very least I would like to see a more coherent policy towards Java platform compatibility across all Commons sub-project. I believe there must be a common baseline we should all agree upon and then stick to, whatever it is. Cheers, Oleg I still really get a strong sense that more Tag and Branching would be an empowerment here, HttpClient for j2sdk 1.4 and greater could take advantage of those features 1.4 provides (for instance nio) while a maintence branch on 1.4 could maintain release for those specific JVM's. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli/src/test/org/apache/commons/cli2/defaults/impl PreferencesImplTest.java PreferencesFactoryImpl.java PropertiesImplTest.java PropertiesBackedPreferences.java
jkeyes 2004/01/22 14:40:53 Modified:cli/src/test/org/apache/commons/cli2 Tag: RESEARCH_CLI_2_ROXSPRING ArgumentTestCase.java PrecedenceTest.java SwitchTest.java ArgumentTest.java DocumentationTest.java GroupTest.java HelpFormatterTest.java CommandLineTest.java GroupTestCase.java CommandTest.java ApplicationTest.java OptionTestCase.java ComparatorsTest.java ParentTestCase.java CommandLineDefaultsTest.java ParentTest.java PropertyOptionTest.java DefaultOptionTest.java cli/src/test/org/apache/commons/cli Tag: RESEARCH_CLI_2_ROXSPRING ParseTest.java PatternOptionBuilderTest.java BugsTest.java OptionGroupTest.java GnuParseTest.java ValuesTest.java OptionsTest.java ApplicationTest.java ValueTest.java ParseRequiredTest.java OptionBuilderTest.java BuildTest.java HelpFormatterExamples.java TestHelpFormatter.java cli/src/java/org/apache/commons/cli2 Tag: RESEARCH_CLI_2_ROXSPRING Group.java SourceDestArgument.java DefaultOptionBuilder.java Parent.java OptionImpl.java UnexpectedOptionException.java CommandLineParser.java Argument.java ArgumentImpl.java CommandLine.java UnexpectedValueException.java PropertyOption.java HelpSetting.java MissingValueException.java Comparators.java GroupImpl.java MissingOptionException.java ParentImpl.java ArgumentBuilder.java BurstException.java Switch.java GroupBuilder.java CommandBuilder.java HelpLine.java OptionException.java PatternBuilder.java SwitchBuilder.java StringComparator.java DefaultOption.java Option.java BadPropertyException.java Command.java HelpFormatter.java cli/src/java/org/apache/commons/cli2/validation Tag: RESEARCH_CLI_2_ROXSPRING Validator.java FileValidator.java InvalidArgumentException.java NumberValidator.java EnumValidator.java UrlValidator.java DateValidator.java ClassValidator.java cli/src/java/org/apache/commons/cli2/resources Tag: RESEARCH_CLI_2_ROXSPRING ResourceHelper.java cli/src/java/org/apache/commons/cli2/defaults Tag: RESEARCH_CLI_2_ROXSPRING DefaultsFactory.java Defaults.java cli/src/test/org/apache/commons/cli2/validation Tag: RESEARCH_CLI_2_ROXSPRING ClassValidatorTest.java DateValidatorTest.java NumberValidatorTest.java cli/src/test/org/apache/commons/cli2/bugs Tag: RESEARCH_CLI_2_ROXSPRING Bug15648Test.java Bug13886Test.java Bug15046Test.java Bug13935Test.java cli/src/java/org/apache/commons/cli Tag: RESEARCH_CLI_2_ROXSPRING TypeHandler.java HelpFormatter.java PosixParser.java OptionValidator.java Option.java OptionBuilder.java Parser.java PatternOptionBuilder.java GnuParser.java MissingArgumentException.java UnrecognizedOptionException.java AlreadySelectedException.java Options.java BasicParser.java CommandLineParser.java ParseException.java OptionGroup.java CommandLine.java MissingOptionException.java Util.java cli/src/java/org/apache/commons/cli2/defaults/impl Tag: RESEARCH_CLI_2_ROXSPRING PreferencesImpl.java PropertiesImpl.java cli/src/test/org/apache/commons/cli2/apps Tag: RESEARCH_CLI_2_ROXSPRING LsTest.java CpTest.java cli/src/test/org/apache/commons/cli2/defaults/impl Tag: RESEARCH_CLI_2_ROXSPRING PreferencesImplTest.java PreferencesFactoryImpl.java PropertiesImplTest.java PropertiesBackedPreferences.java Log: - all classes now have same license header Revision ChangesPath No revision No
Re: commons-logging log4j trace support
On 22 Jan 2004, at 22:14, Glen wrote: Great Good news, my change is already implemented as a new log4j bridge (the existing log4j bridge is final so I couldn't extend it). So that part is already done. In essence I copied the original bridge, factory and logger, into Log4jTraceFactory and Log4jTraceLogger. Then made minor changes for trace support. cool. if you do want to contribute new source files, please make sure that the ASF license is at the top of each. (it assigns the copyright to the ASF.) I don't like the names so if you have better ones please share. Does anyone else find that happens to them. I.e. taking longer to find a good name than it does to actually write the code? i'm not good at names but i usually find that it's easier to find out what the names should have been after the work has been completed and then refactor. I am more than happy to cut my teeth on test cases and documentation. I know what you mean about documentation and test cases taking as much if not more time. In this case much more since the code only took 30 minutes to write. As for the test cases. 95% of my test case can be accomplished by copying the log4j test case (with some mods of course) and adding some tests for the different things you can do to set the Trace level. Does this sound reasonable? the code plus test cases and documentation would be great. i have a noted tendency to sit on code patches which arrive without test cases and documentation (so i thought that it'd only be fair to warn you first...) As for docs I don't see anything in the commons-logging source I have. I have found this http://jakarta.apache.org/commons/logging/userguide.html but can't see where that is stored/ersioned. Is that where docs are needed? Perhaps a faq entry How can I get tae support for log4j? or when you say docs are you just referring to good javadocs? any and all documentation is valuable. i try to ensure that i create javadocs and documentation for features i add but it does take time. the userguide is currently just stored in cvs. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/resources dotbetwixt.dtd
rdonkin 2004/01/22 14:48:18 Modified:betwixt/src/resources Tag: REFACTORING-BRANCH_2004-01-13 dotbetwixt.dtd Log: Added addDefault attributes to DTD. Revision ChangesPath No revision No revision 1.7.2.1 +6 -2 jakarta-commons/betwixt/src/resources/dotbetwixt.dtd Index: dotbetwixt.dtd === RCS file: /home/cvs/jakarta-commons/betwixt/src/resources/dotbetwixt.dtd,v retrieving revision 1.7 retrieving revision 1.7.2.1 diff -u -r1.7 -r1.7.2.1 --- dotbetwixt.dtd24 Aug 2003 16:58:54 - 1.7 +++ dotbetwixt.dtd22 Jan 2004 22:48:18 - 1.7.2.1 @@ -1,7 +1,11 @@ ?xml version='1.0' encoding='UTF-8'? !-- $Id$ -- -!-- The DTD for .betwixt files -- +!-- + The DTD for .betwixt files + Suggested public ID: -//Jakarta Apache //DTD digester-rules XML V1.0//EN; + + -- !ELEMENT attribute EMPTY !ATTLIST attribute - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FeedParser in CVS with Atom Support (migrate to Jakarta Commons)
robert burrell donkin wrote: Kevin A. Burton wrote: I've sent a few emails off to [EMAIL PROTECTED] about this... had a bunch of +1s... You can view the history here: http://www.peerfear.org/rss/permalink/2004/01/11/FeedParserAPIForJavaSourceA vailable (and here: http://marc.theaimsgroup.com/?l=jakarta-generalm=107390079319871w=2 http://marc.theaimsgroup.com/?l=jakarta-generalm=106924016425883w=2) I would like to migrate this code into jakarta-commons. I don't think it makes sense right now to make this a dedicated sub-project especially until the API is a bit more solid and we have 3 developers working on the code. That and the incubator seems like a lot of bureaucracy which I just don't want to deal with right now. Kevin, are you the sole author of the code? Was it a work-for-hire? You wrote that Our lawyers have finally had a chance to review the Apache Public License and contributors documents (long story short they had no problems). Who is Our? I ask those questions in terms of the IP ownership. I see that all of the files are copyright to Sofari. I cannot locate a reference to Sofari as a corporate entity, but peerfear.org is registered to you. AFAIK since it needs a donation document signing it should probably go through the incubator. Grey area. If there is a company involved that isn't Kevin's sole proprietorship, it would be best to get a software grant. If the code is exclusively Kevin's with no company (what is Sofari?), then it should be covered by Kevin's CLA. IIRC avalon pushed through a similar incubation with the minimum of fuss very quickly recently but you'll probably need a member to champion it through for this to happen. Similar. External codebase. The author was not a committer. Provided a software grant (and was made a committer by the Avalon PMC during the interim), and had the code reviewed (preliminary review found GPL dependencies that were removed). Went into an existing codebase with ASF Committers waiting for it. All in all, seems a worthwhile and easy thing to do. The RSS code could be handy in several projects (possibly something in James, possibly in OpenIM, etc.). --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli LICENSE.txt
jkeyes 2004/01/22 15:08:16 Modified:cli Tag: RESEARCH_CLI_2_ROXSPRING LICENSE.txt Log: - use license header from website Revision ChangesPath No revision No revision 1.2.2.1 +11 -15jakarta-commons/cli/LICENSE.txt Index: LICENSE.txt === RCS file: /home/cvs/jakarta-commons/cli/LICENSE.txt,v retrieving revision 1.2 retrieving revision 1.2.2.1 diff -u -r1.2 -r1.2.2.1 --- LICENSE.txt 9 Oct 2003 20:57:47 - 1.2 +++ LICENSE.txt 22 Jan 2004 23:08:15 - 1.2.2.1 @@ -1,13 +1,9 @@ /* - * $Header$ - * $Revision$ - * $Date$ - * * - * + * * The Apache Software License, Version 1.1 * - * Copyright (c) 1999-2001 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without @@ -15,28 +11,28 @@ * are met: * * 1. Redistributions of source code must retain the above copyright - *notice, this list of conditions and the following disclaimer. + *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * - * 3. The end-user documentation included with the redistribution, if - *any, must include the following acknowledgement: - * This product includes software developed by the + * 3. The end-user documentation included with the redistribution, + *if any, must include the following acknowledgement: + * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgement may appear in the software itself, *if and wherever such third-party acknowledgements normally appear. * - * 4. The names The Jakarta Project, Commons, and Apache Software + * 4. The names Apache, The Jakarta Project, Commons, and Apache Software *Foundation must not be used to endorse or promote products derived - *from this software without prior written permission. For written + *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache - *nor may Apache appear in their names without prior written - *permission of the Apache Software Foundation. + *nor may Apache appear in their name without prior + *written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES @@ -57,4 +53,4 @@ * information on the Apache Software Foundation, please see * http://www.apache.org/. * - */ + */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jxpath vs. Jaxen?
From: __matthewHawthorne [EMAIL PROTECTED] I'm frequently finding myself needing a Bean query language, and then I remembered that Jxpath can do this easily. I have only used Jaxen, and found it easy to work with, however I had to add my own code for navigating JavaBeans. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new project proposal: XML based glue language/component assembly
From: Todd V. Jonker [EMAIL PROTECTED] You might want to check out HiveMind in the commons sandbox. Sadly, Hivemind is unavailable at present for legal reasons. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2/resources ResourceHelper.java
jkeyes 2004/01/22 16:17:35
Modified:cli/src/java/org/apache/commons/cli2/resources Tag:
RESEARCH_CLI_2_ROXSPRING ResourceHelper.java
Added: cli/src/java/org/apache/commons/cli2/validation Tag:
RESEARCH_CLI_2_ROXSPRING messages.properties
cli/src/java/org/apache/commons/cli2/defaults/impl Tag:
RESEARCH_CLI_2_ROXSPRING messages.properties
cli/src/java/org/apache/commons/cli2 Tag:
RESEARCH_CLI_2_ROXSPRING messages.properties
cli/src/java/org/apache/commons/cli2/defaults Tag:
RESEARCH_CLI_2_ROXSPRING messages.properties
Removed: cli/src/java/org/apache/commons/cli2/validation Tag:
RESEARCH_CLI_2_ROXSPRING MessagesBundle.properties
cli/src/java/org/apache/commons/cli2/defaults/impl Tag:
RESEARCH_CLI_2_ROXSPRING MessagesBundle.properties
cli/src/java/org/apache/commons/cli2 Tag:
RESEARCH_CLI_2_ROXSPRING MessagesBundle.properties
cli/src/java/org/apache/commons/cli2/defaults Tag:
RESEARCH_CLI_2_ROXSPRING MessagesBundle.properties
Log:
- changed name of resource bundles
Revision ChangesPath
No revision
No revision
1.1.2.1 +4 -0
jakarta-commons/cli/src/java/org/apache/commons/cli2/validation/Attic/messages.properties
No revision
No revision
1.1.2.1 +2 -0
jakarta-commons/cli/src/java/org/apache/commons/cli2/defaults/impl/Attic/messages.properties
No revision
No revision
1.1.2.1 +9 -0
jakarta-commons/cli/src/java/org/apache/commons/cli2/Attic/messages.properties
No revision
No revision
1.1.2.1 +4 -0
jakarta-commons/cli/src/java/org/apache/commons/cli2/defaults/Attic/messages.properties
No revision
No revision
1.1.2.3 +5 -2
jakarta-commons/cli/src/java/org/apache/commons/cli2/resources/Attic/ResourceHelper.java
Index: ResourceHelper.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/resources/Attic/ResourceHelper.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- ResourceHelper.java 22 Jan 2004 22:40:52 - 1.1.2.2
+++ ResourceHelper.java 23 Jan 2004 00:17:34 - 1.1.2.3
@@ -66,9 +66,12 @@
*/
public class ResourceHelper {
-/** resource bundle */
+// resource bundle
private ResourceBundle bundle;
+// default bundle name
+private static final String DEFAULT_BUNDLE = messages;
+
/** cache */
private static Map cache = new HashMap(13);
@@ -97,7 +100,7 @@
className.substring(0, className.lastIndexOf(.) + 1);
final String bundleName =
-packageName + MessagesBundle;
+packageName + messages;
// initialize the bundle
bundle = ResourceBundle.getBundle(bundleName);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2 UnexpectedValueException.java MissingOptionException.java
jkeyes 2004/01/22 16:18:07
Modified:cli/src/test/org/apache/commons/cli2 Tag:
RESEARCH_CLI_2_ROXSPRING PropertyOptionTest.java
cli/src/java/org/apache/commons/cli2/defaults/impl Tag:
RESEARCH_CLI_2_ROXSPRING PropertiesImpl.java
cli/src/java/org/apache/commons/cli2 Tag:
RESEARCH_CLI_2_ROXSPRING
UnexpectedValueException.java
MissingOptionException.java
Log:
- house keeping
Revision ChangesPath
No revision
No revision
1.1.2.3 +1 -4
jakarta-commons/cli/src/test/org/apache/commons/cli2/Attic/PropertyOptionTest.java
Index: PropertyOptionTest.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli2/Attic/PropertyOptionTest.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- PropertyOptionTest.java 22 Jan 2004 22:40:50 - 1.1.2.2
+++ PropertyOptionTest.java 23 Jan 2004 00:18:07 - 1.1.2.3
@@ -63,10 +63,7 @@
import java.util.Set;
/**
- * @author Rob
- *
- * To change the template for this generated type comment go to
- * WindowPreferencesJavaCode GenerationCode and Comments
+ * @author Rob Oxspring
*/
public class PropertyOptionTest extends OptionTestCase {
No revision
No revision
1.1.2.3 +2 -2
jakarta-commons/cli/src/java/org/apache/commons/cli2/defaults/impl/Attic/PropertiesImpl.java
Index: PropertiesImpl.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/defaults/impl/Attic/PropertiesImpl.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- PropertiesImpl.java 22 Jan 2004 22:40:53 - 1.1.2.2
+++ PropertiesImpl.java 23 Jan 2004 00:18:07 - 1.1.2.3
@@ -66,11 +66,11 @@
*/
public class PropertiesImpl implements Defaults {
-/** i18n */
+// resource bundle helper
private ResourceHelper resources =
ResourceHelper.getResourceHelper(PropertiesImpl.class);
-/** store */
+// default store
private Properties properties;
/**
No revision
No revision
1.1.2.3 +2 -5
jakarta-commons/cli/src/java/org/apache/commons/cli2/Attic/UnexpectedValueException.java
Index: UnexpectedValueException.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/Attic/UnexpectedValueException.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- UnexpectedValueException.java 22 Jan 2004 22:40:51 - 1.1.2.2
+++ UnexpectedValueException.java 23 Jan 2004 00:18:07 - 1.1.2.3
@@ -60,16 +60,13 @@
/**
* @author Rob Oxspring
- *
- * To change the template for this generated type comment go to
- * WindowPreferencesJavaCode GenerationCode and Comments
*/
public class UnexpectedValueException extends OptionException {
-/** argument value */
+// argument value
private final String argument;
-/** resource helper instance */
+// resource bundle helper
private static final ResourceHelper helper =
ResourceHelper.getResourceHelper(UnexpectedValueException.class);
1.1.2.3 +1 -1
jakarta-commons/cli/src/java/org/apache/commons/cli2/Attic/MissingOptionException.java
Index: MissingOptionException.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/Attic/MissingOptionException.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- MissingOptionException.java 22 Jan 2004 22:40:51 - 1.1.2.2
+++ MissingOptionException.java 23 Jan 2004 00:18:07 - 1.1.2.3
@@ -63,7 +63,7 @@
*/
public class MissingOptionException extends OptionException {
-/** resource helper instance */
+// resource bundle helper
private static final ResourceHelper helper =
ResourceHelper.getResourceHelper(MissingOptionException.class);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FeedParser in CVS with Atom Support (migrate to Jakarta Commons)
Noel J. Bergman wrote: Kevin, are you the sole author of the code? Was it a work-for-hire? You wrote that "Our lawyers have finally had a chance to review the Apache Public License and contributors documents (long story short they had no problems)." Who is "Our"? "Our" is a company called Sofari (working name) that I've recently founded. The legal documentation has been signed by our CEO and mailed to the ASF. IS there anything else I need to do? hope not... :) I ask those questions in terms of the IP ownership. I see that all of the files are copyright to Sofari. I cannot locate a reference to "Sofari" as a corporate entity, but peerfear.org is registered to you. The copyright attribution will change once the code migrates into Apache. The only reason the copyright remains is due to lazyness on my part. FAIK since it needs a donation document signing it should probably go through the incubator. Grey area. If there is a company involved that isn't Kevin's sole proprietorship, it would be best to get a software grant. If the code is exclusively Kevin's with no company (what is Sofari?), then it should be covered by Kevin's CLA. I've already signed and mailed the corporate contibutors agreement... done this before ;) Similar. External codebase. The author was not a committer. Provided a software grant (and was made a committer by the Avalon PMC during the interim), and had the code reviewed (preliminary review found GPL dependencies that were removed). Went into an existing codebase with ASF Committers waiting for it. All in all, seems a worthwhile and easy thing to do. The RSS code could be handy in several projects (possibly something in James, possibly in OpenIM, etc.). .. and a lot more... RSS/Atom and aggregation is going to explode in 2004. However you guys want to move forward is fine. The incubator does seem like a lot of politics though. Not something that I'm excited to do. One reason I wanted to move it into the commons is so that I could easily make rapid progress, attract other developers, and then come up with a more formal plan when we approach 1.0. Does it make more sense to assign the copyright over and then put it into the sandbox? I'm planning on posting this to a lot of RSS/Atom development communities so I need a place for us to focus our development efforts... Also... who can I talk to about a reset of my [EMAIL PROTECTED] passwd? I recently blew a disk with all my SSH RSA keys and I've since forgot the passwd to that account. Kevin -- Please reply using PGP: http://peerfear.org/pubkey.asc NewsMonster - http://www.newsmonster.org/ Dean in 2004! - http://blog.deanforamerica.com/ Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965 AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 4D20 40A0 C734 307E C7B4 DCAA 0303 3AC5 BD9D 7C4D IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FeedParser in CVS with Atom Support (migrate to Jakarta Commons)
robert burrell donkin wrote: AFAIK since it needs a donation document signing it should probably go through the incubator. in theory since you're already a jakarta committer (burton at apache.org, right?), it should just be a case of being nodded through (but also ensuring that all the legalities have been taken care of). IIRC avalon pushed through a similar incubation with the minimum of fuss very quickly recently but you'll probably need a member to champion it through for this to happen. if it doesn't come through the incubator then i'd say that someone from the pmc would need to nod the acceptance though. Looking at the incubator documentation scares me. Seems like a lot of work. I've been doing the OSS thing for a while now... not sure if I need that. I would rather just make forward progress in jakarta commons or the sandbox and then make it a subproject once we have more developers. Of course that might be unacceptable... I don't know. the code should start in the sandbox (just like everything else). this actually serves a useful purpose since it means that the code can be checked and brought in line with the rest of the commons more easily there. since you're already a apache committer, you can request sandbox karma (and have it granted) and start setting up the structure and the website straight away (though you probably shouldn't commit anything of the donated stuff until the all clear comes through.) I assume I will get an all clear from the ASF once they receive my legal paperwork... BTW this should be taken as friendly advice (rather than definitive policy) since i'm no longer on the pmc and (happily) out of the jakarta policy loop now. Yup... I guess I will have to ask the PMC. Kevin -- Please reply using PGP: http://peerfear.org/pubkey.asc NewsMonster - http://www.newsmonster.org/ Dean in 2004! - http://blog.deanforamerica.com/ Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965 AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 4D20 40A0 C734 307E C7B4 DCAA 0303 3AC5 BD9D 7C4D IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Release Commons Collections 3.0
Jakarta-Commons has voted in favour of releasing Commons-Collections-3.0 +1s Stephen Colebourne Matthew Hawthorne Gary Gregory Arun M Thomas Henri Yandell Yoav Shapira Phil Steitz Noel Bergman No other votes The release process will begin from 2004-01-23T22:00Z unless the PMC objects :-) Stephen Commons Collections is ready to be voted upon for release 3.0. This is a major release, full details below. Release notes: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/collections/RELEASE-NOTES. html?rev=1.7view=auto Distributions: http://jakarta.apache.org/~scolebourne/dist3/ Website: http://jakarta.apache.org/~scolebourne/collections3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Quoting Oleg Kalnichevski [EMAIL PROTECTED]: The most important phrase in Craig's email was: As such, I'm personally not interested in working on any revolutionary Struts or Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base platform as the minimum requirement. Tim Craig, I wish I could agree with you, Not really asking you to, since it was an expression of where *I* am going to focus my own personal efforts :-). but unfortunately I have to say that this is a very PC- (or let me say big-time computing) centric point of view. There are still enough platforms that are in a widespread use where even Java 1.2 is not available, for instance MacOS 9 and, more importantly, all sorts of micro devices and embedded systems. True, it does not make sense to run Struts on a PDA or on a mobile phone. However, commons-codec being a low level library may come quite handy when developing applications for PDAs. Same story goes for HttpClient, which has recently become dependent on commons-codec. HttpClient in its turn is a dependency for XML-RPM. Making Codec require Java 1.4 (at this point) will cause a rippling effect on many other projects which are dependent (either directly or indirectly) on this library. IMHO, Commons-Codec as well as Commons HttpClient being low level libraries should target as wider user base as possible. Funny enough, we (HttpClient) still get requests for Java 1.1.8 compatibility once in a while. Some people went ever as far as creating a semi-official Java 1.1.8 fork to cater to their specific needs. The last thing I would like to see is a Java 1.2.x fork in addition to that. I am not saying Codec should not go forward and adopt new features in the Java platform that sense for it. However, we should consider not only the risk of working ourselves out of existence but also the risk of ending up working just for ourselves. At the very least I would like to see a more coherent policy towards Java platform compatibility across all Commons sub-project. I believe there must be a common baseline we should all agree upon and then stick to, whatever it is. It's up to the developers of each package. The best way to influence that decision, for the packages that people care about, is to become a developer on them :-). Most appear to have settled on 1.2 as a base platform, with some still trying to make provisions for 1.1. But this decision has negative consquences for Jakarta packages as well -- it means we tend to spend a lot of time re-inventing what is already available, and we tend to not even think about designs that are enabled by the newer JDK's features, simply because it would take lots of work to write corresponding support for pre-1.4 users. Over the last couple of years, the net result of this (across all the Jakarta projects I'm familiar with) is a gradual reduction in innovation and new ideas. I'm not a codec contributor, so I don't have a voice in the decision for that package. I agree with your point that the use cases are likely to be different. Also, one could jusifiably accuse me of hijacking this message thread :-) But I really would like to see Jakarta projects do things for all the 1.4 users in the world, even if it means that code won't be helping users on pre-1.4 systems. And, since my primary interest is on server side apps (where 1.4 is more commonly available, or will be very soon), that's where I'm going to focus. Cheers, Oleg Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jxpath vs. Jaxen?
Matthew, If you have the need to traverse through Java Beans, Maps, Collections etc, JXPath does all of that out of the box. Plus it supports mixed models, e.g. a map containing DOM documents or a Java Bean that has a JDOM document as the value of some property. Jaxen is better suited for homogenous representations of XML, such as DOM, JDOM, DOM4J etc. It supports a much wider varieties of in-memory representations of XML than JXPath. You can make Jaxen traverse non-XML object graphs, but you would have to provide your own implementations of some Jaxen APIs. So, to summarize: with pure XML, try either Jaxen or JXPath (or for that matter Xalan if you are working with DOM). With non-XML objects in the picture - go with JXPath. - Dmitri - Original Message - From: __matthewHawthorne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 1:09 AM Subject: Jxpath vs. Jaxen? I'm frequently finding myself needing a Bean query language, and then I remembered that Jxpath can do this easily. But I've done a little reading about Jaxen and wondering if I should give this library it's day in court also. I'm continuing the investigation, but I'm interested in what others have to say. Anyone have feelings favoring one or the other? Apache vs. Codehaus -- who will triumph? It's a true battle of the titans. - 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]
cvs commit: jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/beans PropertyOwnerPointer.java NullPropertyPointer.java
dmitri 2004/01/22 17:10:21
Modified:jxpath/src/java/org/apache/commons/jxpath/ri/model/dynamic
DynamicPropertyIterator.java DynamicPointer.java
jxpath/src/java/org/apache/commons/jxpath/ri/axes
SimplePathInterpreter.java
jxpath/src/test/org/apache/commons/jxpath/ri/model/dynamic
DynamicPropertiesModelTest.java
jxpath/src/java/org/apache/commons/jxpath/ri/compiler
Path.java
jxpath/src/java/org/apache/commons/jxpath/ri/model/beans
PropertyOwnerPointer.java NullPropertyPointer.java
Log:
Fixed an issue with searches in graphs containing DynamicPropertyHandlers
Revision ChangesPath
1.4 +2 -9
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/dynamic/DynamicPropertyIterator.java
Index: DynamicPropertyIterator.java
===
RCS file:
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/dynamic/DynamicPropertyIterator.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- DynamicPropertyIterator.java 9 Oct 2003 21:31:41 - 1.3
+++ DynamicPropertyIterator.java 23 Jan 2004 01:10:20 - 1.4
@@ -58,9 +58,7 @@
import org.apache.commons.jxpath.ri.model.beans.PropertyOwnerPointer;
/**
- * codeDynamicPropertyIterator/code is different from a regular
- * codePropertyIterator/code in that given a property name it
- * will always find that property (albeit with a null value).
+ * @deprecated - no longer needed, as it is identical to PropertyIterator.
*
* @author a href=mailto:[EMAIL PROTECTED]Dmitri Plotnikov/a
* @version $Id$
@@ -75,9 +73,4 @@
{
super(pointer, name, reverse, startWith);
}
-
-protected void prepareForIndividualProperty(String name) {
-((DynamicPropertyPointer) getPropertyPointer()).setPropertyName(name);
-super.prepareForIndividualProperty(name);
- }
}
1.5 +11 -6
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/dynamic/DynamicPointer.java
Index: DynamicPointer.java
===
RCS file:
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/dynamic/DynamicPointer.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- DynamicPointer.java 9 Oct 2003 21:31:41 - 1.4
+++ DynamicPointer.java 23 Jan 2004 01:10:20 - 1.5
@@ -68,6 +68,7 @@
import org.apache.commons.jxpath.ri.QName;
import org.apache.commons.jxpath.ri.model.NodeIterator;
import org.apache.commons.jxpath.ri.model.NodePointer;
+import org.apache.commons.jxpath.ri.model.beans.PropertyIterator;
import org.apache.commons.jxpath.ri.model.beans.PropertyOwnerPointer;
import org.apache.commons.jxpath.ri.model.beans.PropertyPointer;
@@ -110,7 +111,7 @@
public NodeIterator createNodeIterator(
String property, boolean reverse, NodePointer startWith)
{
-return new DynamicPropertyIterator(this, property, reverse, startWith);
+return new PropertyIterator(this, property, reverse, startWith);
}
public NodeIterator attributeIterator(QName name) {
@@ -120,7 +121,11 @@
public QName getName() {
return name;
}
-
+
+public boolean isDynamicPropertyDeclarationSupported() {
+return true;
+}
+
/**
* Returns the DP object iself.
*/
1.13 +1 -1
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/SimplePathInterpreter.java
Index: SimplePathInterpreter.java
===
RCS file:
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/SimplePathInterpreter.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- SimplePathInterpreter.java9 Oct 2003 21:31:39 - 1.12
+++ SimplePathInterpreter.java23 Jan 2004 01:10:20 - 1.13
@@ -787,7 +787,7 @@
* a) represents the requested path and
* b) can be used for creation of missing nodes in the path.
*/
-private static NodePointer createNullPointer(
+public static NodePointer createNullPointer(
EvalContext context, NodePointer parent, Step[] steps,
int currentStep)
{
1.7 +49 -5
jakarta-commons/jxpath/src/test/org/apache/commons/jxpath/ri/model/dynamic/DynamicPropertiesModelTest.java
Index: DynamicPropertiesModelTest.java
===
RCS file:
DO NOT REPLY [Bug 25050] - getValue() and iterate() are not consistent
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25050. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25050 getValue() and iterate() are not consistent [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 01:16 --- The problem turned out to be much deeper than what the provide patch would indicate. The crux of the issue was that DynamicPropertyIterator was based on the assumption that a Map contains any property you would ask for. For example, if you have a JavaBean that has no property called foo, the path /foo throws an exception - there is no such property. However, if instead of a JavaBean we have a Map, the path /foo does not throw an exception. Rater, it returns null. The property exists, but has not been initialized. There is nothing wrong with this logic until you start searching with paths like //foo. As soon as the search encounters a Map, it stops because the Map contains a property called foo. That of course is unacceptable, so I had to make some changes here and there to differentiate between regular traversal like /foo and search like //foo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FeedParser in CVS with Atom Support (migrate to Jakarta Commons)
Kevin A. Burton wrote: Looking at the incubator documentation scares me. Seems like a lot of work. I've been doing the OSS thing for a while now... not sure if I need that. The docs are probably still out of date. We just moved code through the Incubator in something over a week, most of which was spent with people on holiday. In this sort of case, the Incubator is essentially the place for recording the IP checks, which we're already reviewing in this thread. As I understand it, you have submitted a software grant or corporate CLA, which we are waiting to be recorded. FYI, it appears that your own CLA may have been misplaced, since there isn't one on record. The license will be changed. So you need to do that and make sure that your paperwork has been recorded. --- Noel P.S. Just contact root@ about your password. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JDK 1.1 question
On Thursday 22 January 2004 6:02 am, Steve Cohen wrote: On Thursday 22 January 2004 12:04 am, Steve Cohen wrote: I have built a candidate release for 1.1.1. Testing it is has proven a bit problematical. I found an old Blackdown port of java 1.1.8 for Linux. I don't believe Sun ever released a port of Java 1.1 for Linux. Whether this has ever been tested on RedHat 9.0 which it predates by three years, is dubious. In any case, the behavior I notice is that a sample test application attempts to connect() to an ftp server. The call to connect() takes about 15 minutes to return, and when it returns the connection is no longer valid. Obviously there is some sort of threading mismatch going on. So, the heck with that. Let me try to install jdk118 for Windows. Now the programs experience no delays but throw the following exception: java.lang.NoClassDefFoundError: org/apache/oro/text/regex/Perl5Compiler Now I've looked up and down and there's no way oro-2.0.7.jar is not on the classpath, and furthermore, it does contain org/apache/oro/text/regex/Perl5Compiler I believe I've seen cases where these errors are thrown if there's something in the jar class that cannot be resolved at runtime, even if the class itself can be so resolved. Daniel, do you remember anything about anything in 2.0.7 that is not 1.1 compatible? If that is so, it may be that all our 1.1 efforts for net are for naught. Duh, of course there is a dependency. I was too tired to see it last night. jakarta-oro-2.0.7's perl5 compiler uses HashMaps. Is there perhaps an earlier version of the the oro package we could roll back to for 1.1 compatibility that does not do this? Looking into this further, it seems that jakarta-oro-2.0.1 is the most recent oro version that is executable under JDK-1.1 JVMs (actually, this applies only to Perl5Compiler, which seems to be the only jakarta-oro class that is both used by commons-net and incompatible with jdk 1.1). I haven't fully analyzed jakarta-oro, only those classes used by net. Question - primarily for Daniel: Do you think it makes sense to dial back to using jakarta-oro-2.0.1 in commons-net.1.1.1 to preserve JDK 1.1. compatibility? What features/bug fixes would be lost? Unless we either do this or rewrite, we don't have a version that works under 1.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] codec: Binary encoder/decoder addition
When I create release notes I usually look at cvs log for the entire project. Having a Bugzilla issue isn't a requirement for every change. It was refreshing to have a substantial patch for a change thanks to Alex. At least someone is paying attention to the software in the middle of all the noise. Tim Gary Gregory wrote: Could either of you create a Bugzilla ticket with this change so we do not loose sight of it for the next release (release notes, etc). Thanks. Gary -Original Message- From: Tim O'Brien [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 19:19 To: Jakarta Commons Developers List Subject: Re: [PATCH] codec: Binary encoder/decoder addition Alex, It has commit'd. your name and email have been added to project.xml - submit a patch to remove them if you object. Tim Alex Karasulu wrote: Hello, This little class efficiently (I hope) translates binary data into an String of ASCII '0' and '1' characters. It uses the codec encoder/decoder interfaces. Since it's a class addition I just jar'ed up the class and its test case. The jar is attached and contains: src/java/org/apache/commons/codec/binary/Binary.java src/test/org/apache/commons/codec/binary/BinaryTest.java Alex - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/fileupload/src/java/org/apache/commons/fileupload FileUploadBase.java
martinc 2004/01/22 22:51:10
Modified:fileupload/src/java/org/apache/commons/fileupload
FileUploadBase.java
Log:
Collapse some all but duplicated code.
Revision ChangesPath
1.5 +12 -30
jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/FileUploadBase.java
Index: FileUploadBase.java
===
RCS file:
/home/cvs/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/FileUploadBase.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- FileUploadBase.java 9 Oct 2003 21:15:47 - 1.4
+++ FileUploadBase.java 23 Jan 2004 06:51:10 - 1.5
@@ -384,36 +384,18 @@
}
else
{
-if (getFileName(headers) != null)
+FileItem item = createItem(headers,
+getFileName(headers) == null);
+OutputStream os = item.getOutputStream();
+try
{
-// A single file.
-FileItem item = createItem(headers, false);
-OutputStream os = item.getOutputStream();
-try
-{
-multi.readBodyData(os);
-}
-finally
-{
-os.close();
-}
-items.add(item);
+multi.readBodyData(os);
}
-else
+finally
{
-// A form field.
-FileItem item = createItem(headers, true);
-OutputStream os = item.getOutputStream();
-try
-{
-multi.readBodyData(os);
-}
-finally
-{
-os.close();
-}
-items.add(item);
+os.close();
}
+items.add(item);
}
}
else
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Quoting Gary Gregory [EMAIL PROTECTED]: (1) eventually is, sadly I think, a ways off in the future. See discussions on this list WRT J2ee containers, WebSphere, most common installed base of such containers, etc. personal-viewpoint author=craigmcc As a major proponent of long-term support for existing packages that want to do evolutionary development, this is an important issue. My own experience with Struts (which still supports Servlet 2.2 / JSP 1.1) says that this is important for existing users. And it will continue to be. *Nobody* in the real world can migrate to more current technologies as fast as the developers of those technologies would wish that they could. However, I get really impatient with this reality for *future* users. Many/most Jakarta projects tend to focus on the what is widely deployed now scenario -- but limiting ongoing development to this kind of platform is *very* bad for the Java platform in the long run. Personally, I will continue to invest effort in supporting existing users of the Apache/Jakarta packages I contribute to. But my primary focus for future efforts are going to be focused on leveraging the platforms that are more current in the mainstream ... with the expectation that folks on platforms that don't have this current support *will* be taken care of by the time that the revolutionary software is (if it ever is) ready for general release. As such, I'm personally not interested in working on any revolutionary Struts or Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base platform as the minimum requirement. That's not to say that the needs of exisiting pre-1.4-based users, or non-mainstream platforms that don't support SE/EE 1.4, aren't important --- nothing could be further from the truth! -- but limiting the ongoing development of Jakarta-based software (overall, the convention seems to be to support JDK 1.2 as the minimum platform with some packages supporting 1.1 compatible versions) is going to be very detrimental to the long-term success of the Java platform. The JDK 1.2 environment was *years* ago ... when a 256mHz PC was the tip of the state of the art. Would you willing to accept being required to work on such a hardware system today? It's time for us to recognize that there are *millions* of mainstream users, who *can* provide a 1.4 baseline runtime environmment -- and, as a whole, the Jakarta community is not paying enough attention to what kinds of capabilities can not be assumed. Lets *stop* limiting our revolutionary advances by an assumption that we have to be backwards compatible with what (in computer terms) is now considered the Iron Age of computing. /personal-viewpoint Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26328] - getScheme() and getPort() return wrong defaults for HttpsURL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26328. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26328 getScheme() and getPort() return wrong defaults for HttpsURL [EMAIL PROTECTED] changed: What|Removed |Added Summary|getScheme() wrongly returns |getScheme() and getPort() |http for HttpsURL |return wrong defaults for ||HttpsURL --- Additional Comments From [EMAIL PROTECTED] 2004-01-22 11:24 --- Same applies to the default port as well. Can be solved by either making the constants non-static or (better) overwrite the two methods in the subclass. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HttpClient 2.0 rc3: java.io.StreamCorruptedException
Hi All,
I 've tried to port my application from java.io.* to httpClient. Everything
works fine (http, https), except when my client need to communication via a
proxy (no need to set user or password) using SSL.
any idea?
PostMethod postMethod = new PostMethod(URI);
file = new File(fileName);
postMethod.setRequestBody(new FileInputStream(file));
postMethod.setRequestContentLength((int)file.length());
if (connection.isProxied() connection.isSecure()) {
postMethod = new ConnectMethod(postMethod);
}
postMethod.execute(httpState,connection);
if (postMethod.getStatusCode() == HttpStatus.SC_OK) {
ObjectInputStream fromETravel = new
ObjectInputStream(postMethod.getResponseBodyAsStream());
Thu Jan 22, 2004 14:26:49 CET [JCO.ServerThread-1] ERROR com.amadeus.sap
- [ETravelBridgeClient] InputStream does not contain a serialized object
java.io.StreamCorruptedException: InputStream does not contain a serialized
object
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:844)
at java.io.ObjectInputStream.init(ObjectInputStream.java:163)
at
com.amadeus.sap.client.rfc.AbstractETravelBridgeClient$ConnectionListener.sendRFC4Process(AbstractETravelBridgeClient.java:398)
at
com.amadeus.sap.client.rfc.AbstractETravelBridgeClient$ConnectionListener.handleRequest(AbstractETravelBridgeClient.java:347)
at com.sap.mw.jco.JCO$Server.dispatchRequest(Unknown Source)
at com.sap.mw.jco.rfc.MiddlewareRFC$Server.nativeListen(Native
Method)
at com.sap.mw.jco.rfc.MiddlewareRFC$Server.listen(Unknown Source)
at com.sap.mw.jco.JCO$Server.listen(Unknown Source)
at com.sap.mw.jco.JCO$Server.run(Unknown Source)
at java.lang.Thread.run(Thread.java:479)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10794] - User interaction for authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794 User interaction for authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2004-01-22 13:48 --- Changelog: * interactive authentication support * another bug fix in NTLMScheme class * InteractiveAuthenticationExample demo app At the moment I opted for keeping credentials callbacks in a static (global) class. I am not sure that this is the best solution, but at the moment I lack better ideas. Do authentication callbacks make sense on per HttpState basis? HttpClient? HttpClientParams? I felt that credentials callbacks should be global in order to avoid multiple authentication dialogs popping up in multithreaded applications, which, in my opinion, would be a bit confusing. At the same time I can well imagine that some may feel differently. Please let me know what you think. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient 2.0 rc3: java.io.StreamCorruptedException
Hi Joel,
Please take a look at the SSL guide for an example of how to use an SSL
proxy http://jakarta.apache.org/commons/httpclient/sslguide.html.
Generally speaking you do not want to manually create and use the
ConnectMethod. This is handled by HttpClient.execute().
Mike
On Jan 22, 2004, at 8:45 AM, Jean-Noel Heyraud wrote:
Hi All,
I 've tried to port my application from java.io.* to httpClient.
Everything
works fine (http, https), except when my client need to communication
via a
proxy (no need to set user or password) using SSL.
any idea?
PostMethod postMethod = new PostMethod(URI);
file = new File(fileName);
postMethod.setRequestBody(new FileInputStream(file));
postMethod.setRequestContentLength((int)file.length());
if (connection.isProxied() connection.isSecure()) {
postMethod = new ConnectMethod(postMethod);
}
postMethod.execute(httpState,connection);
if (postMethod.getStatusCode() == HttpStatus.SC_OK) {
ObjectInputStream fromETravel = new
ObjectInputStream(postMethod.getResponseBodyAsStream());
Thu Jan 22, 2004 14:26:49 CET [JCO.ServerThread-1] ERROR
com.amadeus.sap
- [ETravelBridgeClient] InputStream does not contain a serialized
object
java.io.StreamCorruptedException: InputStream does not contain a
serialized
object
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:844)
at java.io.ObjectInputStream.init(ObjectInputStream.java:163)
at
com.amadeus.sap.client.rfc.AbstractETravelBridgeClient$ConnectionListen
er.sendRFC4Process(AbstractETravelBridgeClient.java:398)
at
com.amadeus.sap.client.rfc.AbstractETravelBridgeClient$ConnectionListen
er.handleRequest(AbstractETravelBridgeClient.java:347)
at com.sap.mw.jco.JCO$Server.dispatchRequest(Unknown Source)
at com.sap.mw.jco.rfc.MiddlewareRFC$Server.nativeListen(Native
Method)
at com.sap.mw.jco.rfc.MiddlewareRFC$Server.listen(Unknown Source)
at com.sap.mw.jco.JCO$Server.listen(Unknown Source)
at com.sap.mw.jco.JCO$Server.run(Unknown Source)
at java.lang.Thread.run(Thread.java:479)
-
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]
Invalid Cookie Error
I am getting the following error from HttpClient and I would like to know if nayone can suggest a solution. violates RFC 2109: host minus domain may not contain any dots The machine name is machine.fl.mydomain.com and the domain attribute is .mydomain.com. Can I tell HttpClient to ignore this error since it is a trusted site? Thanks. -- Sincerely, David Webb Vice-President Hurff-Webb, Inc. http://www.hurff-webb.com (904) 861-2366 (904) 534-8294 Mobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10794] - User interaction for authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794 User interaction for authentication --- Additional Comments From [EMAIL PROTECTED] 2004-01-22 13:46 --- Created an attachment (id=10054) Patch (take 1) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Invalid Cookie Error
David, Use browser compatibility cookie policy instead of stricter RFC 2109. For more details see http://jakarta.apache.org/commons/httpclient/cookies.html Cheers, Oleg -Original Message- From: David Webb [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 16:10 To: [EMAIL PROTECTED] Subject: Invalid Cookie Error I am getting the following error from HttpClient and I would like to know if nayone can suggest a solution. violates RFC 2109: host minus domain may not contain any dots The machine name is machine.fl.mydomain.com and the domain attribute is .mydomain.com. Can I tell HttpClient to ignore this error since it is a trusted site? Thanks. -- Sincerely, David Webb Vice-President Hurff-Webb, Inc. http://www.hurff-webb.com (904) 861-2366 (904) 534-8294 Mobile - 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 2.0 rc3: java.io.StreamCorruptedException
Thanks for your hints, it has solved my issue!
Jean-Noel
From: Michael Becke [EMAIL PROTECTED] on 22/01/2004 10:09 EST
Please respond to Commons HttpClient Project
[EMAIL PROTECTED]
To:Commons HttpClient Project
[EMAIL PROTECTED]
ache.org
cc:
Subjec Re: HttpClient 2.0 rc3:
t: java.io.StreamCorruptedException
Hi Joel,
Please take a look at the SSL guide for an example of how to use an SSL
proxy http://jakarta.apache.org/commons/httpclient/sslguide.html.
Generally speaking you do not want to manually create and use the
ConnectMethod. This is handled by HttpClient.execute().
Mike
On Jan 22, 2004, at 8:45 AM, Jean-Noel Heyraud wrote:
Hi All,
I 've tried to port my application from java.io.* to httpClient.
Everything
works fine (http, https), except when my client need to communication
via a
proxy (no need to set user or password) using SSL.
any idea?
PostMethod postMethod = new PostMethod(URI);
file = new File(fileName);
postMethod.setRequestBody(new FileInputStream(file));
postMethod.setRequestContentLength((int)file.length());
if (connection.isProxied() connection.isSecure()) {
postMethod = new ConnectMethod(postMethod);
}
postMethod.execute(httpState,connection);
if (postMethod.getStatusCode() == HttpStatus.SC_OK) {
ObjectInputStream fromETravel = new
ObjectInputStream(postMethod.getResponseBodyAsStream());
Thu Jan 22, 2004 14:26:49 CET [JCO.ServerThread-1] ERROR
com.amadeus.sap
- [ETravelBridgeClient] InputStream does not contain a serialized
object
java.io.StreamCorruptedException: InputStream does not contain a
serialized
object
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:844)
at java.io.ObjectInputStream.init(ObjectInputStream.java:163)
at
com.amadeus.sap.client.rfc.AbstractETravelBridgeClient$ConnectionListen
er.sendRFC4Process(AbstractETravelBridgeClient.java:398)
at
com.amadeus.sap.client.rfc.AbstractETravelBridgeClient$ConnectionListen
er.handleRequest(AbstractETravelBridgeClient.java:347)
at com.sap.mw.jco.JCO$Server.dispatchRequest(Unknown Source)
at com.sap.mw.jco.rfc.MiddlewareRFC$Server.nativeListen(Native
Method)
at com.sap.mw.jco.rfc.MiddlewareRFC$Server.listen(Unknown Source)
at com.sap.mw.jco.JCO$Server.listen(Unknown Source)
at com.sap.mw.jco.JCO$Server.run(Unknown Source)
at java.lang.Thread.run(Thread.java:479)
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26139] - Memory leak in MultiThreadedHttpClient caused by bad .equals()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26139. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26139 Memory leak in MultiThreadedHttpClient caused by bad .equals() [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |2.1 Final Version|unspecified |Nightly Builds --- Additional Comments From [EMAIL PROTECTED] 2004-01-22 17:30 --- My plan, yet to be implemented, is to do 23 for all of the various HttpClient classes, and to add javadocs suggesting that all implementors do the same. How does that sound? Sounds good, and ambitious. A review of Object#equals method in all HttpClient classes is going to be quite an undertaking. Let me know if you need a helping hand. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26070] - [RFE] Allow streaming of POST methods via chunked transfer encoding.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26070. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26070 [RFE] Allow streaming of POST methods via chunked transfer encoding. --- Additional Comments From [EMAIL PROTECTED] 2004-01-22 18:13 --- Mohammad, My previous comment was not intended to discourage you and was not meant to make you think that your contribution was not welcome. Quite the opposite is the case. We certainly want to have the existing ChunkedOutputStream class replaced with your code. If just felt that output optimization based on the existing deficient architecture was not worth the trouble. This problem can be revisited in the course of 4.0 api overhaul. For the 3.0 release I would rather prefer a less intrusive approach. Would you be willing to continue working on this patch? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26070] - [RFE] Allow streaming of POST methods via chunked transfer encoding.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26070. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26070 [RFE] Allow streaming of POST methods via chunked transfer encoding. --- Additional Comments From [EMAIL PROTECTED] 2004-01-22 18:27 --- hah! It takes more than words to discourage me :- I've actually been a little busy, but kept this in the back of my mind. The way I see it, there are 3 ways to proceed (in order of difficulty, reverse order of goodness): 1) Forget about refactoring the BufferedChunkedOutputStream and make it an inner class of StreamedPostMethod. This is actually how I wrote the code originally. 2) Take out the first chunk optimization. This makes BufferedChunkedOutputStream a simple replacement for the current implementation. See below. 3) Teach HttpMethodBase how to deal with delaying headers. This may not be too bad in time for 2.1 (are we calling that 3.0 now?). I haven't had time to take a close look. The reason I'm hesitant about 2 is that HttpClient is used by a wide range of people, most of whom don't care about large POST payloads. The nice thing about first chunk optimization is that it transparently uses a more widely available Content-Length header. There are alot of broken proxies/load balancers/firewalls/webservers out there. It would be nice for a general purpose library to use the more common form when it can. There is nothing preventing people from doing their own buffering; this is just a convenience. FYI, for my purposes, option 2 will be just fine. Thanks Moh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26139] - Memory leak in MultiThreadedHttpClient caused by bad .equals()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26139. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26139 Memory leak in MultiThreadedHttpClient caused by bad .equals() --- Additional Comments From [EMAIL PROTECTED] 2004-01-22 18:49 --- Oleg, To clarify, my plan is to revisit the equals() methods for all HttpClient classes related to this problem (socket factories, etc.). It may eventually extend to all classes, but that is a separate problem I think. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[HttpClient][Bugzilla] should I stay or should I go?
Good day, Following the proposal to migrate Jakarta Commons projects from Bugzilla to JIRA posted to the Jakarta commons-dev list, we would like to have a few points clarified, before the final decision can be made whether Jakarta Commons HttpClient project stays with Bugzilla or migrates (kindly requests to be migrated) to JIRA. * Do you actually encourage migration from Bugzilla to JIRA? Will it make the task of to administering and supporting projects' infrastructure (issue tracking in the first place) easier for you? * Can existing bug reports (including closed ones) be migrated to JIRA in their entirety, if at all? What kind of data would not be migrated automatically? Would existing user accounts be preserved? * We (HttpClient committers contributors) have been in fact quite satisfied with Bugzilla so far. It has served us well. The only thing we have found constraining is the release management (versions, milestones, etc). As an alternative to migration to JIRA would it be possible to promote HttpClient from a component of Jakarta-commons project to a full fledged top level project with its own set of versions and milestones? HttpClient has already got its own mailing list. HttpClient related content constitutes 20-30% Bugzilla entries for the Jakarta-commons project. I believe this might be the best option, as least as far as we are concerned. I am just not sure it is technically feasible. Cheers, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
I'm a big loser
I can't seem to figure out how to POST data to a page that is protected (puts up a gray box where you enter the username/password). The code below is in a servlet running on www.mydomain.com and submitting to another page also on www.mydomain.com. // Create an instance of HttpClient. HttpClient client = new HttpClient(); // submit username/password for the gray box. client.getState().setAuthenticationPreemptive(true); UsernamePasswordCredentials creds = new UsernamePasswordCredentials(username, password); client.getState().setCredentials(null, request.getServerName(), creds); // Now submit this file to the piece that uploads batch files. String targetURL = http://; + request.getServerName() + /hrw/ecom/HRWImportCOPSData; MultipartPostMethod method = new MultipartPostMethod(targetURL); method.addParameter(import_file, completeEcomFile.getName(), completeEcomFile); method.setDoAuthentication(true); but when I try to submit the request using statusCode = client.executeMethod(method); I repeatedly get the exception Connection refused. I'm pretty sure the authentication is being required by the Apache webserver. Any help is greatly appreciated - Dave Care2 make the world greener! Eighty-six nations have signed the international Framework Convention on Tobacco Control. Help get the U.S. on the list! http://www.care2.com/go/z/10840/1060 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Change domains after faking a POST?
Its off topic for HttpClient (if I understand you need a transcoding proxy), but here are some resources that may help. You may want to have a look at some Jetspeed classes and related. Specifically the jetspeed.util.rewriter package, websurf portlet, and the webclipping portlet. http://jakarta.apache.org/jetspeed/api/org/apache/jetspeed/util/rewriter/pac kage-summary.html http://jakarta.apache.org/jetspeed/site/community-portlets.html http://jakarta.apache.org/jetspeed/site/portlet_config_WebClippingPortlet.ht ml Cocoon may also have some similar code as I recall. HTH -Original Message- From: D Alvarado [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 12:32 PM To: [EMAIL PROTECTED] Subject: Re: Re: Change domains after faking a POST? If you try and think this through carefully, you will see that the term in the context of will inadvertly lead to ambiguities. What about images referenced by the document, how must they be resolved? What about links to other domains, do we still have to use the proxy or can we just reach them directly? Please for the sake of the architecture of your application, do not blindly relay content to the client. The Http Proxy standard was specifically made for that purpose. So do not believe you can do better - you will fail terribly. Ok, well I definitely won't pursue the blind route. How would an HTTP Proxy behave in this situation? Surely it wouldn't parse out HTML. Also, not that this matters, but there will never be images or links, just the relative url in the action form tag. I have also considered the case that this situation has no elegant answer. If so, I will let this die. - Care2 make the world greener! Eighty-six nations have signed the international Framework Convention on Tobacco Control. Help get the U.S. on the list! http://www.care2.com/go/z/10840/1060 - 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]
