Re: [all] Instead of source and binary - one distribution
Well a lot of times a commons component is a transitive dependency for a project. I know I've never looked at the beanutils source but I have to have it for my struts projects. Also, jars in the public maven repositories should probably stay slim. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ Tim O'Brien wrote: We make releases both source and binary, but why not just start cutting one release? I can understand why a product like HTTPD would be distributed without source, but the commons community consists of developers. Can anyone think of any good reason to preserve the current release structure. My apologizes in advance if this starts an endless flame war. I have a knack for that. - Tim O'Brien [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]
Re: [codec] base64Codec.decode and DecoderException
Hi,
I'd guess not. In Codec 1.1 the (checked) DecoderException was thrown.
XML-RPC 2.0 alpha (HEAD) depends on version 1.1 of codec with no known
issues.
I'd be surprised if we updated to 1.2 this summer. Our stable branch
(1.2) has no current or planned dependency on codec because we had our
own Base64 implementation. I probably already mentioned that we only
need Base64, so we might end up deciding against having a codec
dependency. Not long ago the Maven team encountered the same situation
and they decided to copy the Base64 source rather than to depend on
codec. I'd prefer not to follow suit for a lot of the same reasons we
decided to create a shared Base64 implementation in the first place
(early 2002 in the sandbox). For various reasons xmlrpc doesn't move
very quickly, especially by jakarta standards. So for the time being,
we'll probably stick with codec 1.1.
Cheers,
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net/
Gary Gregory wrote:
Has this been resolved within "build_ws-xmlrpc_ws-xmlrpc"?
I do not see the compile error mentioned in the message below in the
page:
http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/gump_work/build_w
s-
xmlrpc_ws-xmlrpc.html
Thank you,
Gary
-Original Message-
From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 09:44
To: Jakarta Commons Developers List
Subject: [codec] base64Codec.decode and DecoderException
Folks,
An interested compatibility issue has surfaced from this:
http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/gump_work/build_w
s-
xmlrpc_ws-xmlrpc.html
/usr/local/gump/public/workspace/ws-
xmlrpc/src/java/org/apache/xmlrpc/Defaul
tTypeFactory.java:133: exception
org.apache.commons.codec.DecoderException
is never thrown in body of corresponding try statement
[javac] catch (DecoderException e) {
[javac] ^
This is the code:
public Object createBase64(String cdata)
{
try {
return base64Codec.decode(cdata.getBytes());
}
catch (DecoderException e) {
//TODO: consider throwing an exception here?
return new byte[0];
}
}
Now since exceptions are not part of the signature of methods, there
is
probably no runtime issue here. If the exception is not going to be
thrown
that is the same as it not actually being thrown, I guess. Still,
there is
a
compile time problem and if one removes the catch they can't compile
against
older codec (assuming that was declared to throw it).
Can somebody provide the background information on this exception,
from
this
method, and when (releases) it might've been available and removed? If
this
exception is never to be thrown again (and better, if it isn't thrown
in
currently released code) then maybe we can just ask the ws-xmlrpc
folks to
update.
BTW: I don't think there is a way to turn off this compiler error, is
there?
Would that be appropriate, even if possible?
regards,
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
-
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]
[codec] [convert] Re: StatefulDecoders
Alex Karasulu wrote: -Original Message- From: Brett Henderson [mailto:[EMAIL PROTECTED] You're right, encoders and decoders are special types of filters. But why create a distinction between the two when there is no reason to. If encoders require different methods to decoders then by all means create separate interfaces, but they are doing the same thing (transforming data) so surely we can use the same interfaces for both purposes. What do others think about this? It sounds sensible but I can't seem to shake the sense of comfort in making the distinction between the two. For the stateless operation there we may not have symmetry between the decode and encode halves. To my mind encoding and decoding are not distinct operations: they both simply transform information from one format to another. It seems "in the eye of the beholder" which format is "encoded" and which is "decoded". On the other hand, the case of lossy transformations may lend some weight to naming the format that contains less/degraded information the "encoded" format. Off the top of my head, I could imagine two video streaming applications that broadcast media in different formats. I imagine that each application will allow many formats for source media and "encode" to each chosen streaming format. If application A streams divx and application B streams ogg theora, the applications would disagree on which format to label "encoded". I'm leaning towards a single set of interfaces for data transformation. I am also beginning to suspect that codec and convert may be converging. Poking around the sandbox, I think compress might want to be assimilated as well. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] StatefulDecoders
As a user of codec, I would like to post a non-binding +1 for the interfaces in Alex's JIRA issue. They are simple and provide a clean, intuitive asynchronous interfaces for client usage. I'd also like to request the analogous interfaces on the Encoder side. Is codec going to continue to maintain String??coder and Binary??coder interfaces? If so, please implement these as subinterfaces of Stateful??coder. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ Alex Karasulu wrote: Brett, Noel, How about we put our minds together and finalize some of this stuff so I can start writing some codecs that can be added back to this project? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Notify about using the e-mail account.
Remy Maucherat wrote: Bill Culp wrote: Your attachment did not come through. Could you give me an example of the 'negative content'? This thing seems to be a virus targetted at the users of ASF products. Please ignore it. I have sent a request to apmail already to block these. Rémy Unfortunately, its not just targetted at ASF, and it will come from many many different mail addresses. The fact that it got posted to the list (which is moderated) tells me that either a) it fools the moderators, or b) a subscriber is infected. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] [moderation] Re: Email account utilization warning.
Hi Moderators, This is itself spam, probably a virus judging by the attachment. I have received several of these at my domain as well. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ [EMAIL PROTECTED] wrote: Dear user of Apache.org, Some of our clients complained about the spam (negative e-mail content) outgoing from your e-mail account. Probably, you have been infected by a proxy-relay trojan server. In order to keep your computer safe, follow the instructions. For more information see the attached file. Cheers, The Apache.org team http://www.apache.org - 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: bug in commons email (MIME related)
Hi, Well I needed a break from writing requirements and I use commons-email, so I thought I'd chip in here. This String is used to set the Content-ID header, which is specified in RFC 2392. (I love rfc-editor.org). content-id = url-addr-spec url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec cid-url = "cid" ":" content-id Well, I discovered that RFC 2822 (a proposed standard) obsoletes RFC822, but in my 5 minutes of reading they seemed to agree on what an addr-spec is: "addr-spec = local-part "@" domain ; global address". That's the one from 822, 2822 gets more complex with the local-part and the domain. Anyway, it seems Just Plain Wrong to shove random characters in there, right? The examples in RFC2387 seem to be appending an @domain.com to the Content-ID's anyway. If I missed something obvious, my apologies. Today was the first time I looked at these RFCs. I remember Noel and some others discussing a possible MIME library on this list recently; perhaps they have some input? -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ Oron Ogdan Adam wrote: line 183 in HtmlEmail.java : --- String cid = RandomStringUtils.randomAscii(10); --- this can produce special html chars, which are hard to escape, wouldn't it be easier and safer to randomly get alphanumeric chars of say size 20 ? BR Oron http://netada.co.uk - 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]
[validator][site] Download link?
Hi, There is no download link in the maven generated site for validator. I looked through the Project Info menu also. I remember seeing dozens of messages fly by about shared site generation using maven.. how is that coming? The "About Us", "Download", "View CVS", "Information", "Community", and "Translations" sections of the menu on the front page for Commons would look good as a link in the bottom section next to "Project Info" imho. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [release managers] Rsync with Apache's Maven repository
Mark R. Diggory wrote: __matthewHawthorne wrote: Paul Libbrecht wrote: Well... no, that means you would depend on daily build for all of Apache projects which definitely not the intent. Is it really a problem to have >one< project-name-SNAPSHOT.jar ? (and no dated things)? I disagree. If you specified both ibiblio.org/maven and cvs. apache.org/builds/java-repository as your remote repositories in Maven, you could easily depend on a released version or a SNAPSHOT. Maybe I'm misunderstanding you. Right, if your cofiguring your project dependencies to be "snapshot", you will be developing against the latest daily build. If you resolve your dependencies to a verison then your still always going to get that version, no matter whats in the daily build repository and where it points. The important thing to note, and I mentioned this in my last email is that when you allow Maven to do this resolution using the goal "resolve-snapshots", you would get different results with the daily build repository in your config, so, when cutting a release, it would be wise to remove the daily build repository from your configuration temporarily. Of course, this is all hypothetical, there is no daily build repository on cvs.apache.org yet. -Mark In any case, in my mind one should not be deploying SNAPSHOTs to the "release" repository anyway, its only for releases. Further, it seems to me to be a dubious practice to cut a release with a SNAPSHOT dependency in project.xml. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons] archives assistance [Configuration]
More specifically: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] Search body for +configuration +database -"bug database" Works for me. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net __matthewHawthorne wrote: I have a need to search the archives pretty often, but I don't seem to have the trouble that you have. True, the word "configuration" is probably very common, but usually a lot of messages that my searches return belong to the same thread, and it's not too hard to sift through and find what I need. Even if hundreds of messages are returned, it usually only takes a few minutes to find what I need. Maybe I'm just lucky ... Either way, what you're suggesting would be a good idea. Maybe try at the archives at: http://nagoya.apache.org/eyebrowse/ - 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: [all] Author tags redux
In response to Simon and Yoav's points about doing this with maven, I think it is quite possible. We already have in the POM, and I think a slight change to the changes plugin [1] would allow us to account peoples' patches effectively. Perhaps an optional attribute to the tage named submitted-by or something. Then, a custom goal in maven.xml (or a new plug in) would allow us to generate patch reports for non-committers. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net [1] http://maven.apache.org/reference/plugins/changes/ Simon Kitching wrote: If there is a website that contributors can point to and say "look, that's me" (eg for CVs) then I agree that author tags are not necessary. And the less clutter in the source files the better. Some system where the maven site had a list of contributors ordered by # of patches committed would be ideal though I can't immediately see how to implement that. and Shapira, Yoav wrote: We want to attract these new contributors, and this is a nice perk. Yes, it's in the changelog, but that's not as easy to find for all projects. I suppose we could put every contributor's name on a web page somewhere, but that's at least as much of a pain to maintain, because now you have at least two people involved: the contributor and the committer who has to edit the web page listing the contributors. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons - TLP
If that's the case, why not try to promote them to Jakarta proper? I know little of jxpath, but Digester seems like it would fit under Libraries, Tools, and APIs. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net __matthewHawthorne wrote: I think that Jakarta Commons is buried down deeper than it should be. Some of the projects such as [digester] and [jxpath] are so gosh darn useful that they deserve to be in a more visible space. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Digester vs xmlbean vs JAXB
The other responses were well written and fairly complete in discussing JAXB, Digester, and Castor. XMLBeans I think has been under-represented, but unfortunately I know little about it except that it was recently donated to Apache by BEA. Another option that hasn't been mentioned is Betwixt, which is very straightforward for bean <-> XML mapping. I got up to speed on it and successfully used it with my code in under 4 hours. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Samuel Cheung wrote: I have a newbie question. What are the advantages/dis-advantages between Digester vs xmlbean vs JAXB? My understanding is they convert XML file to Java Class. Is that correct? If that is the case, shouldn't one use JAXB over xmlbean and Digester, since JAXB is "standard"? Thanks for any feedback. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] Streamable Codec Framework
My apologies as well, I didn't realize you weren't a committer, nor that the MD5 stuff never made it into the release. Tim, everyone, now that codec is a released component, might we create a contrib directory or a codec-sandbox? Chris's MD5 stuff has been done for ages now. I am not a commons committer, or I'd take some action myself. This was previously tracked in Bug 17091 (http://issues.apache.org/bugzilla/show_bug.cgi?id=17091) but was CLOSED with resolution LATER. See Chris's attachment on 6/12/03. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Christopher (siege) O'Brien wrote: Apologies, that was not intended for the entire list. But since it went there, may as well elaborate. The ChunkedInputStream used a call-back system to provide a data written to the stream back in consistently-sized chunks (except for the last data written, which would be sized appropriately). This was useful in MD5 for obvious reasons in the streaming implementation. I factored it into its own class because I figured it could also be used in the SHA1 implementation that was in the works, and perhaps other registers-based hashes or checksumming codecs. Ryan, the original ChunkedInputStream should be a part of the package I put together for the MD5 package, as you correctly recalled. I had posted a note at one point offering the idea up to the IO folks, but I never got a response on that. - siege On Mon, 2003-11-10 at 19:12, Christopher (siege) O'Brien wrote: I don't have CVS access! But you do, and you should have a copy of the code... - siege - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Attributes] Inherit and Develop
Search back through the commons-dev archives. This code originally came from nanning, and there is a more recent version available. Some discussion began about incorporating attrib4j and the new stuff in nanning, but I think we got stuck because few of the interested developers are currently commons committers. In any case, it can only be a good thing to compare notes with the other implementations out there. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Leo Sutic wrote: Hi, I'm a comitter at the Avalon project (avalon.apache.org), and I have developed tools and API to enable C#/.Net like attributes in Java. Originally I developed it as a proof-of-concept, and we held a vote on what to do with the project once the proof was done. The result was basically "nice code, make it a real project - but do it elsewhere". The Commons Attributes project seemed to be the most natural place to go to. As far as I can see, Commons Attributes is *dead* in terms of development. Therefore I ask the following: + Commit access to jakarta-commons-sandbox/attributes + Some indication that the attributes project is indeed dead and that I can "inherit" it. This is just to pre-empt any conflicts arising from committing code to a repository that used to be used by someone else. For an explanation of what I have done, you can read the Javadoc Overview (along with some Q&A) at: http://cvs.apache.org/viewcvs.cgi/*checkout*/avalon-sandbox/attributes/a pi/src/java/overview.html?rev=HEAD&content-type=text/html /LS - 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]
[jexl] dotted property names in expressions
Hi, There is a problem with jexl when testing dotted property names for emptiness. I am using it from jelly through maven: maven -Ddotted.property.name=foo goal inside the goal: Empty property Empty little property Only the first echo happens. If I get more time to get the code from CVS working in eclipse and to get my head around Jexl internals, I'll write a unit test. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY] Commons-csv or not?
Looks great. Actually, Cocoon has a CSVGenerator now that turns CSV files into XML SAX events. Perhaps factoring stuff out of there is appropriate if we want to create an independent effort here. The other formats you mentioned interest me greatly, especially EDIFACT. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Simon Kitching wrote: Hmm .. an "import-stuff-into-xml" project? Interesting... I have in fact written exactly this for my current employer, for a (continuously expanding) series of formats. We then apply stylesheets to the results, for various purposes. I doubt I could contribute any code, but can definitely confirm that I would have used such a library if it had existed about a year ago when I started (and had been sufficiently flexible/complete)! I could also contribute a collection of weird and wonderful formats as invented by our clients :-) Here's a few possible formats in addition to csv: * ASN.1 * windows .ini files * java .properties files * EDIFACT * apache-httpd .conf format :-) And here's some potential "competitors", which also import data into xml formats: * Microsoft Biztalk * IBM Websphere Business Integration Note that I'm not pushing for or against the existence of this project. Just had some thoughts to toss into the discussion Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Checked vs Runtime exceptions
This may be the "correct solution" in some of your eyes, but it is far
too much overhead for most programmers who want to use logging. If my
database server is down or the logging directory can not be found when I
want to log something, my application code is not the right place to
handle that.MyMethodUsesLogging has no business handling those
exceptional cases. I think a RuntimeException is most appropriate here.
Juozas Baliuka wrote:
I think this logging example was a good one:
void MyMethodUsesLogging()throws MyException{
try{
log.info("started");
}catch(LoggingException e){
log.error(e); // ??
throw new MyExeption(e);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[attributes] Limitations of current implementations
Hello, I have been investigating commons-attributes for use with XML-RPC, specifically to denote which methods on a given class should be exposed via an XML-RPC server. I have done some reading on the web about metadata, including JSR175. I would like to get feedback from some more experienced developers about some implementation decisions. In particular, both attrib4j and commons-attributes make the following assumptions: - There is one set of metadata for a given language structure - An attribute set and the attribute values are immutable These assumptions seem to be unnecessary and they limit what can be accomplished using metadata. I could not find language addressing them in JSR175. First, the assumption that there is only one set of metadata for a given language structure is already more restrictive than the current usage of deployment descriptors in J2EE. A class might have separate types of metadata for different runtime or deployment time usage. Attributes used for EJB code generation might be better kept separate from attributes for persistence, security, RPC, and other concerns. Second, I do not understand the need for an attribute to remain constant for a particular version of a class. Some attributes might be better defined by the application deployer than by the class programmer. Future users of the class might want to assign additional attributes to language structures that were not foreseen by the programmer. A container might be able to leverage a facility for runtime attribute modification in order to perform its duties. If anyone can shed some light on these issues, I would greatly appreciate it. Thanks, -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging packaging questions
Hey folks, I would disagree if the jar sharing mechanism provided for versioning. There are several ways to accomplish this, but the maven repository does it in a very simple and practical way. All that would be left to jpackage-type tools is the dynamic runtime classpaths. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net David Graham wrote: I don't work on commons-logging so I won't speak to satisfying your request but I am curious about why you need this behavior. I would *never* allow all of my apps to share jars between them and upgrade them all at the same time. The amount of testing that would require is simply unreasonable not to mention the fact that all apps aren't on the same development/deployment cycle. IMO, sharing jars in this way is asking for trouble. David The jpackage project (http://www.jpackage.org/) is a volunteer project devoted to providing clean linux rpm packages of java stuff. Since Linux core processes permit very fine control of what's actually installed on the system, one of our main goals is to enable component sharing instead of the usual java practise of having a copy of every single needed jar in every single app. Since every library is only installed once on the system, it must be installed right to please every user app. (OTOH this allows ugrading a component in every app at once instead of having to rebuild all the users). Applications use a common script framework to build classpathes out of available jars and/or create symlinks when they need directories of jars to run. This is a rather unusual setup (even if our users love it) and as a result we tend to find problems other people miss. The most recent one involves tomcat4,commons-logging and log4j. I won't bore you with technicalities (the whole discussion is available at the http://lists.zarb.org/pipermail/jpackage-discuss/2003-June/002084.html url, and I think it even overflows in a few other threads) but we found we needed some changes in commons-logging jar structure and we'd rather have them into jakarta proper instead of branching stuff (we've been providing official linux rpms of jakarta stuff and we'd rather keep it that way). Anyway : 1. we absolutely need removal of the log4j classpath entries in the generated jar manifests (as a rule we consider classpathes in manifests evil since they result in subtle behaviours no human can really handle. They won't work most of the time and when they do it's not like the user intended). We do not want log4j stealth-drawn into the classpath if present like it is now and users want control of the actual logging backend used. 2. we'd like the build-in backends split from the main jar so we can made them optional and allow people not to install them if they already have log4j or a 1.4 jvm. 3. people have asked for further splittage of the backend glue so they can only install the parts relevant to the backend they'll actually use (ie separate log4j, jdk 1.4, avalon... parts). In linux speak that would get us : commons-logging frontend requires commons-logging-backend commons-logging-log4 provides commons-logging-backend requires log4j commons-logging-jdk provides commons-logging-backend requires java >= 1.4.0 commons-logging-simple provides commons-logging-backend and so on, each package consisting of a single jar with no classpath in its manifest. I realise I've not been as terse as I wanted to so I'll stop now. Just ask if I wasn't clear enough. Regards, -- Nicolas Mailhot << signature.asc >> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] promote commons attributes to the commons proper
Non-binding +1 -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net James Strachan wrote: Jon, Paul - this is all seeming a little painful to make useful progress working within Jakarta Commons. Adding 1 non-apache committer to a sandbox project seems too hard right now - we're stuck in a chicken and egg - some don't want non-apache committers working in the sandbox and some don't want us promoting a project to commons proper so we can add a new committer. Why don't we just scrap commons-attributes in the sandbox and move the project over to codehaus.org instead? Its certainly the easiest option. On Wednesday, June 11, 2003, at 10:16 am, Martin Cooper wrote: On Tue, 10 Jun 2003, James Strachan wrote: So that we can add some more committers to the commons-attributes projects to help unify the various attribute-replated projects out there (initially commons-attributes and Nanning but maybe eventually attrib4j too) I'd like to propose we promote commons-attributes to the commons proper. Then we can work on merging the code bases and patches and working towards an alpha release. -- - Vote: Promote commons-attributes to commons proper [ ] +1 I am in favor of the move, and will help support it [ ] +0 I am in favor of the move, but am unable to help support it [ ] -0 I am not in favor of the move [X] -1 I am against this proposal (must include a reason). -- - It seems to me that this is entirely the converse of what Apache is about. The suggestion here is that a project be promoted out of the sandbox in order to build a community around it. That is the *opposite* of what we want to achieve. If the participation of people currently outside of Apache is necessary to build a community around commons-attributes, then this is a project that should be developed further elsewhere, and perhaps (re-)introduced to the Incubator when that community exists. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: _Commons-Attributes_(sandbox)_and_
robert burrell donkin wrote: On Sunday, June 8, 2003, at 03:48 PM, Ryan Hoegg wrote: I am currently a committer on ws.apache.org/xmlrpc. Can I help? like anyone else you can help out as a developer ;) i'm not an commons-attributes committer, so others will have to answer whether they'd be happy to have you on-board as a committer but i can probably give you an answer in theory: as a apache committer you can now request jakarta-commons-sandbox karma from the jakarta pmc (pmc at jakarta. apache.org) giving your reasons (maybe something like 'to help out on commons-attributes'). please supply your apache user name with the request (this makes things easier for infrastructure). - robert Sounds good, first I suppose I should talk to the attributes committers. Before I jump in and start working on merging the codebases, I should make sure that the commons-attributes committers want that. In an e-mail from Jon to Mark Pollack and me, it seemed that he needed some convincing :) -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: _Commons-Attributes_(sandbox)_and_Jon_Tirsén.
I have e-mailed briefly with Mark Pollack of attrib4j.sourceforge.net. It seems some work needs to be done to support JSR175 for both commons-attributes and attrib4j. The main difference Jon and Mark have so far is the Attribute interface, where Mark would rather not have String properties for Name and Value. One interesting thing about attrib4j is that it stores its attributes in the class file instead of a separate properties file. I think that since the attribute storage mechanism is already abstracted in the current commons-attributes through the DefaultAttributeFinder and DefaultAttributeCompiler, it would make sense to agree on a common interface and create multiple implementations. I am currently a committer on ws.apache.org/xmlrpc. Can I help? -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Paul Hammant wrote: Well I volunteer to help this get promoted out of sandbox. I've done work on it before (pairing with James Strachan - which he never committed - grumble grumble ;) Jon, that sound good to you ? - Paul --- robert burrell donkin <[EMAIL PROTECTED]> wrote: > i'm against nominating committers for work on sandbox components. (apache committers should just be able to request karma and then check with the current committers that it's ok to join the fun.) if jon is an existing apache committer then he needs to post a request to the pmc cc'ing commons-dev giving some brief indications of his plans. we should then be able to sort out karma with infrastructure. IMHO if jon is not then the best solution would be for an existing apache committer to volunteer (yourself, maybe) to lead an effort to push attributes forward to a stage where it's ready for promotion to the common proper. BTW are there any copyright issues associated with the Nanning code? - robert On Sunday, June 8, 2003, at 11:33 AM, Paul Hammant wrote: Jon has been working on attributes inside Nanning's CVS. The code we have (which is really) good is an earlier fork of that. Is there any way we can get Jon commit provs here? The version in Nanning is much more advanced than the version he donated to us earlier. If we can get some consensus, I think a vote may be a good idea. Surely he must qualify on the multi-month patch donator principle? - Paul __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] codec to commons
+1 O'brien, Tim wrote: Formal vote, codec is ready for a release. Please submit votes within the next 72 hours, I will summarize the results at that time. * Base64 is based upon the latest code from HttpClient and XML-RPC - the interfaces are a product of negotiation between these two efforts. * Codec contains a number of language utilities - Soundex, RefinedSoundex and Metaphone are stable and ready for use. I am currently consulting the PMC for an opinion on DoubleMetaphone and Nysiis. * The goal for this release is simply to provide a common Base64 implementation for HttpClient and xml-rpc. There are other available utilities. * There is a community of contributors who have shown a clear interest in expanding codec - contributors can be found on this report: http://jakarta.apache.org/commons/sandbox/codec/team-list.html * As required by the proposal, codec is simple, and well-tested package: http://jakarta.apache.org/commons/sandbox/codec/clover/index.html Here is a copy of the tightly scoped PROPOSAL: Proposal for Codec Package January 24, 2002 (0) Rationale Many software projects have a need to use various formats of data, and to be able to switch between various formats. The codec package seeks to encapsulate some of the most popular encode/decode algorithms in one easy to use, well tested package. A base64 codec is the first candidate, with others to follow soon. (1) Scope of the Package This proposal is to create a package of Java utility classes for the encoding/decoding of various types of data. A base64 codec will be the first implementation. (1.5) Interaction With Other Packages Codec relies only on standard JDK 1.2 (or later) APIs for production deployment. It utilizes the JUnit unit testing framework for developing and executing unit tests, but this is of interest only to developers of the component. Codec will be a dependency for several existing components in the open source world. No external configuration files are utilized. (2) Initial Source of the Package The original Java classes (Base64, etc.) are splashed around various Apache subprojects. We intend to seek them out and integrate them. The proposed package name for the new component is org.apache.commons.codec. (3) Required Jakarta-Commons Resources CVS Repository - New directory codec in the jakarta-commons CVS repository. Mailing List - Discussions will take place on the general [EMAIL PROTECTED] mailing list. To help list subscribers identify messages of interest, it is suggested that the message subject of messages about this component be prefixed with [Codec]. Bugzilla - New component "Codec" under the "Commons" product category, with appropriate version identifiers as needed. (4) Initial Committers The initial committers on the Lang component shall be as follows: Scott Sanders (sanders) Henri Yandell (bayard) Daniel Rall (dlr) Tim O'Brien (tobrien) Tim O'Brien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons codec and Base64
Let's say it's "stabilizing". The code there is also slated for 2.0 of Apache XML-RPC. We have been the most recent project to work on that code, but are coordinating with the HttpClient team on agreeing on the API. The API is probably not stable as of now, but I'd love to see your ideas on it. The code has been examined quite closely for RFC compliance and performance, so I would suggest using the Codec Base64 implementation for that reason anyway. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Gary Gregory wrote: Hello All, What is the status of Sandbox-Commons-Codec? I see in the current HTTPClient (2.0 Alpha) Javadoc that Codec will be used in HTTPC 2.1. Is Codec stable? I am looking for a Base64 implementation and an API change in a deeply buried Xerces base64 impl is making me look for a implementation which is more 'public' or in a 'higher' level package/component. Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Data Transformer Proposal
I like this idea. Would this be a front end to things like Castor and Digester, or would they move to this component? Also, do you already have a codebase you have in mind for this? -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net P.S. Out of curiosity, are you familiar with any open source EDI transformation code? [EMAIL PROTECTED] wrote: - Commons Data Transformer - Sandbox Component proposal - Data Transformation is essential part of day to day computing, whether it is xml-to-xml transformation, xml-to-java transformation, edi-to-java transformation etc. Lets take a simple example of xml-to-java transformation (or vice versa) There are several implementations : Castor, JAXB to name a few. Usage of these introduces dependencies on the implementation. This immediately draws similarity with commons-logging. Commons-Logging acts as a Adapter between the user code and the implementation, freeing the user code from Log4J and J2SE Logging imports. (Thus allowing plug and play logging at the code level.) A similar approach for Data transformations in general (xml-to-java objects in particular) is highly desirable. Programmers like to access in memory Java object representations of external data. Hence I propose a Commons "Data Transformer", freeing the user from implementation specific imports. I envision Commons Data transformer will perform "x-to-java" (direct transform) and "java-to-x" (inverse transform) transformations. PS : It is interesting to note that certain kinds of Configuration are really a subset of data transformation. Thanks, Srikanth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC channels
Kasper Nielsen wrote: Jandalf wrote: Is there any IRC servers and channels in use by Commons? HttpClient is planning an IRC session and we need a home. Any talk about an irc.apache.org? try irc.werken.com there is a couple of apache projects like maven, turbine, ojb, velocity hanging out there. irc.freenode.net seems popular as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Code formatters
Hi all, Can anyone recommend a good code formatter and templates to use to clean up code for commons? -- Ryan Hoegg ISIS Networks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] To depend or not to depend?
Craig R. McClanahan wrote: On Fri, 7 Feb 2003, Ryan Hoegg wrote: Starting a new thread for this, it really has little to do with CLI. We are having a similar dilemma in XML-RPC. The idea of a SafeCommonsLogger seems sound. It could even end up in a commons-stub package. It would do nothing if commons-logging-api.jar or commons-logging.jar is not in the CLASSPATH. Instead of trying to convert every commons-logging user in the world to switch to using SafeCommonsLogger as a wrapper around commons-logging (which is itself a wrapper around ... nah, let's not go there at the moment :-), I have an alternative suggestion. Why not just provide a trivially simple two-class JAR file that defines org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory with exactly the same public APIs as the "real" ones? Then, just ship this tiny little JAR file with apps (or applets) that don't want to use commons-logging. The resulting JAR file is going to be pretty much the same size as something containing SafeCommonsLogger anyway. As long as your replacement classes maintain binary compatibility with the standard ones, any code that currently thinks it is using commons-logging will be transparently using your own version instead. Sounds interesting. I will ask Daniel Rall, as he is the one who pointed out the problem with the same class showing up in multiple places in the CLASSPATH. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] To depend or not to depend?
Commons-logging-api.jar is 16K, which would increase our applet JAR size by 60+%. That's not acceptable for a system level service like logging. -- Ryan Hoegg Henri Yandell wrote: Why not just put SafeCommonsLogger in commons-logger.jar? Is commons-logging.jar's 20 odd K isn't that huge. Also, commons-logging could move the implementations out into commons-logging-impl.jar, or even one per underlying logging framework to make that 25K smaller. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] To depend or not to depend?
Starting a new thread for this, it really has little to do with CLI. We are having a similar dilemma in XML-RPC. The idea of a SafeCommonsLogger seems sound. It could even end up in a commons-stub package. It would do nothing if commons-logging-api.jar or commons-logging.jar is not in the CLASSPATH. -- Ryan Hoegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] RE: Base64.java
We do as well. Codec should probably end up with the union, not the intersection However, ours tests for the MIME specific 76 character line wrapping. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Jeffrey Dever wrote: That sounds good here too. We only call Base64 methods a couple of times anyway, so adaptation is a minor issue. Just a note about tests, we have a Junit test class (not sure if xml-rpc has one) that should go along with the main Base64 class. You did a grep on the code base so I'm sure you are aware of it. Jandalf. I like your plan Tim. Let's get 1.1 nailed down so we are all on the same codebase, and do the design of 2.0 right. I don't think XML-RPC cares much whether we get the default in decode(byte[]) in 1.1, I think that decision should be made based on RFC interpretation. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] RE: Base64.java
O'brien, Tim wrote: 1) One of the classes in the package set the flags in a static block. 2) The flags are set before each call to the Base64 encode/decode methods. To use flags safely, you would have to make them instance members and requre instantiation of Base64 objects. This does more harm than good. No, static flags. That is harmful. If you take a look at http://cvs.apache.org/~tobrien/codec/evolve.html, you notice that we move towards an approach where one could instantiate a Base64 instance and configure certain properties of the encoding algorithm. We'll keep the static methods for ease of use, but behind the scenes those two functions would be maintaining and configuring two separate "instances" of the class - we'll get there, my main concern right now is to achieve a level of reuse and then we can go about developing sound OO design behind the scenes without violating our contract to both xml-rpc and httpclient. It cannot be overemphasized that we are not talking about configuring a class via static flags. That's a dangerous proposition, especially in multi-threaded environments. I'm out of contact for 2 days, so I'll let the discussion simmer a bit. Tim O'Brien I like your plan Tim. Let's get 1.1 nailed down so we are all on the same codebase, and do the design of 2.0 right. I don't think XML-RPC cares much whether we get the default in decode(byte[]) in 1.1, I think that decision should be made based on RFC interpretation. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] RE: Base64.java
If this is the direction in which we are headed, I would nominate Henri's initial idea. Bear in mind we are not talking about 1.1 here, but 2.0 (i.e. future). For 1.1, my vote (as a committer in XML-RPC) is for Jeffrey's solution, with the default being opur consensus on the reading of the relevant RFCs. For 2.0, I think the idea of a Base64 interface with different implementations sounds cleaner than either idea. Reason being, the user of decodeChunked propbably wants to be using encodeChunked as well. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Henri Yandell wrote: I agree with you up until the last point. Rather than an obscure and irritating boolean argument on the end, just offer a different name. public static byte[] decode(byte[] data); public static byte[] decodeChunked(byte[] data); [bear in mind decodeChunked may be a bad name. I'm just copying :) ] Hen On Tue, 4 Feb 2003, Jeffrey Dever wrote: There does not seem to be much choice other than overloading the method signatures: public static byte[] decode(byte[] data); public static byte[] decode(byte[] data, boolean chunk); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Codec] Configuration flags
Hi, I am importing a discussion to Commons Dev that has been going on in HttpClient, XML-RPC, and off-list in private e-mails. Tim O'Brien thus spake: My personal feelings here are that we should have some flags for RFC compliance - if you want to be warned on invalid characters/whitespace, set a flag If you want to throw an exception on an invalid exception, set a flag If you want a trailing newline for RFC compliance, set a flag. By default, we'll maintain compliance, and it is up to the user to set some boolean properties to alter behavior. We'll make it very clear in the documentation what the default behavior is. Feel free to open this discussion up to a mailing list. I'm only keeping it private because the conversation was started in private. We shouldn't make any decisions in a private discussion, but I can't help but think this is a more general issue that has been seen in many projects. I have seen similar discussions on the HttpClient list for things like setting HTTP 1.1 mode. Perhaps Jakarta Commons should settle on one way to do configuration? In XML-RPC we have started using a setProperty() method with constants for property names. In Avalon, they have a first class Configuration class, with setAttribute methods. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH][HttpClient] bug 12607
As you probably suspected, the server's response doesn't seem to be showing any extra stuff in the chunk-size section. In fact, I think the problem is that the server is giving a Content-Length header as well as chunking. From RFC2616: If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored. This is what my sniffer shows as the server's response: HTTP/1.1 200 OK Date: Sun, 29 Sep 2002 18:20:42 GMT Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.2.2 X-Powered-By: PHP/4.2.2 Transfer-Encoding: chunked Content-Type: text/xml Content-length: 338 152 faultCode 1 faultString Unknown method 0 And this is what UrlPostMethod.getResponseBodyAsString() is returning: 152 faultCode 1 faultString Unknown method Could you post the server's response? > > Ryan Hoegg wrote: > >> Although it seems we will be going to BNF as a regex someday, I am >> suspicious that this very issue is causing incompatibility with a >> HTTP 1.1 server I am trying to access. So I may make a stab at >> parsing this chunk size thing as I wrote below. Am I right in >> assuming this patch should go to bug 12607? > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH][HttpClient] bug 12607
I went back to RFC2616 to find this (3.6.1):
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer= *(entity-header CRLF)
and this (2.2):
token = 1*
Since chunk-extension includes only tokens and an "=" I read this to say
that neither \r or \n is allowed before the first CRLF in a chunk.
--
Ryan Hoegg
ISIS Networks
Ortwin Glück wrote:
> Not sure if single \n or \r is allowed here or not. Maybe leave it as
> it is.
>
> "Real world guys" anyone?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Test suites
Hello, I am curious as to how you have been approaching building tests for peculiar behavior of HTTP servers. I am having issues with particular HTTP servers in 1.1 mode with chunking, so I want to build a test for it without introducing a dependency on the uptime or software version of a particular server on the internet. How have you solved this problem in the past? -- Ryan Hoegg ISIS Networks -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH][HttpClient] Bug 12607 fix w/ test + typo fixes
I have tested the patch to ChunkedInputStream on my local copy and it works; in fact, it solved a larger problem I was having integrating HttpClient into the Apache XML-RPC project. Thanks Martin! -- Ryan Hoegg ISIS Networks Elwin, Martin wrote: >ChunkedInputStream.java.diff is a patch for the 12607 bug. The solution was >proposed by the bug submitter and I've verified it as well. > >Simple real-world test to verify the bug and the fix: > >.../jakarta-commons/httpclient/target/examples$ java -classpath >.;../classes;../../lib/commons-logging.jar TrivialApp http://slashdot.org > >TestStreams.java is updated to include a test of this as well (and a small >fix to the suite() method so that the test is executed at all! :). Splitting >the testChunkedInputStream into several methods (or tests) might be good. > >The two other diffs are for a typo in a trace output in HttpConnection and a >typo in the syntax description of TrivialApp. > >Kindly, > >/M > > >Martin Elwin >@N59.29606 E18.08052 (WGS-84) > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [httpclient] Content-Length handling
You are right. If we wait, we are basically falling back to waiting for the server to close the connection in every case. I believe that HttpClient behaves correctly. I have already pursued this with the appropriate HTTP servers :) -- Ryan Hoegg ISIS Networks Ortwin Glück wrote: > My point of view: > > We should primarily stick to the RFCs. (Yes I know there are other > interest groups who do server testing). If there are servers that have > a faulty HTTP implementation that's their problem (which should be > corrected), not ours. Better write to them :-) > > But the actual problem here is more: How can we determine that the > content-length was reported too small? > > Imagine the following situation: > Server reports content-lenth 1000 bytes. The actual content is 1015 > bytes. After 10 bytes the server pauses (maybe because of network jam) > and after some seconds the remaining 15 bytes arrive. There is > absolutely no reason why the client should wait (for how long?) for > more data after it has received the reported number of bytes. > > So we can not detect this in general, right? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
