Re: Jakarta Commons Structure rehashed
Tim O'Brien [EMAIL PROTECTED] writes: I know that most posters love Option A, however this makes it very hard to check out the whole commons in one go. Which is what e.g. the maven reactor builds would like to have (are they still used?) or the commons builds, that need the site module. You have the symlinks option already with subversion 1.0; it is called svn:externals. It is not very maintainable IMHO, though. So, personally I'm +1 for the subversion move, -0 for Option A and +1 for Option B. Regards Henning --_56C95760-3542-4CAA-8B06-025FDD8B49FA_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I don't think we ever settled this question.=20 Which SVN structure are we interested in? ** Option A: jakarta/ commons/ digester/ trunk/ tags/ branches/ beanutils/ trunk/ tags/ branches/ OR=20 ** Option B: jakarta/ commons/ trunk/ digester/ beanutils/ tags/ digester/ beanutils/ branches/ digester/ beanutils/ --_56C95760-3542-4CAA-8B06-025FDD8B49FA_-- -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Commons Structure rehashed
Tim O'Brien [EMAIL PROTECTED] writes: Not following this one, this implies that ASF has one trunk. Even though copies are cheap I wouldn't want to create a copy of the entire SVN tree for every release. So, don't do it. Just copy your directory. into the release. Subversion does not have the rigid directory structure of CVS. Just copy your subtree into the release directory and be done. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Commons Structure rehashed
Not very convenient to manage, though. Option B is better IMHO. I don't understand this argument. One propset/propdel combo for promotion or demotion is very manageable. However, as other arguments in this thread have put forward, option A has other benefits that don't have an alternative, or are less convenient day-to-day, in option B. Releases, tags and branches of individual modules are more frequent than new modules at this level. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Commons Structure rehashed
Noel J. Bergman [EMAIL PROTECTED] writes: I also prefer the flatter layout: jakarta/commons/tags/ /branches /trunk We don't version Commons as a single component, and I don't know that we want to force everyone to always take every single component. Someone wanting to build all of Commons is not the norm. So check out jakarta/commons/trunk/digester and work there. Checking out the whole trunk is not the norm. Folks, this is not CVS. You are not bound to a rigid structure as with CVS. But you _want_ to be able to check out multiple projects side by side. Because some of the depend on each other (or on the commons-site module). A major nit that I have to pick is the growing number of project building with maven and the inability of _many_ maven plugins like the changelog, dev or file activity lists to _use_ subversion. This is actual information that we lose from the project sites if we go subversion. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Commons Structure rehashed
Hi Henning, I replied to this on jakarta general the other day. A major nit that I have to pick is the growing number of project building with maven and the inability of _many_ maven plugins like the changelog, dev or file activity lists to _use_ subversion. This is many = 4. the 3 you listed, plus SCM. the 3 you listed work on linux, and there is a patch for windows that I am about to test and commit. I'm working on SCM, but commons does not at present use this anyway. gump and cruisecontrol, to the extent they use it, already work with subversion. If you find any other limitations, please let me know. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Commons Structure rehashed
Brett Porter [EMAIL PROTECTED] writes: Hi Henning, Hi Brett, A major nit that I have to pick is the growing number of project building with maven and the inability of _many_ maven plugins like the changelog, dev or file activity lists to _use_ subversion. This is many = 4. the 3 you listed, plus SCM. the 3 you listed work on linux, and there is a patch for windows that I am about to test and commit. Are these the versions released with 1.0.2? Also I feel uncomfortable with works on one platform but not on another. Also, some plugins (quick grep; e.g. release) depend on SCM to do the right thing. A non-working release plugin is a no-go IMHO. I'm working on SCM, but commons does not at present use this anyway. How many commons components use maven for releasing? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Commons Structure rehashed
Are these the versions released with 1.0.2? Also I feel uncomfortable with works on one platform but not on another. Yes. There is a windows specific bug in that release, so an updated plugin will be made available for those publishing a site from a windows machine. This requires a manual install of a new plugin: maven plugin:download -DgroupId=maven -DartifactId=maven-changelog-plugin -Dversion=1.X.X (this will fix all 3) Also, some plugins (quick grep; e.g. release) depend on SCM to do the right thing. A non-working release plugin is a no-go IMHO. confusing aspect - the release was an experiment left around because it provides some support code to other plugins. The SCM plugin I mentioned has some release goals. These are all really just convenience goals - certainly not something you need to use day-to-day. The future goal is to redevelop these with complete requirements. Deployment itself is unaffected. I'm working on SCM, but commons does not at present use this anyway. How many commons components use maven for releasing? AFAIK, just Jelly and Jexl. Hopefully by the time they come to a new release, the new plugin will be ready for download. Its not a huge amount of additional work These are all issues, but not blocking IMO. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: [proposal] avoiding jar version nightmares
I think handling different versions of classes/jars at VM level would be a nice feature, but it would be very hard to implement nd to understand when it comes to reflection. Another proposal would be to do it the j2se-way: When introducing new features to a package (e.g. java.io) don't include the version number in the package name, but call it new (e.g. java.nio). So what about: org.apache.commons.component gets org.apache.commons.ncomponent in its next incompatible version. The next incompatible change will result in org.apache.commons.vncomponent (very new component) Each major version step will add a leading v-character After five major versions, the five v-characters can be replaced by an 'a' (absolutely new) So this might be a way to handle many different major versions without adding the nasty version number to the project name, but indicate clearly what the package is all about. BTW: How will digester2 manage this problem? Is it not a good starting point to call the package digester2 or digester-2 or ndigester or whatever? Cheers, Daniel Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am 20.12.04 01:11:00: The ability to declare your own versioning information, and that of your dependencies, in a MANIFEST.MF file already exists: http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html Two existing use cases for this information are applets and servlet containers, where the container should examine the manifest of the applet itself (or the WAR in the case of a webapp) and reject execution if the specified versions of the declared dependencies are not present. But nothing stops a container from doing more with this info (see below for one idea). What's missing today at the *language* level is the ability to load incompatible versions into the same class loader. That would take language and JVM architecture changes -- if that's important to you, go find the threads on ServerSide or JavaLobby about providing feedback to the requirements for Mustang (JDK 1.6), since that's the earliest time we could actually get it into the language itself. In the mean time, nothing stops a servlet container provider from assembling dynamically an appropriate parent class loader that contains just the specified dependencies (instead of, or in addition to, the kind of thing that Tomcat does with its shared and common class loaders). That way, one could provide webapp A with version 1 of the library, and webapp B with version 2 of the same library, which is pretty much equivalent to what you describe for .NET. Seems like a good RFE for Tomcat ... However, this won't solve the two incompatible versions in the same webapp use case -- for that, you'll still need to use child class loaders. It sounds like this would also be true in the .NET environment??? Craig On Sun, 19 Dec 2004 18:37:43 -0500, Matt Sgarlata [EMAIL PROTECTED] wrote: Craig McClanahan wrote: On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata [EMAIL PROTECTED] wrote: How do we go about petitioning Sun for something like this? A while back now (while the details for Tiger were being planned), I happened to be in a meeting with Graham Hamilton (who basically owns the direction that J2SE is going from a Sun perspective), talking about the very issue of class loaders and the contortions that you have to go through in order to implement things like webapp reloading. I asked him for a Christmas present to all Java developers -- add something like ClassLoader.unloadClass() or ClassLoader.replaceClass() to deal with things like this. He said hmm ... that's a hard problem and proceeded to describe several of the places where implementing this would be extremely difficult (and/or would have nasty performance impacts) in the current architecture of JVMs. Well what about introducing the versioned library approach that is done in .NET? I'm not familiar with the details myself, but Chris Lambrou wrote earlier: The .NET equivalent of a jar file is called an assembly. For libraries, this is basically a DLL. Every time the code is compiled, the DLL is automatically allocated a unique version number. When you compile your code that refers to code in a library assembly, your assembly has an explicit dependency on that library assembly. At runtime, when your code tries to invoke the library code, an exception will be raised if the exact version of the library assembly is not available. It would appear that if there are bug fixes or other improvements to the library, and a recompiled assembly DLL is substituted for the one you originally compiled against, then your code will break. At runtime, your code will fail to link to the library code, since the version number no longer matches. Obviously, a maintenance release of a library component shouldn't require a recompilation and redeployment of all
[GUMP@brutus]: Project commons-chain (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-chain has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 5 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-chain : GoF Chain of Responsibility pattern Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-chain/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-chain-20122004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: myfaces unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons/commons-chain/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons/commons-chain/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 3120122004, brutus:brutus-public:3120122004 Gump E-mail Identifier (unique within run) #19. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-id (in module jakarta-commons-sandbox) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-id has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-id : Commons Identifier Package
Full details are available at:
http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole output [commons-id-20122004.jar] identifier set to project name
-DEBUG- (Gump generated) Maven Properties in:
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml
-DEBUG- Maven project properties in:
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html
Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build)
Work ended in a state of : Failed
Elapsed: 4 secs
Command Line: maven --offline jar
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id]
CLASSPATH:
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar
-
[mkdir] Created dir:
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/target/classes
java:compile:
[echo] Compiling to
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/target/classes
[javac] Compiling 35 source files to
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/target/classes
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task/UUIDTask.java:21:
package org.apache.tools.ant does not exist
import org.apache.tools.ant.BuildException;
^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task/UUIDTask.java:22:
package org.apache.tools.ant does not exist
import org.apache.tools.ant.Task;
^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task/UUIDTask.java:23:
package org.apache.tools.ant.types does not exist
import org.apache.tools.ant.types.EnumeratedAttribute;
^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task/UUIDTask.java:29:
cannot resolve symbol
symbol : class Task
location: class org.apache.commons.id.task.UUIDTask
public class UUIDTask extends Task {
^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task/UUIDTask.java:43:
cannot resolve symbol
symbol : class EnumeratedAttribute
location: class org.apache.commons.id.task.UUIDTask.UUIDVersion
public static class UUIDVersion extends EnumeratedAttribute {
^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task/UUIDTask.java:53:
cannot resolve symbol
symbol : class BuildException
location: class org.apache.commons.id.task.UUIDTask
public void execute() throws BuildException {
^
/home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/task/UUIDTask.java:50:
cannot resolve symbol
symbol : method getValue ()
location: class org.apache.commons.id.task.UUIDTask.UUIDVersion
uuidVersion = newVersion.getValue();
^
[GUMP@brutus]: Project commons-jelly-tags-jsl (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 32 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl : The Jelly Stylesheet Library (JSL) Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-jsl/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jsl-20122004.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-jsl/gump_work/build_jelly-tags_commons-jelly-tags-jsl.html Work Name: build_jelly-tags_commons-jelly-tags-jsl (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-jsl-20122004 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/jsl] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/jsl/target/classes:/usr/local/gump/public/workspace/jelly-tags/jsl/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-20122004.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20122004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20122004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-20122004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-20122004.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/standard.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar:/usr/local/gump/public/workspace/jelly-tags/xml/target/commons-jelly-tags-xml-20122004.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-20122004.jar:/usr/local/gump/public/workspace/jelly-tags/ant/target/commons-jelly-tags-ant-20122004.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/grant/target/commons-grant-20122004.jar:/usr/local/gump/public/workspace/jelly-tags/log/target/commons-jelly-tags-log-20122004.jar - Buildfile: build.xml init: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jelly-tags/jsl/target/lib get-deps: compile: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jelly-tags/jsl/target/classes [javac] Compiling 7 source files to /home/gump/workspaces2/public/workspace/jelly-tags/jsl/target/classes [javac] /home/gump/workspaces2/public/workspace/jelly-tags/jsl/src/java/org/apache/commons/jelly/tags/jsl/ApplyTemplatesTag.java:67: cannot resolve symbol [javac] symbol : method applyTemplates (java.lang.Object,org.jaxen.XPath,java.lang.String) [javac] location: class org.dom4j.rule.Stylesheet [javac] stylesheet.applyTemplates( source, select, mode ); [javac] ^ [javac]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient ProxyClient.java
olegk 2004/12/20 03:39:04
Modified:httpclient/src/java/org/apache/commons/httpclient
ProxyClient.java
Log:
Removed references to deprecated methods
Revision ChangesPath
1.5 +6 -6
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ProxyClient.java
Index: ProxyClient.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ProxyClient.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ProxyClient.java 4 May 2004 21:24:51 - 1.4
+++ ProxyClient.java 20 Dec 2004 11:39:04 - 1.5
@@ -179,10 +179,10 @@
*/
public ConnectResponse connect() throws IOException, HttpException {
-if (!getHostConfiguration().isProxySet()) {
+if (getHostConfiguration().getProxyHost() == null) {
throw new IllegalStateException(proxy host must be configured);
}
-if (!getHostConfiguration().isHostSet()) {
+if (getHostConfiguration().getHost() == null) {
throw new IllegalStateException(destination host must be
configured);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: new sandbox projects
In case someone missed the thread on general here is a re-post as Brett suggested... Thanks for the positive feedback so far. BTW: How far is the SVN migration? cheers -- Torsten Torsten Curdt wrote: Hey, folks! Over at cocoon we have some code that might be worth sharing on jakarta commons. So I was wondering if the sandbox is open to any committer or only to jakarta committers? (which I am not) I heard different stories... I factored out our javaflow (java continuations) implementation and a java compiler interface (jci) featuring a compiling classloader. Any opinions on hosting that at jakarta commons? Or should we keep that stuff under our umbrella? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestConnectionPersistence.java
olegk 2004/12/20 03:42:30
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
httpclient/src/test/org/apache/commons/httpclient
TestConnectionPersistence.java
Log:
PR #32333 (Connection not closed after Connection: close request)
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Revision ChangesPath
1.221 +13 -8
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java
Index: HttpMethodBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.220
retrieving revision 1.221
diff -u -r1.220 -r1.221
--- HttpMethodBase.java 9 Nov 2004 19:25:42 - 1.220
+++ HttpMethodBase.java 20 Dec 2004 11:42:30 - 1.221
@@ -903,17 +903,22 @@
if (connectionHeader == null) {
connectionHeader = responseHeaders.getFirstHeader(connection);
}
+// In case the response does not contain any explict connection
+// directives, check whether the request does
+if (connectionHeader == null) {
+connectionHeader = requestHeaders.getFirstHeader(connection);
+}
if (connectionHeader != null) {
if (connectionHeader.getValue().equalsIgnoreCase(close)) {
if (LOG.isDebugEnabled()) {
-LOG.debug(Should close connection in response to
-+ connectionHeader.toExternalForm());
+LOG.debug(Should close connection in response to
directive:
++ connectionHeader.getValue());
}
return true;
} else if
(connectionHeader.getValue().equalsIgnoreCase(keep-alive)) {
if (LOG.isDebugEnabled()) {
-LOG.debug(Should NOT close connection in response to
-+ connectionHeader.toExternalForm());
+LOG.debug(Should NOT close connection in response to
directive:
++ connectionHeader.getValue());
}
return false;
} else {
1.2 +46 -4
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestConnectionPersistence.java
Index: TestConnectionPersistence.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestConnectionPersistence.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestConnectionPersistence.java7 Nov 2004 12:31:42 - 1.1
+++ TestConnectionPersistence.java20 Dec 2004 11:42:30 - 1.2
@@ -31,6 +31,10 @@
import org.apache.commons.httpclient.methods.PostMethod;
import org.apache.commons.httpclient.methods.StringRequestEntity;
+import org.apache.commons.httpclient.server.HttpRequestHandler;
+import org.apache.commons.httpclient.server.SimpleHttpServerConnection;
+import org.apache.commons.httpclient.server.SimpleRequest;
+import org.apache.commons.httpclient.server.SimpleResponse;
import junit.framework.Test;
import junit.framework.TestSuite;
@@ -171,6 +175,44 @@
httppost.releaseConnection();
}
assertTrue(connman.getConection().isOpen());
+}
+
+public void testRequestConnClose() throws Exception {
+this.server.setRequestHandler(new HttpRequestHandler() {
+
+public boolean processRequest(
+final SimpleHttpServerConnection conn,
+final SimpleRequest request) throws IOException {
+
+// Make sure the request if fully consumed
+request.getBodyBytes();
+
+SimpleResponse response = new SimpleResponse();
+response.setStatusLine(HttpVersion.HTTP_1_1,
HttpStatus.SC_OK);
+response.setBodyString(stuff back);
+
+conn.setKeepAlive(true);
+conn.writeResponse(response);
+
+return true;
+}
+
+});
+
+AccessibleHttpConnectionManager connman = new
AccessibleHttpConnectionManager();
+
+this.client.getParams().setVersion(HttpVersion.HTTP_1_0);
+this.client.setHttpConnectionManager(connman);
+
+PostMethod httppost = new PostMethod(/test/);
+httppost.setRequestHeader(Connection, close);
+httppost.setRequestEntity(new StringRequestEntity(stuff));
+try {
+
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient DefaultHttpMethodRetryHandler.java
olegk 2004/12/20 03:47:46
Modified:httpclient/src/java/org/apache/commons/httpclient
DefaultHttpMethodRetryHandler.java
Log:
PR #32558 (DefaultMethodRetryHandler bug)
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Revision ChangesPath
1.3 +4 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/DefaultHttpMethodRetryHandler.java
Index: DefaultHttpMethodRetryHandler.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/DefaultHttpMethodRetryHandler.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DefaultHttpMethodRetryHandler.java18 Sep 2004 11:34:12 -
1.2
+++ DefaultHttpMethodRetryHandler.java20 Dec 2004 11:47:46 -
1.3
@@ -86,7 +86,7 @@
if (exception == null) {
throw new IllegalArgumentException(Exception parameter may not
be null);
}
-if (executionCount = this.retryCount) {
+if (executionCount this.retryCount) {
// Do not retry if over max retry count
return false;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpState.java
olegk 2004/12/20 03:50:55
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpState.java
Log:
PR #32409 (HttpState should have methods for clearing all cookies and
credentials)
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Revision ChangesPath
1.38 +34 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpState.java
Index: HttpState.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpState.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- HttpState.java22 Sep 2004 23:36:10 - 1.37
+++ HttpState.java20 Dec 2004 11:50:54 - 1.38
@@ -592,4 +592,34 @@
}
return sbResult.toString();
}
+
+/**
+ * Clears all credentials.
+ */
+public void clearCredentials() {
+this.credMap.clear();
+}
+
+/**
+ * Clears all proxy credentials.
+ */
+public void clearProxyCredentials() {
+this.proxyCred.clear();
+}
+
+/**
+ * Clears all cookies.
+ */
+public void clearCookies() {
+this.cookies.clear();
+}
+
+/**
+ * Clears the state information (all cookies, credentials and proxy
credentials).
+ */
+public void clear() {
+clearCookies();
+clearCredentials();
+clearProxyCredentials();
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient release_notes.txt
olegk 2004/12/20 03:52:53 Modified:httpclient release_notes.txt Log: PR #32333 PR #32558 PR #32409 Revision ChangesPath 1.44 +11 -0 jakarta-commons/httpclient/release_notes.txt Index: release_notes.txt === RCS file: /home/cvs/jakarta-commons/httpclient/release_notes.txt,v retrieving revision 1.43 retrieving revision 1.44 diff -u -r1.43 -r1.44 --- release_notes.txt 19 Dec 2004 16:57:23 - 1.43 +++ release_notes.txt 20 Dec 2004 11:52:53 - 1.44 @@ -1,4 +1,15 @@ Changes since Beta 1: + + * 32409 - HttpState now has new methods for clearing all cookies and credentials. + Contributed by Oleg Kalnichevski olegk at apache.org + + * 32558 - Fixed retry count bug in DefaultMethodRetryHandler + Contributed by Oleg Kalnichevski olegk at apache.org + + * 32333 - Connection is now closed upon Connection: close request, + if the server does not include an explicit connection + directive in the response. + Contributed by Oleg Kalnichevski olegk at apache.org * 32765 - Fixed NullPointerException in HostConfiguration.setHost(Sting) Contributed by Stuart Herring apache -at- stuartherring.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new sandbox projects
was offline for a few hours ...you guys are quick :o) Thanks for granting the karma, Craig. Although I'd like to commit the stuff right away it probably makes sense to wait util the switch to svn is done. Or what do you guys reckon? cheers -- Torsten In case someone missed the thread on general here is a re-post as Brett suggested... Thanks for the positive feedback so far. BTW: How far is the SVN migration? cheers -- Torsten Torsten Curdt wrote: Hey, folks! Over at cocoon we have some code that might be worth sharing on jakarta commons. So I was wondering if the sandbox is open to any committer or only to jakarta committers? (which I am not) I heard different stories... I factored out our javaflow (java continuations) implementation and a java compiler interface (jci) featuring a compiling classloader. Any opinions on hosting that at jakarta commons? Or should we keep that stuff under our umbrella? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new sandbox projects
i'd say go for it now :) -- dims On Mon, 20 Dec 2004 13:00:41 +0100, Torsten Curdt [EMAIL PROTECTED] wrote: was offline for a few hours ...you guys are quick :o) Thanks for granting the karma, Craig. Although I'd like to commit the stuff right away it probably makes sense to wait util the switch to svn is done. Or what do you guys reckon? cheers -- Torsten In case someone missed the thread on general here is a re-post as Brett suggested... Thanks for the positive feedback so far. BTW: How far is the SVN migration? cheers -- Torsten Torsten Curdt wrote: Hey, folks! Over at cocoon we have some code that might be worth sharing on jakarta commons. So I was wondering if the sandbox is open to any committer or only to jakarta committers? (which I am not) I heard different stories... I factored out our javaflow (java continuations) implementation and a java compiler interface (jci) featuring a compiling classloader. Any opinions on hosting that at jakarta commons? Or should we keep that stuff under our umbrella? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26659] - [lang] add method to DateUtils to get the distance between 2 dates
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26659. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26659 --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 13:27 --- The variableDistance handling is a bit of a worry. Increasing by one until we equal that point. Working out difference between two months separated by 400 years will take quite a while. I agree this can be a problem, but I'm sure it can be done more efficiently. If there is a chance that this code gets accepted, I'll submit a new patch with a faster algorithm. I could see this on a CalendarUtils, or DurationCalendarUtils, but I'm not convinced of the need for it. I use it very frequently to determine the age (in years) of a person when only his/her birthdate is available (for adults: this is expressed in years, for young children this is expressed in months en for babies this is expressed in weeks). the functionality for Month/Year seems very open to user interpretation. Exactly how many years are between 1st Sept 1980 and 1st Mar 1981? 1, 0.5 or 0? The javadoc should make sure there is only 1 way to interpret this functionality. Perhaps the suggested javadoc can be rewritten to avoid these questions. regards, Maarten -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new sandbox projects
Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am 20.12.04 12:42:26: In case someone missed the thread on general here is a re-post as Brett suggested... Thanks for the positive feedback so far. BTW: How far is the SVN migration? cheers -- Torsten Torsten Curdt wrote: Hey, folks! Over at cocoon we have some code that might be worth sharing on jakarta commons. So I was wondering if the sandbox is open to any committer or only to jakarta committers? (which I am not) I heard different stories... I factored out our javaflow (java continuations) implementation and a java compiler interface (jci) featuring a compiling classloader. This sounds very interesting! Would be glad to see it in the commons sandbox. Any opinions on hosting that at jakarta commons? Or should we keep that stuff under our umbrella? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Svn migration - subclipse, scheduling, binaries
So, three issues to know about re: svn: 0. Subclipse: If you use Subclipse - know tha the test repository uses a self-signed cert, you may need to hit the test repository with svn command-line and permanently accept the cert from my machine before you can use subclipse. I was able to checkout the current from Subclipse, so it does honor svn:externals. 1. Scheduling: If we go forward with this migration, we need to do this when everyone is available both so we can migrate successfully and so that we can have a proper 72 hour vote window. Doing this right before a holiday weekend is not the best idea, and I think we could use some more time to work out other issues like security and site publishing. The earliest I can see is a vote thread next week starting on the 27th or 28th, ending on the 30th. That leaves us with the posssibility of a five to six hour migration on new years' eve or day which might work out well. Was thinking this qualifies again as a release majority vote. (To address Torsten's question of waiting to commit until the SVN migration is done, I'd say don't wait for this. Adding another component doesn't create any more work, and I know I wouldn't want to slow down that work at all. Plus, this migration isn't a guaranteed thing.) 2. Binary Files: If you keep jars or other binaries in CVS and these binaries were not added with -kb, the cvs2svn process may have mangled you binaries. I don't think this is going to be a big problem, as most of the well used commons components do not version jars. Just be aware of this issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-177) In JellyServlet, the procedure used to determine the script's location is too simplistic
[
http://nagoya.apache.org/jira/browse/JELLY-177?page=comments#action_56890 ]
Denis Robert commented on JELLY-177:
Don't thank me, thank the Freemarker developers, since the technique was lifted
from them.
In JellyServlet, the procedure used to determine the script's location is too
simplistic
Key: JELLY-177
URL: http://nagoya.apache.org/jira/browse/JELLY-177
Project: jelly
Type: Bug
Components: core / taglib.core
Versions: 1.0
Environment: Servlet, 1.0RC1
Reporter: Denis Robert
Priority: Minor
In JellyServlet, the procedure used to determine the script's location is too
simplistic; it misses simple cases like the a *.jelly servlet-mapping.
I suggest replacing the getScript method with something like (taken in part
from the Freemarker servlet):
protected URL getScript(HttpServletRequest req)
throws MalformedURLException {
String scriptUrl = null;
String includedPath = (String)
req.getAttribute(javax.servlet.include.servlet_path);
if (includedPath != null) { //This is the result of a
RequestDispatcher include...
String includedPathInfo = (String)
req.getAttribute(javax.servlet.include.path_info);
if (includedPathInfo != null) {
scriptUrl = includedPathInfo;
} else {
scriptUrl = includedPath;
}
} else {
scriptUrl = req.getParameter(script);
if (scriptUrl == null) {
scriptUrl = req.getPathInfo();
}
if (scriptUrl == null) {
scriptUrl = req.getServletPath();
}
}
URL url = getServletContext().getResource(scriptUrl);
if (url == null) {
throw new IllegalArgumentException(Invalid script url:
+ scriptUrl);
}
return url;
}
--
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]
[jira] Commented: (JELLY-177) In JellyServlet, the procedure used to determine the script's location is too simplistic
[
http://nagoya.apache.org/jira/browse/JELLY-177?page=comments#action_56894 ]
Denis Robert commented on JELLY-177:
So as to properly render unto Gaius Julius, here's the reference to the
complete source of the freemarker servlet I used as source:
http://cvs.sourceforge.net/viewcvs.py/freemarker/freemarker/src/freemarker/ext/servlet/FreemarkerServlet.java
In JellyServlet, the procedure used to determine the script's location is too
simplistic
Key: JELLY-177
URL: http://nagoya.apache.org/jira/browse/JELLY-177
Project: jelly
Type: Bug
Components: core / taglib.core
Versions: 1.0
Environment: Servlet, 1.0RC1
Reporter: Denis Robert
Priority: Minor
In JellyServlet, the procedure used to determine the script's location is too
simplistic; it misses simple cases like the a *.jelly servlet-mapping.
I suggest replacing the getScript method with something like (taken in part
from the Freemarker servlet):
protected URL getScript(HttpServletRequest req)
throws MalformedURLException {
String scriptUrl = null;
String includedPath = (String)
req.getAttribute(javax.servlet.include.servlet_path);
if (includedPath != null) { //This is the result of a
RequestDispatcher include...
String includedPathInfo = (String)
req.getAttribute(javax.servlet.include.path_info);
if (includedPathInfo != null) {
scriptUrl = includedPathInfo;
} else {
scriptUrl = includedPath;
}
} else {
scriptUrl = req.getParameter(script);
if (scriptUrl == null) {
scriptUrl = req.getPathInfo();
}
if (scriptUrl == null) {
scriptUrl = req.getServletPath();
}
}
URL url = getServletContext().getResource(scriptUrl);
if (url == null) {
throw new IllegalArgumentException(Invalid script url:
+ scriptUrl);
}
return url;
}
--
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: Jakarta Commons Structure rehashed
Henning P. Schmiedehausen wrote: Checking out the whole trunk is not the norm. Folks, this is not CVS. You are not bound to a rigid structure as with CVS. But you _want_ to be able to check out multiple projects side by side. Because some of the depend on each other (or on the commons-site module). A major nit that I have to pick is the growing number of project building with maven and the inability of _many_ maven plugins like the changelog, dev or file activity lists to _use_ subversion. This is actual information that we lose from the project sites if we go subversion. Sure Henn, but IMHO, Jakarta Commons has always been a real use case testing ground for Maven, It will not be long before those plugins are migrated if Commons goes SVN, many Maven developers are also Commons developers. -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]
Re: [logging] ECL: Log interface vs. abstract class
Whether you choose Log to be an interface or an abstract class does not really matter. The point I am trying to convey is that jcl will not be able to abstract more than one logging API. Although desirable, abstraction is not technically feasible. At 12:59 AM 12/20/2004, Matt Sgarlata wrote: I think this added functionality that is coming in Log4J demonstrates another reason to leave Log as an interface rather than converting it to an abstract class. Assuming we make LocalizedLog an interface that extends Log, when Log4J introduces support for their new domain logging (if you will), JCL can just introduce a DomainLog interface that extends Log and has nothing to do with LocalizedLog. A logging implementation may or may not support internationalization, and may or may not support this new domain concept. In this way, we can have Log implementations describe which features they support by implementing certain interfaces and not others. -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[HttpClient] Re: SVN awareness
Folks, I took a quick look at the test SVN repository. All looks sane to me. I checked out HttpClient 3.0 (trunk) and HttpClient 2.0.x (HTTPCLIENT_2_0_BRANCH) snapshots. They seems identical to the CVS content of two days ago. As far as I am concerned we should be good to take the plunge Cheers, Oleg On Sun, Dec 19, 2004 at 07:33:42PM -0500, Henri Yandell wrote: You guys can tend to get a big ignored out here on your own list. Wanted to make sure that you're aware of the plans to move Commons from CVS over to SVN soon as it'll affect you too. Once in SVN, we can easily promote you out when the time comes to be a Jakarta sub-project. Tim O'Brien and Martin Cooper are handling the migration. Hen - 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: Svn migration - subclipse, scheduling, binaries
On Mon, 20 Dec 2004 08:02:14 -0500, Tim O'Brien [EMAIL PROTECTED] wrote: 1. Scheduling: If we go forward with this migration, we need to do this when everyone is available both so we can migrate successfully and so that we can have a proper 72 hour vote window. Doing this right before a holiday weekend is not the best idea, and I think we could use some more time to work out other issues like security and site publishing. Craig's nightlies. Gump. The earliest I can see is a vote thread next week starting on the 27th or 28th, ending on the 30th. That leaves us with the posssibility of a five to six hour migration on new years' eve or day which might work out So either a drunk infra team or a hungover one Bear in mind, this would just be the test migration on asf hardware, and we could then leave it open for a set time period for people to play with. well. Was thinking this qualifies again as a release majority vote. At first I thought that it should be consensus, ie) no -1's, but I'm seeing your thinking now. We have two types of -1; firstly there's a -1 because I like CVS and want to stay there; secondly there's a -1 because I can't use SVN in the way I need to. The former should be treated as a majority vote, while the latter should be treated as a consensus vote. So I'm +1 to a release majority vote with the acceptance that we're not going to leave anyone behind. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Svn migration - subclipse, scheduling, binaries
Yes, the intent isn't to leave anyone behind. I just noticed that infrastructure changes don't have a section in the guideline proposal: http://jakarta.apache.org/site/proposal.html#decisions/items From: Henri Yandell well. Was thinking this qualifies again as a release majority vote. At first I thought that it should be consensus, ie) no -1's, but I'm seeing your thinking now. We have two types of -1; firstly there's a -1 because I like CVS and want to stay there; secondly there's a -1 because I can't use SVN in the way I need to. The former should be treated as a majority vote, while the latter should be treated as a consensus vote. So I'm +1 to a release majority vote with the acceptance that we're not going to leave anyone behind. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] ECL: Log interface vs. abstract class
Aren't you assuming that things can be placed in nice orthogonal and independent boxes? Let X and Y be logging APIs that JCL attempts to abstract. Let IX be an interface unique to API X. Let JCL-IX be JCL's mirror of interface IX. If the end-user sprinkles her code with JCL-IX calls, there are two possible branches: 1) API X is available, and there no unintended or unforeseen interactions between JCL-IX and IX then everything will be fine. If there are unintended or unforeseen interactions, then this usually takes a long time to discover, let alone to repair. In the mean time, your users will be pulling out their hair in frustration. 2) API X is unavailable. In that case, JCL might may attempt to replace the functionality offered by API X with a NOP implementation or a simple alternative. However, if API X is considered core functionality, then the promise of abstraction cannot be not fulfilled without duplicating the code found in API X. Writing a good facade is much harder than what people realize. In the case of competing and divergent APIs, it is an impossible one. At 03:18 PM 12/20/2004, Matt Sgarlata wrote: I disagree; different logging APIs can be supported with the addition of new interfaces. Using this strategy, the set of interfaces that a given Log implementation implements define the set of features which that logging implementation supports. Ceki Gülcü wrote: Whether you choose Log to be an interface or an abstract class does not really matter. The point I am trying to convey is that jcl will not be able to abstract more than one logging API. Although desirable, abstraction is not technically feasible. -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking GenericLockManager.java
ozeigermann2004/12/20 07:23:56
Modified:transaction/src/java/org/apache/commons/transaction/locking
GenericLockManager.java
Log:
Some fixes around global timeouts
Revision ChangesPath
1.9 +22 -10
jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
Index: GenericLockManager.java
===
RCS file:
/home/cvs/jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking/GenericLockManager.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- GenericLockManager.java 19 Dec 2004 10:54:52 - 1.8
+++ GenericLockManager.java 20 Dec 2004 15:23:56 - 1.9
@@ -269,11 +269,9 @@
* @see LockManager#releaseAll(Object)
*/
public void releaseAll(Object ownerId) {
-// reset time out status for this owner
-if (timedOutOwners.remove(ownerId)) {
-// short cut if we were timed out there are no more locks
-return;
-}
+// XXX even if we are timed out we can still have
+// locks acquired because we might have been waiting for one
+// while we were set to timed out
Set locks = (Set) globalOwners.get(ownerId);
if (locks != null) {
synchronized (locks) {
@@ -284,6 +282,8 @@
}
}
}
+// reset time out status for this owner
+timedOutOwners.remove(ownerId);
}
/**
@@ -373,7 +373,6 @@
if (timeout now) {
releaseAll(ownerId);
timedOutOwners.add(ownerId);
-it.remove();
released = true;
}
}
@@ -381,6 +380,18 @@
return released;
}
+protected boolean timeOut(Object ownerId) {
+Long timeout = (Long)globalTimeouts.get(ownerId);
+long now = System.currentTimeMillis();
+if (timeout != null timeout.longValue() now) {
+releaseAll(ownerId);
+timedOutOwners.add(ownerId);
+return true;
+} else {
+return false;
+}
+}
+
protected long getNextGlobalConflictTimeout(Set conflicts) {
long minTimeout = -1;
long now = System.currentTimeMillis();
@@ -443,6 +454,7 @@
}
protected void timeoutCheck(Object ownerId) throws LockException {
+timeOut(ownerId);
if (timedOutOwners.contains(ownerId)) {
throw new LockException(
All locks of owner
-
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/12/20 08:13:42
Modified:fileupload/src/java/org/apache/commons/fileupload
FileUploadBase.java
Log:
Fix typos in exception messages.
Revision ChangesPath
1.15 +3 -3
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.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- FileUploadBase.java 12 Dec 2004 17:21:41 - 1.14
+++ FileUploadBase.java 20 Dec 2004 16:13:42 - 1.15
@@ -301,13 +301,13 @@
if (requestSize == -1) {
throw new UnknownSizeException(
-the request was rejected because it's size is unknown);
+the request was rejected because its size is unknown);
}
if (sizeMax = 0 requestSize sizeMax) {
throw new SizeLimitExceededException(
the request was rejected because
-+ it's size exceeds allowed range);
++ its size exceeds allowed range);
}
try {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] ECL: Log interface vs. abstract class
In my last message, I failed to emphasize the brittleness of the break into interfaces hypothesis. Even if at a high-level of abstraction two APIs perform the same task, this does not mean that they can be abstracted away by a thin facade (or bridge). For example, all the attempts made at bridging X.25 and TCP/IP, both well defined and stable protocols, have failed miserably, even if both stacks supposedly fit into layers 1-4 of the 7 layer OSI network model. The Logging problem has not been completely solved yet. Log4j will continue to evolve at a quick pace during the coming years. I believe that trying to foresee, let alone abstract this evolution is an iffy proposal at best. Some will say that Logging is no where comparable in complexity of a network protocol. Some will say that JSR 47 cannot be ignored since it is part of the JDK. Some will say that they absolutely require API independence to satisfy their clients. I realize that asking you to take my word for it is too big a leap of faith. Consequently, and as in the past, I fully expect my repeated warnings to be ignored. Coming back to your example, you are assuming that localization support will be done by introducing new member methods in the logger interface/ abstract class. However, this will not necessarily be the case. As Curt Arnold mentioned earlier, localization support can be added by adding new semantics to the existing methods. Of course, another logging API may choose another path where localization support is done through new specialized methods. Now, JCL's task is two abstract these two different approaches. Which even in the case of this quasi-trivial example looks extremely hard to get right. Hence my observation that in the case of evolving and divergent APIs, abstraction although desirable, is not feasible. The interface vs. abstract class debate only makes sense in the case of APIs submitting to a common standard. In that case, the common standard should be implemented in terms of interfaces instead of abstract classes in order too leave enough wiggling room for willing implementations of the standard. However, even if you are right, since there is no common standard, the debate interface vs. abstract class is moot. My personal attempts at a future-aware standard showed how difficult the abstraction task was. (I was only concerned with abstracting log4j's own interfaces.) See also http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/ugli/ At 04:41 PM 12/20/2004, Matt Sgarlata wrote: Let's make this more concrete by examining the problem currently presented to us: localization of logging messages (this would be API-X in your example). If JCL adds a new LocalizedLog interface (JCL-IX), calls to the localized log will work as expected when the underlying logging implementation supports localization (branch 1 in your post). If localization is not available, the unresolved message keys are supplied to the underlying logging implementation (branch 2). This seems perfectly reasonable to me. If the underlying logging implementation doesn't support internationalization, then the log messages aren't internationalized. Of course, if you've gone to all the trouble of making your message internationalized, I would expect this would narrow down the field of logging implementations you chose from :) I hope I'm not being argumentative or dense. I'm really just trying to make a case for using interfaces rather than abstract classes. My point earlier was simply that the more features are supported by JCL, the harder it will be to squeeze them into some type of abstract class hierarchy and the more compelling an interface-based abstraction layer is. Matt -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32782] New: - Feature Request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32782. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32782 Summary: Feature Request Product: Commons Version: 1.0 Final Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: File Upload AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] As per an email discussion with Martin Cooper, I would like to suggest that when a FileUpload request fails because the file size exceeded the maximum size, that the maximum size be stated in the error message. This would help the user since he would now know the maximum size; otherwise, he won't know how small a file will fit within the maximum size, just that he had exceeded an unspecified limit. It might be even more helpful if the message stated the name and size of the user's file that had violated the maximum size. For instance: The file you just tried to upload, foo.jpg, was 2,000,000 bytes in size which exceeds the maximum size supported by this server, 500,000 bytes. This would help the user determine which file was the offender and how much smaller it needed to be to satisfy the server's limits. Of course, if the user was trying to upload several files, it is the aggregate size of all of the files that violates the maximum size. In that case, perhaps all the names and sizes of the files involved should be specified, as should the maximum size allowed by that server. This starts to be an unwieldy message but it would be very useful nonetheless, at least in my view, and would enable even a very non-technical user to get out of trouble by themselves without involving the server's technical staff. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpConnection.java HttpVersion.java
olegk 2004/12/20 11:52:50
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpConnection.java HttpVersion.java
Log:
Javadoc fixes
Contributed by Ernst de Haan ernst.dehaan at nl.wanadoo.com and Oleg
Kalnichevski
Revision ChangesPath
1.104 +19 -7
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java
Index: HttpConnection.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
retrieving revision 1.103
retrieving revision 1.104
diff -u -r1.103 -r1.104
--- HttpConnection.java 3 Nov 2004 19:37:10 - 1.103
+++ HttpConnection.java 20 Dec 2004 19:52:50 - 1.104
@@ -1162,7 +1162,12 @@
}
/**
- * Release the connection.
+ * Releases the connection. If the connection is locked or does not have
a connection
+ * manager associated with it, this method has no effect. Note that it
is completely safe
+ * to call this method multiple times.
+ *
+ * @see #isLocked()
+ * @see #setLocked(boolean)
*/
public void releaseConnection() {
LOG.trace(enter HttpConnection.releaseConnection());
@@ -1177,7 +1182,10 @@
}
/**
- * @return
+ * Tests if the connection is locked. Locked connections cannot be
released.
+ * An attempt to release a locked connection will have no effect.
+ *
+ * @return tttrue/tt if the connection is locked, ttfalse/tt
otherwise.
*
* @since 3.0
*/
@@ -1186,7 +1194,11 @@
}
/**
- * @param locked
+ * Locks or unlocks the connection. Locked connections cannot be
released.
+ * An attempt to release a locked connection will have no effect.
+ *
+ * @param locked tttrue/tt to lock the connection, ttfalse/tt to
unlock
+ * the connection.
*
* @since 3.0
*/
1.6 +9 -9
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpVersion.java
Index: HttpVersion.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpVersion.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- HttpVersion.java 13 May 2004 04:03:25 - 1.5
+++ HttpVersion.java 20 Dec 2004 19:52:50 - 1.6
@@ -32,17 +32,17 @@
/**
* pHTTP version, as specified in RFC 2616./p
* p
- * HTTP uses a ltmajorgt.ltminorgt numbering scheme to indicate
versions
- * of the protocol. The protocol versioning policy is intended to allow
- * the sender to indicate the format of a message and its capacity for
+ * HTTP uses a lt;majorgt;.lt;minorgt; numbering scheme to indicate
+ * versions of the protocol. The protocol versioning policy is intended to
+ * allow the sender to indicate the format of a message and its capacity for
* understanding further HTTP communication, rather than the features
* obtained via that communication. No change is made to the version
* number for the addition of message components which do not affect
* communication behavior or which only add to extensible field values.
- * The ltminorgt number is incremented when the changes made to the
+ * The lt;minorgt; number is incremented when the changes made to the
* protocol add features which do not change the general message parsing
* algorithm, but which may add to the message semantics and imply
- * additional capabilities of the sender. The ltmajorgt number is
+ * additional capabilities of the sender. The lt;majorgt; number is
* incremented when the format of a message within the protocol is
* changed. See RFC 2145 [36] for a fuller explanation.
* /p
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] ECL: pluggable message resolution
On 18 Dec 2004, at 20:18, Richard Sitze wrote:
[forgive me for changing the subject, I'm trying to take steps to try
to
help us focus on separate issues]
Noel J. Bergman [EMAIL PROTECTED] wrote on 12/17/2004 09:10:34 PM:
Richard Sitze wrote:
As a real example, the axis community uses globalized messages.
A lot of products do, as I see on a regular basis, so I definitely
support
your interest in this feature.
However, I view logging as separate from content generation. I'd like
to
see the mechanism pluggable. That could be done by providing a
message
factory to the logging layer, so that it does the lookup rather than
your
example:
log.error(Message.getMessage(MSGID, new String { arg1, ..., argN
}));
Doing so would still permit your facade:
log.error(this.getClass(), thisMethodName, MSGID, new String
{...});
but the factory that the logger uses to construct the message would be
pluggable and distinct from the role of bridging to an underlying log
mechanism.
I would claim that for a first shot let's keep this simple. It is
pluggable in that you may plug in your own Log implementation that does
what you need.
That aside, how do you propose to reconcile this pluggable mechanism
with the underlying logger that DOES accept MSGID and Object[]
directly?
I'm of the opinion that IF a reasonable proposal can be produced, then
it
can be introduced at a later point in time [evolution].
it seems to me that pluggability arises as a natural consequence.
one day (i'm sure) it will be possible to create thin bridges to
i18nable logging systems. AFAIK none of the generations of logging
systems which JCL currently targets can be bridged in such a manner.
it seems to me that the most elegant approach would be to allow (and
encourage) native thin bridges (to i18nable logging systems) but to
also build an implementation which would adapts from the enterprise
interfaces to base JCL. it would make sense for this implementation to
be pluggable (since the base rendering should ideally be minimally
sufficient) so that others can easily substitute a more sophisticated
rendering/i18n implementation.
opinions?
And I'd like to see a Java 5 versiion of this interface that takes
advantage
of variable argument lists, rather than the String[].
Unlikely in the JCL.
sad but true
it would be quite a big step to say that the enterprise portion is for
java 5 only. i wouldn't actively object provided that active support
for this measure was adequately demonstrated.
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Problem with common DBUtil Bean
I have
Table with these column name and types
INDEX_ID NUMBER,
DOCUMENT_TYPE VARCHAR2(3),
DATE_ENTERED DATE,
SELECT index_id, document_type, date_entered from MyTable;
and database has required data.
public MyBean class {
public long index_ID;
public String document_Type ;
public java.sql.Date date_Entered ;
public MyBean(){
super();
}
public long getIndex_ID() {
return index_ID;
}
public void setIndex_ID(long index_ID) {
this.index_ID = index_ID;
}
public java.sql.Date getDate_Entered() {
return this.date_Entered;
}
public void setDate_Entered(java.sql.Date date_Entered) {
this.date_Entered = date_Entered;
}
public String getDocument_Type() {
return document_Type;
}
public void setDocument_Type(String document_Type) {
this.document_Type = document_Type;
}
}
public SomeTestCalss {
public void someTestmethod(){
// some how got connetion/ result set statement this is tested ok
callst.execute();
//Casting the returned parameter, OracleTypes.CURSOR to a JDBC ResultSet
rset = (ResultSet)callst.getObject(1);
rset = StringTrimmedResultSet.wrap(rset);
SqlNullCheckedResultSet sqlncrswrap = new SqlNullCheckedResultSet(rset);
sqlncrswrap.setNullDate(null) ;
sqlncrswrap.setNullInt(0) ;
sqlncrswrap.setNullString();
rset = ProxyFactory.instance().createResultSet(sqlncrswrap);
// Pass wrapped ResultSet to processor
results = BasicRowProcessor.instance().toBeanList(rset,MyBean.class);
Iterator iter = mciResults.iterator();
while (iter.hasNext()) {
MyBean mb = (MyBean) iter.next();
System.out.println(Index ID+mb.getIndex_ID());
System.out.println(Document Type+mb.getDocument_Type());
System.out.println(date_entered +mb.getDate_Entered());
}
}
}
output looks like this
Index ID 0
Document Type MYDOCTYPE
Date entered null
Why Index ID for all rows is 0 and Date entered for all rows is null while I
can get Document Type value correctly.
-
Do you Yahoo!?
Send a seasonal email greeting and help others. Do good.
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 18 Dec 2004, at 18:24, Richard Sitze wrote: Curt Arnold [EMAIL PROTECTED] wrote on 12/16/2004 11:13:25 PM: On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote: snip Some of advantages of this approach: no API change is necessary, diagnostic messages are still trivial to add and fast to process, each appender may have a different locale, localization has no cost for discarded messages, generic language (typically english) messages are available for messages that have not been translated (and likely most diagnostic messages would not be), does not require customized readers. It is reasonable to attempt to standardize a general enablement for I18N on the API level. Sure, you can roll your own. Sure, each component could roll it's own... Sure, we can duplicate this endlessly. Let's standardize this now. As long as this effort is only trying to define an abstraction layer to unify existing practice and implementations, I'm okay with it. If it is trying to standardize an API before implementations are available and without consultation with major implementations like the Logging Services Project, then I would be concerned. IIRC we're never really gone for official consultations here at apache (or at least the bits i've been involved with): too much committee, too little community. i alerted ceki (who i've know and respected for too many years even though we don't always agree) soon after i discovered this thread and hoped that other interested folks from the logging project. jakarta commons has a slightly different focus and expertise. we're more interested in bricks (small, compact reusable components with minimal dependencies) than logging systems. the extensions proposed by richard would allow components with enhanced logging requirements (such as i18nable messages) to be added to the commons. so, in many ways it doesn't matter whether existing logging systems offer these capabilities or not: what matters is whether there is a need for this kind of enhanced logging for the kind of bricks built by the jakarta commons. it's good people that logging experts have shown up to the party but (so long as a need for this exists), the party would have happened anyway. From reading the thread, I'm not sure what the effort is trying to do. We ARE assuming that maintaining SOME SIGNIFICANT compatibility with the existing JCL is of paramount importance. We are NOT trying to standardize on some other API within the industry, but rather to evolve an existing standard with new function. The API's are based *functionally* on JSR-47 and other logging implementations. It's fair to say that there is more than a little experience being brought to bear on this effort within the Jakarta community. i think that this is one of the crucial matters which hasn't really been totally bottomed out. IMHO enterprise commons logging it is technically feasible to added as a compatible extension to JCL. however, the proposal breaks down a little into a number of independent requests: i18nable logs; improved support for JSR-47; better discover and so on. in addition, there are a few other issues which are related which have been itches for quite a period (including improved support for frameworks, support for more varied environments and better packaging for distributables). the question i pose is: are we trying for a JCL 2.0 which in my mind would be a compatible evolution of JCL 1.0 aiming to solve all the major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover and factoring) plus additional pluggable modules...? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 18 Dec 2004, at 20:52, Curt Arnold wrote: On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote: snip That a single log request can be rendered for more than one locale would either require having a localizable object passing through the logging dispatch system, being able to translate the log request at the appender or some other approach internal to the logging system. Constructing a message using resource bundles and passing a rendered message on to log4j logging would not accomplish that goal. We do not desire to pass on the rendered message, unless the underlying logger offers us no alternative. We desire to pass the messageID and parameters directly to the Logger, to be handled as it would. Again, I'm not sure what changes/problems you are arguing for? That is effectively issuing an architectural ultimatum to the logging implementations: be able to pass resource bundles and parameters through your processing pipeline or appear to be a second class implementation of Jakarta Commons Logging. (ceki - can't you keep your troops in line! ;) LOL! how the story has been rewritten in the last two years... we here in the commons are humble implementors of a simple (but yet too complex) thin (but too fat) bridging API. we are second class (we don't really provide any logging worth a damn): the logging system architects are the first class citizens. FWIW i have an idea that logging systems capable of supporting native thin wrapper implementations will actually be mostly used through the Log compatibility layer. If this is making architectural demands, it would be right to have the implementors feedback. though we are hoping not to make architectural demands, i think everyone here is glad to have your feedback. your points about the distinction between administrative and diagnostic logging interest me. it seems to me that diagnostic logging is less about the language that the log is written in and more about being able to correlate the message with the code that created the message. this suggests that knowledge of the key is much more critical than the message itself for diagnostic output. given a good key creation convention (org.apache.commons.bizarro[100], say). it might therefore be useful to be able to be able to render the key as part of the message (or even as the message). - 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/io/read TestReadContext.java
rdonkin 2004/12/20 14:04:53
Modified:betwixt/src/java/org/apache/commons/betwixt/io/read
ReadContext.java
betwixt/src/test/org/apache/commons/betwixt/io/read
TestReadContext.java
Log:
Fix for bug #32743. (Wouldn't you know it? Missed a unit test for that
method...)
Revision ChangesPath
1.10 +1 -1
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/read/ReadContext.java
Index: ReadContext.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/read/ReadContext.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ReadContext.java 6 Oct 2004 20:39:13 - 1.9
+++ ReadContext.java 20 Dec 2004 22:04:53 - 1.10
@@ -230,7 +230,7 @@
result = (String) mappedElement;
break;
}
- --i;
+ ++i;
}
return result;
}
1.3 +8 -1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io/read/TestReadContext.java
Index: TestReadContext.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io/read/TestReadContext.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestReadContext.java 13 Jun 2004 21:32:48 - 1.2
+++ TestReadContext.java 20 Dec 2004 22:04:53 - 1.3
@@ -94,6 +94,13 @@
assertEquals(No class, null, context.getLastMappedClass());
}
+public void testGetCurrentElement() throws Exception {
+ReadContext context = new ReadContext(new BindingConfiguration(),
new ReadConfiguration());
+context.pushElement(element);
+context.markClassMap(String.class);
+assertEquals(Current element: , element,
context.getCurrentElement());
+}
+
public void testLastMappedClassBottomClass() throws Exception
{
ReadContext context = new ReadContext(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32743] - [betwixt] Adding DEBUG to log4j.properties results in IndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32743. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32743 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 23:08 --- Commited fix. Thanks for the report. BTW if you do post any code again, please consider contributing a unit test (donating the code to the ASF) so that it can be added to the Betwixt unit tests. In this case, it was easy for me to create a test that demonstrated the problem, but it can be frustrating to have code that demonstrates a problem that cannot be used as a base for a unit test (since the copyright is held by another). Robert -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 18 Dec 2004, at 20:52, Curt Arnold wrote: On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote: snip We ARE assuming that maintaining SOME SIGNIFICANT compatibility with the existing JCL is of paramount importance. We are NOT trying to standardize on some other API within the industry, but rather to evolve an existing standard with new function. The API's are based *functionally* on JSR-47 and other logging implementations. It's fair to say that there is more than a little experience being brought to bear on this effort within the Jakarta community. Again, I'm coming into this late. Is there a requirements doc of some sort other than what was in this thread, have there been any votes, anything in CVS, any timeline? there was a vote but i think it was a little premature. certainly, there's been no pressure to conclude it and it seems to me that the present consensus is that more talk and thought is needed. commons appears to be in the process of migrating to subversion. i feel an urge to code but it'd be better to take a branch or three to further the discussion in code. so for the moment, i don't think we'll see any commits for a while yet. certainly, i wouldn't feel comfortable with any as yet. personally speaking, i think that refactoring the discovery process is a pre-requisite to firming up the design. i have seen too much discussion on that yet so maybe we're still a little way off... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32743] - [betwixt] Adding DEBUG to log4j.properties results in IndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32743. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32743 --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 23:19 --- I may be wrong but I believe it will occur with one of the unit tests. If not, I will gladly donate the code below to ASF as long as my name is removed from the test. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
At 11:03 PM 12/20/2004, robert burrell donkin wrote: (ceki - can't you keep your troops in line! ;) I really don't have any troops marching at my orders. Those who are affiliated with Logging Services do not necessarily listen to me anyhow, let alone take any orders. They are all independently minded people who express their minds freely. We are extremely lucky to have them. (It doesn't always work out so well in other projects.) LOL! how the story has been rewritten in the last two years... What I find fascinating is the extent to which political considerations seem to outweigh technical considerations. - robert -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 20 Dec 2004, at 22:21, Ceki Gülcü wrote: At 11:03 PM 12/20/2004, robert burrell donkin wrote: (ceki - can't you keep your troops in line! ;) I really don't have any troops marching at my orders. Those who are affiliated with Logging Services do not necessarily listen to me anyhow, let alone take any orders. They are all independently minded people who express their minds freely. We are extremely lucky to have them. (It doesn't always work out so well in other projects.) exactly (and that was the intended joke) LOL! how the story has been rewritten in the last two years... What I find fascinating is the extent to which political considerations seem to outweigh technical considerations. ISTM it hasn't really started out so political this time (or did i miss it...) we certainly have a different agenda here in the commons but IMO that has more to do with technical matters such as how to make bricks that can fit... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
David Graham wrote: --- Daniel Florey [EMAIL PROTECTED] wrote: BTW: Another advantage of this approach would be that imports would indicate which version of the component is in use. I had a lot of trouble to find out, which version of jdom was in use by some libraries as this was not indicated by the name of the jar. The version may be listed in the manifest file. This is really pushing the limits of my classloading knowledge, but doesn't the Manifest just say which version you need to run? If two incompatible versions are specified by two different JARs, then you're still up a creek, right? If I understand this correctly, all the Manifest can do is make your application puke on startup instead of puking at runtime. It doesn't solve the problem of running two versions of a class at the same time. David Daniel __ Do you Yahoo!? Jazz up your holiday email with celebrity designs. Learn more. http://celebrity.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: [proposal] avoiding jar version nightmares
Daniel Florey wrote: I think handling different versions of classes/jars at VM level would be a nice feature, but it would be very hard to implement nd to understand when it comes to reflection. Does this mean .NET doesn't have reflection? That's such a killer feature of Java; I can't believe they wouldn't have ported it to .NET. Any .NET developers out there that can tell us how .NET deals with reflection when you have multiple versions of the same class? Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Enterprise Common Logging... dare we say 2.0?
Robert, we've got some issues to work through and infrastructure wants to wait until at least next week. Don't delay anything on account of the svn migration. From what I see, the transition should be seemless - just a few hours downtime. So, commit away. Tim From: robert burrell donkin commons appears to be in the process of migrating to subversion. i feel an urge to code but it'd be better to take a branch or three to further the discussion in code. so for the moment, i don't think we'll see any commits for a while yet. certainly, i wouldn't feel comfortable with any as yet.
Re: AW: AW: [proposal] avoiding jar version nightmares
.Net does have reflection. Some even say it's somewhat more elegant than Java... I ain't goin' there :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Matt Sgarlata wrote: Daniel Florey wrote: I think handling different versions of classes/jars at VM level would be a nice feature, but it would be very hard to implement nd to understand when it comes to reflection. Does this mean .NET doesn't have reflection? That's such a killer feature of Java; I can't believe they wouldn't have ported it to .NET. Any .NET developers out there that can tell us how .NET deals with reflection when you have multiple versions of the same class? Matt - 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: [dbutils] Problem with common DBUtil Bean
First, you need to alias the column names in the sql to avoid having to
use the horrible underscore in your java method names:
select index_id as indexID, document_type as documentType, date_entered as
dateEntered from MyTable
DBUtils 1.0 didn't contain very intelligent column to bean property
mapping. Oracle's JDBC driver returns NUMBER columns as BigDecimal so
changing your indexID from a long to a BigDecimal should fix the problem.
However, working with longs is easier so I suggest you download the latest
nightly build of DBUtils. Since 1.0 was released we made the type mapping
a bit smarter so your long indexID should be populated correctly.
David
--- spframe live [EMAIL PROTECTED] wrote:
I have
Table with these column name and types
INDEX_ID NUMBER,
DOCUMENT_TYPE VARCHAR2(3),
DATE_ENTERED DATE,
SELECT index_id, document_type, date_entered from MyTable;
and database has required data.
public MyBean class {
public long index_ID;
public String document_Type ;
public java.sql.Date date_Entered ;
public MyBean(){
super();
}
public long getIndex_ID() {
return index_ID;
}
public void setIndex_ID(long index_ID) {
this.index_ID = index_ID;
}
public java.sql.Date getDate_Entered() {
return this.date_Entered;
}
public void setDate_Entered(java.sql.Date date_Entered) {
this.date_Entered = date_Entered;
}
public String getDocument_Type() {
return document_Type;
}
public void setDocument_Type(String document_Type) {
this.document_Type = document_Type;
}
}
public SomeTestCalss {
public void someTestmethod(){
// some how got connetion/ result set statement this is tested ok
callst.execute();
//Casting the returned parameter, OracleTypes.CURSOR to a JDBC
ResultSet
rset = (ResultSet)callst.getObject(1);
rset = StringTrimmedResultSet.wrap(rset);
SqlNullCheckedResultSet sqlncrswrap = new
SqlNullCheckedResultSet(rset);
sqlncrswrap.setNullDate(null) ;
sqlncrswrap.setNullInt(0) ;
sqlncrswrap.setNullString();
rset = ProxyFactory.instance().createResultSet(sqlncrswrap);
// Pass wrapped ResultSet to processor
results = BasicRowProcessor.instance().toBeanList(rset,MyBean.class);
Iterator iter = mciResults.iterator();
while (iter.hasNext()) {
MyBean mb = (MyBean) iter.next();
System.out.println(Index ID+mb.getIndex_ID());
System.out.println(Document Type+mb.getDocument_Type());
System.out.println(date_entered +mb.getDate_Entered());
}
}
}
output looks like this
Index ID 0
Document Type MYDOCTYPE
Date entered null
Why Index ID for all rows is 0 and Date entered for all rows is null
while I can get Document Type value correctly.
-
Do you Yahoo!?
Send a seasonal email greeting and help others. Do good.
__
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32785] New: - FileItem implements Serializable incorrectly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32785. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32785 Summary: FileItem implements Serializable incorrectly Product: Commons Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: File Upload AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] org.apache.commons.fileupload.FileItem implements Serializable, but does not honor the contract. It contains member field org.apache.commons.fileupload.DeferredFileOutputStream, which is not Serializable. Would prefer to have this class be truly Serializable but may not be practical considering the nature of it. It should at least not define itself as such, as it is misleading. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: [proposal] avoiding jar version nightmares
Matt Sgarlata wrote: Does this mean .NET doesn't have reflection? That's such a killer feature of Java; I can't believe they wouldn't have ported it to .NET. Any .NET developers out there that can tell us how .NET deals with reflection when you have multiple versions of the same class? Since the class name alone is insufficient to fully identify a specific version of a class, to my knowledge there is no equivalent to Class.forName(String classname) in .NET. Instead, .NET has the Assembly class. An Assembly is roughly akin to a java jar file, and is typically a single DLL that contains one or more classes. Assembly has a non-static getType(String typeName) method, that performs the same job as the static Class.forName(String classname) method in java, but for a specific Assembly instance. There is never any ambiguity over which version of the named Type that is returned, since an Assembly can only contain one version of any given class. Support for multiple versions of a class at runtime is achieved by storing those multiple class versions in separate Assemblies. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
