Re: [logging] Running tests on earlier JVMs
(fetchmail-jsieve-IMAP is now working fine for me in JAMES and i've stopped buggy FETCH response crashing evolution so but i won't have access to my old mail until i've rewritten the backend so that it will perform against big message sets. in short, i think i'm getting commons mail ok but i'm short on archives...) so could people help me get back up to speed on where we are with JCL and were we want to get to...? On Thu, 2007-07-19 at 22:19 +0200, Dennis Lundberg wrote: Henri Yandell wrote: snip Finding a (really old) platform to run on = We've said earlier that we should ideally run the tests using a 1.2 jvm. So I installed 1.2.2_17 on my Windows machine and started running tests. That didn't go to well. Here's what I get: Buildfile: build-testing.xml A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/Project.addReference (Ljava/lang/String;Ljava/lang/Object;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/Project.fireMessageLoggedEvent (Lorg/apache/tools/ant/BuildEvent;Ljava/lang/String;I)V': Interpreting method . Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/ComponentHelper.addCreatedTask (Ljava/lang/String;Lorg/apache/tools/ant/Task;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi init: [echo] Logging Wrapper Library 1.1.1-SNAPSHOT discovery: log4j12-test-warning: test: [echo] Test output can be found in directory G:\apache\jakarta\commons-logging/target/test-reports. [delete] Deleting directory G:\apache\jakarta\commons-logging\target\test-reports [mkdir] Created dir: G:\apache\jakarta\commons-logging\target\test-reports [echo] executing tests [**/*TestCase.java] A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/ComponentHelper.getDataTypeDefinitions ()Ljava/util/Hashtable;': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/DirectoryScanner.scan ()V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/util/FileUtils.createTempFile (Ljava/lang/String;Ljava/lang/String;Ljava/io/File;)Ljava/io/File;': Interpret ing method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/taskdefs/ProcessDestroyer.add (Ljava/lang/Process;)Z': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi [junit] java.lang.IllegalMonitorStateException: current thread not owner [junit] at org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java, Compiled Code) [junit] at java.lang.Thread.run(Thread.java:479) [junit] java.lang.IllegalMonitorStateException: current thread not owner [junit] at org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java, Compiled Code) [junit] at java.lang.Thread.run(Thread.java:479) And then it just hangs! This is done using ant 1.6.5. When I tried with ant 1.5.4 it didn't work at all because we use propertyset: BUILD FAILED file:G:/apache/jakarta/commons-logging/build-testing.xml:171: Unexpected element propertyset I don't know the jvm requirements for the different ant versions. I'll be checking in the ant script shortly... Any pointers to what might be going wrong here is greatly appreciated. the good news is that my old machine is now working again :-) here's my bad news: JCL source will not compile for me on a 1.2.2 JVM (IIRC some 1.2 JVM had compilers bugs) the tests will not compile for me on 1.3.1 JVM: MockSecurityManager uses Exception.getStackTrace() which was introduced with 1.4 runs well for me on 1.4 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (POOL-97) EVICTION_TIMER is never cancelled.
[ https://issues.apache.org/jira/browse/POOL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514495 ] Robert Burrell Donkin commented on POOL-97: --- This fix breaks binary compatibility but only at package private level. One question which may need to investigated is whether any subtle concurrency issues are prevent by using a static instance. I've taken a look at the code and i can only see it being used to set up eviction timings. Not sure whether these are ever cleared out. So, the instance will ensure the pool remains in memory until the server is restarted. More eyes would be good since it's very easy to miss subtle concurrency issues. I suppose that some benchmarks would be the right way to assess the performance impact of this patch. A more complex solution would be to create a private subclass of timer that does knows when to unschedule eviction tasks. The evictor would need to implement a package interface (unschedulable?) and then test for the pool being closed (or something like that). This would be quite a bit more effort with more to go wrong. EVICTION_TIMER is never cancelled. -- Key: POOL-97 URL: https://issues.apache.org/jira/browse/POOL-97 Project: Commons Pool Issue Type: Bug Affects Versions: 1.3 Reporter: Devendra Patil Fix For: 2.0 Attachments: timer.patch The static EVICTION_TIMER (java.util.Timer) used in GenericObjectPool is never cancelled (even after closing the pool). The GenericObjectPool.close() method just cancels the _evictor (TimerTask). I agree this behaviour is ideal if EVICTION_TIMER is to be used across multiple pools. But, In my case, the resources (i.e. jars) are dynamically deployed and undeployed on remote grid-servers. If EVICTION_TIMER thread doesn't stop, the grid-servers fails to undeploy (i.e. delete) the jars. The grid-server doesn't restart during resource deployment/undeployment, so, setting EVICTION_TIMER to daemon doesn't help me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Logging 1.1.1 - when?
On Thu, 2007-07-19 at 20:32 +0100, Niall Pemberton wrote: On 7/19/07, Henri Yandell [EMAIL PROTECTED] wrote: On 7/19/07, Sullivan, Sean [EMAIL PROTECTED] wrote: Are there plans to release Commons Logging 1.1.1? I am eager to see Commons Logging 1.1.1 because JCL 1.1 throws exceptions when running in a Java applet sandbox. (This bug is already fixed: https://issues.apache.org/jira/browse/LOGGING-106) The roadmap shows 4 issues that are resolved in Commons Logging 1.1.1: Plus I seem to recall that when I was digging through it for work, I found a significant bugfix that wasn't in JIRA. https://issues.apache.org/jira/browse/LOGGING?report=com.atlassian.jira. plugin.system.project:roadmap-panel Is anybody working on JCL 1.1.1? Not afaik. I put some effort in a bit back, but the release process was too confusing for the time I wanted to put in. Is it worth pinging Simon or Robert (last 2 release managers) directly for help - this may be going under their radar. i consider myself pinged - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moderators for [EMAIL PROTECTED]
On Mon, 2007-07-02 at 15:13 -0400, Rahul Akolkar wrote: On 7/2/07, Matt Benson [EMAIL PROTECTED] wrote: How arduous a task is it? snip/ Most I've spent is ~5 minutes in one day. Requirement would be people who generally check email atleast once a day. one of my JAMES TODOs is to create a collaborative email moderation application with web interface but since i haven't even finished fixing the IMAP implementation yet, it seems a long way off... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[compess] any objections to me jumping in?
any objections to me jumping in, applying some patches, fixing some bugs and generally tidying compress up? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BETWIXT-57) Class loader problem in JBoss version 4.0.4GA
[
https://issues.apache.org/jira/browse/BETWIXT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464026
]
Robert Burrell Donkin commented on BETWIXT-57:
--
I was a little concerned about the effects on existing installations of using
the context classloader but Betwixt is only a 0.x so feel free to break the
semantics if it's right thing to do and you documentation it at the bottom of
tasks.xml.
Please feel free to go ahead and add more javadocs (and documentation, if you
can find some time)
Class loader problem in JBoss version 4.0.4GA
-
Key: BETWIXT-57
URL: https://issues.apache.org/jira/browse/BETWIXT-57
Project: Commons Betwixt
Issue Type: Bug
Environment: JBoss application server version 4.0.4GA. Probably
affects most versions of JBoss
Reporter: Surjit Sen
Priority: Critical
When using betwixt in a JBoss application, Class not found exceptions get
thrown when Class.forName methods are called in classes
org.apache.commons.betwixt.digester.ElementRule and
org.apache.commons.betwixt.digester.ClassRule. Specifically the Class.forName
method uses the system class loader to load classes and in JBoss the
classpath normally does not contain the application jar files. The fix is
very simple. The Class.forName method calls in both the classes were replaced
with the following code lines in ElementRule and similar changes were made in
ClassRule as well. This fix ensures that the appropriate class loader is used
for loading classes and is similar to the fix made in log4j.
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader =
Class.forName(implementationClass).getClassLoader();
//Class clazz = Class.forName(implementationClass);
}
Class clazz = loader.loadClass(implementationClass);
descriptor.setImplementationClass(clazz);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] betwixt failed.
On Sun, 2007-01-07 at 03:19 +0100, Dennis Lundberg wrote: [EMAIL PROTECTED] wrote: Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20070106/betwixt.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] It seems that Netscape [1] has decided to take down the site where the rss-0.91.dtd file [2] is located. I googled for an alternate location and found one on freshmeat [3]. [1] http://my.netscape.com/ [2] http://my.netscape.com/publish/formats/rss-0.91.dtd [3] http://download.freshmeat.net/backend/rss-0.91.dtd the licensing for 0.91 is interesting (to say the least) which is why we can't distribute it removing the test seemed like the best idea so that's what i've done - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BETWIXT-57) Class loader problem in JBoss version 4.0.4GA
[
https://issues.apache.org/jira/browse/BETWIXT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462843
]
Robert Burrell Donkin commented on BETWIXT-57:
--
There are issues with switching universally to using the context classloader:
too many containers do not set this classloader correctly. Digester rules
should use the classloader provided by Digester. So, the Betwixt rules should
use the Digester classloader. However, the Digester implemetation is not
exposed by XmlIntrospector. So, this setting needs to be added into the
IntrospectionConfiguration.
I've committed these changes into trunk.
Now, when using Betwixt in a container like JBoss with a well behaved context
classloader, setUseContextClassLoader(true) should called on
IntrospectionConfiguration for the XMLIntrospector. This should produce the
same result as the fix above. Please try the latest code and open this again if
this fix doesn't work.
Class loader problem in JBoss version 4.0.4GA
-
Key: BETWIXT-57
URL: https://issues.apache.org/jira/browse/BETWIXT-57
Project: Commons Betwixt
Issue Type: Bug
Environment: JBoss application server version 4.0.4GA. Probably
affects most versions of JBoss
Reporter: Surjit Sen
Priority: Critical
When using betwixt in a JBoss application, Class not found exceptions get
thrown when Class.forName methods are called in classes
org.apache.commons.betwixt.digester.ElementRule and
org.apache.commons.betwixt.digester.ClassRule. Specifically the Class.forName
method uses the system class loader to load classes and in JBoss the
classpath normally does not contain the application jar files. The fix is
very simple. The Class.forName method calls in both the classes were replaced
with the following code lines in ElementRule and similar changes were made in
ClassRule as well. This fix ensures that the appropriate class loader is used
for loading classes and is similar to the fix made in log4j.
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader =
Class.forName(implementationClass).getClassLoader();
//Class clazz = Class.forName(implementationClass);
}
Class clazz = loader.loadClass(implementationClass);
descriptor.setImplementationClass(clazz);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BETWIXT-57) Class loader problem in JBoss version 4.0.4GA
[
https://issues.apache.org/jira/browse/BETWIXT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Burrell Donkin resolved BETWIXT-57.
--
Resolution: Fixed
Fix committed.
Class loader problem in JBoss version 4.0.4GA
-
Key: BETWIXT-57
URL: https://issues.apache.org/jira/browse/BETWIXT-57
Project: Commons Betwixt
Issue Type: Bug
Environment: JBoss application server version 4.0.4GA. Probably
affects most versions of JBoss
Reporter: Surjit Sen
Priority: Critical
When using betwixt in a JBoss application, Class not found exceptions get
thrown when Class.forName methods are called in classes
org.apache.commons.betwixt.digester.ElementRule and
org.apache.commons.betwixt.digester.ClassRule. Specifically the Class.forName
method uses the system class loader to load classes and in JBoss the
classpath normally does not contain the application jar files. The fix is
very simple. The Class.forName method calls in both the classes were replaced
with the following code lines in ElementRule and similar changes were made in
ClassRule as well. This fix ensures that the appropriate class loader is used
for loading classes and is similar to the fix made in log4j.
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader =
Class.forName(implementationClass).getClassLoader();
//Class clazz = Class.forName(implementationClass);
}
Class clazz = loader.loadClass(implementationClass);
descriptor.setImplementationClass(clazz);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Jakarta Commons Betwixt 0.8 Released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Jakarta Commons community is pleased to announce that Apache Jakarta Commons Betwixt 0.8 is now available for download from http://jakarta.apache.org/site/downloads/downloads_commons-betwixt.cgi. Please remember to verify the release when downloading from a mirror. Commons Betwixt is a reflective, dynamic, bean-centric object-xml mapper. It provides a flexible way to map beans into XML - and vice versa. It requires Java 1.3 or higher. For more details see http://jakarta.apache.org/commons/betwixt. Betwixt is an open source library developed by the Jakarta Project of the Apache Software Foundation (see http://jakarta.apache.org/) and released under the Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0). Jakarta commons is an open development community. All are invited to contribute by joining us on the mailing lists (see http://jakarta.apache.org/commons) or by raising issues and submitting patches through http://issues.apache.org. Betwixt 0.8 is a feature release. Support for polymorphic mappings has been improved. More flexible mapping are possible using new strategies. Enhancements have been made to mapping formats. Mixed collections are now handled more completely. Complete details can be found in the release notes http://jakarta.apache.org/commons/betwixt/betwixt-0.8/RELEASE-NOTES.txt. Betwixt 0.8 is compatible with 0.7. Documentation for this release is available from http://jakarta.apache.org/commons/betwixt/betwixt-0.8/docs/index.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFltPll6Otx30NTe0RAvu7AJ9L3vcD7XH8AYGMF0kqwto3G70AqQCgiwsc KDmH0kjk/bzAyhDwkdLz5ZQ= =BfSe -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Release Commons Betwixt 0.8
by my count: +1 robert burrell donkin +1 Jörg Schaible +1 Niall Pemberton +0 Rahul Akolkar +1 Mario Ivankovits so the vote passes with 4 binding +1's thanks to everyone who found the time to take a look (and yes, i will make very sure i don't mess my signatures up this time) - robert signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Commons Betwixt 0.8
On Mon, 2006-12-11 at 11:12 -0500, Rahul Akolkar wrote: On 12/11/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Robert! release candidate 4 is available @ http://people.apache.org/~rdonkin/commons-betwixt/ and the site @ http://people.apache.org/~rdonkin/commons-betwixt/site/ I've updated my gpg key store using gpg ---refresh-keys and got your now key (at least it looks like). Then I tried to check the sig: # gpg --verify commons-betwixt-0.8-RC4.tar.gz.asc commons-betwixt-0.8-RC4.tar.gz gpg: Signature made So 10 Dez 2006 16:52:55 CET using DSA key ID 7D0D4DED gpg: BAD signature from Robert Burrell Donkin (CODE SIGNING KEY) [EMAIL PROTECTED] yeh: it's bad Any idea why its BAD? i was in a rush and didn't bother double checking them :-/ The md5 sum is correct. snip/ I looked around for a couple of minutes, but couldn't find the key (tried the MIT server with Robert Donkin, needs to be the email address (rdonkin same as apache id) betwixt trunk and RC URL). Please point me to the key. http://www.apache.org/dist/jakarta/commons/betwixt/KEYS Also, I personally favor (now) the style with which we've made the last four releases out of Commons (final artifact versions, no need to rebuild artifacts after vote). I'm generally plus zero (spelling it out so its not confused with a vote) to the older style, such as this vote. i seem to remember bad experiences with leakages to ibiblio long ago but if this isn't a probably any more, i'd prefer to vote on artifacts. however, i haven't really kept up on the current fashions in the commons so i'm not sure what the current consensus is. what i'll do is keep this thread running for those who prefer to vote on candidates. if there are too few votes, i'll cut a release and people can vote on that instead. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] final checks on RC2
On Sat, 2006-11-25 at 19:05 +, Niall Pemberton wrote: On 11/25/06, robert burrell donkin [EMAIL PROTECTED] wrote: snip is there anyway to get the maven folks to take a look at the project.xml before it's released rather than afterwards? You might trying pinging Carlos Sanchez - hes given feedback on improving the project.xml to help m2 in the past. what's the best way to ping Carlos - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] final checks on RC2
On Sun, 2006-11-26 at 17:10 +, Niall Pemberton wrote: On 11/26/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sat, 2006-11-25 at 19:05 +, Niall Pemberton wrote: On 11/25/06, robert burrell donkin [EMAIL PROTECTED] wrote: snip is there anyway to get the maven folks to take a look at the project.xml before it's released rather than afterwards? You might trying pinging Carlos Sanchez - hes given feedback on improving the project.xml to help m2 in the past. what's the best way to ping Carlos carlos AT apache cheers - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (BETWIXT-56) Build improvements
[ http://issues.apache.org/jira/browse/BETWIXT-56?page=all ] Robert Burrell Donkin closed BETWIXT-56. Resolution: Fixed Committed. Many thanks. BTW i'm happy for apache folks to add their names to the betwixt and hack away Build improvements -- Key: BETWIXT-56 URL: http://issues.apache.org/jira/browse/BETWIXT-56 Project: Commons Betwixt Issue Type: Improvement Reporter: Niall Pemberton Priority: Minor Attachments: betwixt-0.8-rc2-nits.patch Attaching patch to: 1) Include the xdocs in the source distro 2) Addi scope elements to the xerces, xml-apis and junit dependencies in the project.xml for maven 2 3) Switch mail archive links 4) Chnage the maven build to create md5 checksums -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] final checks on RC2
On Fri, 2006-11-24 at 09:48 -0800, Henri Yandell wrote: On 11/23/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 11/23/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sun, 2006-11-19 at 19:53 +, robert burrell donkin wrote: thanks to everyone who commented on RC1 i've now cut an RC2 based on the feedback and uploaded the artifacts (only) to http://people.apache.org/~rdonkin/commons-betwixt/. please check them. unless issues emerge, i'll finish off the process (javadocs, signatures and so on) and move to a VOTE. no further reports so i'll move towards a vote soon Sorry Robert, kept meaning to look at the rc, but not finding time - couple of comments: 1) The xdocs are missing from the source distro applied 2) Adding scope elements to the xerces, xml-apis and junit dependencies in the project.xml will probably help maven 2 downstream users by not pulling in those dependencies Really important catch. applied is there anyway to get the maven folks to take a look at the project.xml before it's released rather than afterwards? 3) Don't know why, but everyone seems to have changed mail archive from eyebrowse Eyebrowse be dead. yep. applied 4) Add md5 checksums to the build would make creating the release easier. Wouldn't for me :) yeh - i prefer to use the scripts thanks for the review i've cut an RC3 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[betwixt] final checks for RC3
i've cut an RC3 including niall's improvements. it's available from http://people.apache.org/~rdonkin/commons-betwixt. please review. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] final checks on RC2
On Sun, 2006-11-19 at 19:53 +, robert burrell donkin wrote: thanks to everyone who commented on RC1 i've now cut an RC2 based on the feedback and uploaded the artifacts (only) to http://people.apache.org/~rdonkin/commons-betwixt/. please check them. unless issues emerge, i'll finish off the process (javadocs, signatures and so on) and move to a VOTE. no further reports so i'll move towards a vote soon - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[betwixt] final checks on RC2
thanks to everyone who commented on RC1 i've now cut an RC2 based on the feedback and uploaded the artifacts (only) to http://people.apache.org/~rdonkin/commons-betwixt/. please check them. unless issues emerge, i'll finish off the process (javadocs, signatures and so on) and move to a VOTE. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] please check RC1
On Sun, 2006-11-12 at 12:37 -0700, Phil Steitz wrote: On 11/12/06, robert burrell donkin [EMAIL PROTECTED] wrote: everyone ok with the current codebase? Sorry for the late response. better late than never definitely appreciated :-) I am not familiar with the code base, so comments below are just mechanical. Both maven and ant builds worked fine for me on FC 3, with Sun 1.5_06 jdk. Some small comments: 1. The release notes are great. They would be even greater if you replaced the old bugzilla issue numbers with the JIRA references :-). There is also a reference at the top to the change log document which I would expect to be the maven changelog report, but that report is excluded from the site. the change log postdates the manual betwixt system. i'll adjust the language to make things clearer 2. I would delete the last line of project.properties. If this is actually used for anything, we are in trouble ;-) good spot 8-) 3. What is conf/MANIFEST.MF for? It is not what gets put into the jar (which looks fine) dunno - looks like it's been hanging around from the days of yore. but gone now :-) 4. Do you really mean X-Compile-Target-JDK: 1.1? probably not 5. For general education purposes, should we *all* now be adding copyright statements to NOTICE.txt as you did? We should probably do this across the board in SVN. yep: see http://www.apache.org/legal/src-headers.html - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] please check RC1
On Sun, 2006-11-05 at 15:19 +0100, Dennis Lundberg wrote: robert burrell donkin wrote: http://people.apache.org/~rdonkin/commons-betwixt - robert I ran a linkcheck on the Maven generated site and it found a couple of broken links that I have fixed. thanks :-) When compiling using Maven 1.0.2 and JDK 1.4.2_12 I get 12 deprecation warnings for the sources and 19 deprecation warnings for test sources. Maybe something to have a look at? yeh nearly all are in deprecated methods or classes or test deprecated methods or classes. this other one is safe enough (overrides a deprecated method) and it's probably not worth risking making a change. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[betwixt] please check RC1
http://people.apache.org/~rdonkin/commons-betwixt - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[betwixt] Propose 0.8 Release
i've taken a good look at the code base, tidied up some legal issues and some bad speiling. looks good. so, i've created a minimal release plan here: http://wiki.apache.org/jakarta-commons/Betwixt/0.8ReleasePlan. unless there are any other volunteers, i'll act as release managers. sound ok? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] What's needed for a 0.8 release ?
On Mon, 2006-10-23 at 22:50 -0700, Thomas Dudziak wrote: On 10/23/06, robert burrell donkin [EMAIL PROTECTED] wrote: barring unforeseen events, i should have time on tuesday and wednesday. the infrastructure should all be back up by then. great, thanks! Let me know how I can help! there aren't any JIRA issues for which fixes are definitely required before 0.8 can be released. there a number of nice-to-haves and some long term issues which require some effort to fix. it's been a long time since the last release so i think that it's less risky to cut from a branch without any new code in. be good to see some of the patches applied, though. unless anyone has a better plan, i'll take a branch almost immediately, see what's required to release the code base then create a page on the wiki. opinions? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] What's needed for a 0.8 release ?
On Tue, 2006-10-17 at 01:19 +0200, Martin van den Bemt wrote: Highly appreciated Robert.. barring unforeseen events, i should have time on tuesday and wednesday. the infrastructure should all be back up by then. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] What's needed for a 0.8 release ?
On Sun, 2006-10-15 at 13:57 -0700, Thomas Dudziak wrote: Hi folks, hi thomas as we're reading the 1.0 release of DdlUtils, Martin noticed that we currently use a SVN build of commons-betwixt. Since we very much would like to have a proper released betwixt version instead, I wanted to ask what needs to be done for a 0.8 release. makes sense. i don't recall anything in particular that was really needed for a release (but i've been really busy and haven't really done any betwixt development for months) I'd be happy to help getting these things done, if someone could e.g. mark the issues necessary for 0.8 in JIRA ? i'll try to find some time in the next day or two - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (BETWIXT-54) CyclicReferenceException Logging
[ http://issues.apache.org/jira/browse/BETWIXT-54?page=all ] Robert Burrell Donkin closed BETWIXT-54. Resolution: Fixed hi holgar thanks for the patch i've committed a variation upon the patch. i'm a little concerned that logging to error is a little high. so, i've logged to info but included the information in the exception which should be printed out when caught. please give this a try. if this isn't good enough then i'll consider turning up the log level again. robert CyclicReferenceException Logging Key: BETWIXT-54 URL: http://issues.apache.org/jira/browse/BETWIXT-54 Project: Commons Betwixt Issue Type: Improvement Environment: / Reporter: Holger Haag Priority: Trivial Attachments: betwixt-cyclic-reference-logging.patch I got screwed last night because of a CyclicReferenceException without additional info (debug level not switched on). So I've increased the priority of some log entries from debug to error and added some more information (class names of all objects in the stack). I think this will make debugging CyclicReferenceException much easier. Patch attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Project blog?
On Mon, 2006-07-17 at 10:31 -0700, Henri Yandell wrote: I took a break from Commons stuff yesterday to work on some Commons stuff. A while back I decided I should stop posting Commons bits in my personal blog and make a blog dedicated to it. A few days ago it dawned on me that I should then try to lure other Commons bloggers into putting their Commons bits on the same blog. One blog, many authors. A project blog. Here's what I've come up with so far: http://www.featheredblogs.org/blogs/page/commoners Much work still needed obviously, but thought I'd see what people thought. Of special note: - the Triage page is scraped from JIRA's RSS feed to produce a page on which issues that need deciding on can be looked at. I'll add an RSS option and have it email the list at some point too. It only has certain components currently (ones that have been cleaned up). - the 'In the Sandbox' category is an idea for a stock interview about a new sandbox component. A bit of advertising basically. Some questions: * Anyone interested in the idea? i've had a little bit of think and i'd be interested in sign up if you'd be happy for me to sign on... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (BETWIXT-53) Patch: MethodExpression - improved error logging
[ http://issues.apache.org/jira/browse/BETWIXT-53?page=all ] Robert Burrell Donkin closed BETWIXT-53. Resolution: Fixed Committed. Many thanks. Robert Patch: MethodExpression - improved error logging Key: BETWIXT-53 URL: http://issues.apache.org/jira/browse/BETWIXT-53 Project: Commons Betwixt Issue Type: Improvement Reporter: Holger Haag Priority: Trivial Attachments: betwixt.patch added new parameter to handleException: Method m to show/log which method invocation did not work -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Project blog?
On Mon, 2006-07-17 at 10:31 -0700, Henri Yandell wrote: I took a break from Commons stuff yesterday to work on some Commons stuff. A while back I decided I should stop posting Commons bits in my personal blog and make a blog dedicated to it. A few days ago it dawned on me that I should then try to lure other Commons bloggers into putting their Commons bits on the same blog. One blog, many authors. A project blog. Here's what I've come up with so far: http://www.featheredblogs.org/blogs/page/commoners Much work still needed obviously, but thought I'd see what people thought. Of special note: - the Triage page is scraped from JIRA's RSS feed to produce a page on which issues that need deciding on can be looked at. I'll add an RSS option and have it email the list at some point too. It only has certain components currently (ones that have been cleaned up). - the 'In the Sandbox' category is an idea for a stock interview about a new sandbox component. A bit of advertising basically. Some questions: * Anyone interested in the idea? sounds cool - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Chain1.1 based on RC3
On Thu, 2006-06-08 at 20:53 +0100, Niall Pemberton wrote: I have just uploaded release candidate 3 (RC3) for Commons Chain 1.1 a few nits: the source distribution unpacks to the same directory as the binary distribution not a big fan of using the change-report document as the release notes. for the source distribution, this means that a user needs to know how to build the documentation before they can read the release notes. i much prefer release notes to be text (i usually read them from the command line). improving this probably needs a plugin so i'm not going to hold up this release. but overall it's just about good enough [X] +1 looks good enough [ ] +0 [ ] -0 [ ] -1 nope, something needs fixing - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release FileUpload 1.1.1-RC1 (take two)
On Sat, 2006-06-03 at 14:42 -0700, Henri Yandell wrote: Repeating this vote call because the last one got a bit lost in getting the site generation right, but I don't think an RC2 is required just for that. - I've prepared a release for FileUpload; http://people.apache.org/~bayard/fileupload/ [X] +1, looks good (enough) [ ] -1, nope, something needs fixing. Will keep the vote open until Wednesday. remember to fix the release date on the documentation Henri Yandell is missing from the list of project members ;-) some checkstyle issues: bad path? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [VOTE] commons karma for Jochen Wiedmann
i count: +1's (binding) robert burrell donkin Stephen Colebourne Yoav Shapira Davanum Srinivas with no other votes. if i have made any mistakes please post a correct. therefore the vote for jakarta karma for jochen has passed. - robert On Tue, 2006-05-23 at 23:31 +0100, robert burrell donkin wrote: Jochen Wiedmann ([EMAIL PROTECTED]) is a pmc'er over in web services land. Jochen would like commons karma (http://mail-archives.apache.org/mod_mbox/jakarta-general/200605.mbox/% [EMAIL PROTECTED]) to help work on file-upload. i trust that he'll discuss any plans with the file upload team but i think we can use his help. since this is a vote for karma, i think this can be executed a little quicker than normal. i'll tally votes not earlier than 2230 hours GMT on Thursday 25th of May. here's my +1 - robert --8 [ ] +1 grant Jochen Wiedmann commons karma [ ] +0 [ ] -0 [ ] -1 do not grant Jochen Wiedmann commons karma --- signature.asc Description: This is a digitally signed message part
[jira] Resolved: (LOGGING-105) Implementation dependencies should be set to runtime scope
[ http://issues.apache.org/jira/browse/LOGGING-105?page=all ] Robert Burrell Donkin resolved LOGGING-105: --- Resolution: Duplicate JCL does not fit nicely into the Maven2 dependency management scheme so this creating a good POM difficult. The Commons team does not maintain the Maven2 POMs for JCL. Please add any comments you have to http://jira.codehaus.org/browse/MEV-392. Implementation dependencies should be set to runtime scope -- Key: LOGGING-105 URL: http://issues.apache.org/jira/browse/LOGGING-105 Project: Commons Logging Type: Bug Versions: 1.1 Final Reporter: Michael Hartman The logkit, log4j, and avalon-framework dependencies listed in the commons-logging-1.1.pom Maven2 POM should have their scopes set to runtime or otherwise be set to optional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
On Thu, 2006-06-01 at 19:05 +0100, Stephen Colebourne wrote: Henri Yandell wrote: I pondered it for a while. The tag is of value - it's so we can start a branch if trunk suddenly becomes untenable. My biggest concern with Simon's reason was that it encourages read-write tags if we take it fully. Ideally we would copy the rc tag to the release tag, modify the rc bits to the real release and then build a release. Are we happy with tags being edited like that? not really: makes it a lot more difficult to work out what the release was actually cut from Well I know I'd have to rethink all the scripts I've now worked up to get releases out consistently and easily. Sounds like all we might agree on here is for each release manager to make a choice. i'm unhappy about tags being deleted and i don't really think it's necessary with subversion. why not separate releases from release candidates? for example: commons-whatever - trunk | - branches | - tags | - candidates | - releases - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
On Mon, 2006-05-29 at 23:43 +1200, Simon Kitching wrote: On Mon, 2006-05-29 at 12:35 +0100, Stephen Colebourne wrote: Simon Kitching wrote: On Sun, 2006-05-28 at 00:03 -0700, Henri Yandell wrote: [I haven't created an SVN tag for the RC1. Is there any particular reason the release info says to create a tag?] Making a tag in subversion has exactly the same price as checking in one new file, ie is trivial. I think the existing release advice is therefore good; creating a tag for an RC should be the regular practice. Personally I don't like the resulting 'tag clutter'. Is there any way in SVN to remove dead tags? Sure; svn rm. A tag is just a directory (well, actually, just an entry in the parent directory that points to a specific inode). For RCs from releases before the current one, I think deleting them seems reasonable (eg when 1.2 is released, remove 1.0 RC tags). I'd prefer to keep RC tags for at least one release though. If you don't like them in the main tags directory, they could be pushed down into a special RC directory Of course delete just makes them not visible in the head revision; the tag directory is still there if you look for it. is there any reason why we actually need to remove dead tags? subversion holds the history of the project and deleting history seems a little extreme (as well as bring potentially problems down the line). why not just move dead tags to a special area? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BETWIXT-52) Bug/Testcase: Reading does not work: Container holding a list (generics) of interface implementations
[ http://issues.apache.org/jira/browse/BETWIXT-52?page=all ] Robert Burrell Donkin resolved BETWIXT-52: -- Resolution: Fixed This took quite a lot of work for what turned out to be a small fix! Thanks very much for unit tests - I don't think I'd have stayed the course without them. Please free to reopen if I haven't fixed it fully. Bug/Testcase: Reading does not work: Container holding a list (generics) of interface implementations - Key: BETWIXT-52 URL: http://issues.apache.org/jira/browse/BETWIXT-52 Project: Commons Betwixt Type: Bug Reporter: Holger Haag Attachments: AlphaListHolder.java, TestPolyListHolder.java, betwixt-polylistholder-2006-05-24-svn-patch, poly.zip Referring to the thread http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL PROTECTED] on the commons-user mailing list: I've created a test case reproducing this issue. First of all I've extended the existing test case TestPolyList: The interface implementations of AlphaOneImpl and AlphaTwoImpl now have attributes which are serialized/deserialized. This is closer to real-world examples. Secondly, there is now a new javabean-like class, AlphaListHolder which holds an instance of AlphaList. The test case TestPolyListHolder tries to do the serialization/deserialization. Serialization works nicely, but reading the XML fails. I'll attach four files: - betwixt-polylistholder-2006-05-24-svn-patch: svn patch for existing files - TestPolyListHolder.java: new test case - AlphaListHolder.java: the holder class - poly.zip: the whole poly package, just in case (the above mentioned three files should be sufficient to patch the SVN trunk) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (BETWIXT-52) Bug/Testcase: Reading does not work: Container holding a list (generics) of interface implementations
[ http://issues.apache.org/jira/browse/BETWIXT-52?page=all ] Robert Burrell Donkin closed BETWIXT-52: Bug/Testcase: Reading does not work: Container holding a list (generics) of interface implementations - Key: BETWIXT-52 URL: http://issues.apache.org/jira/browse/BETWIXT-52 Project: Commons Betwixt Type: Bug Reporter: Holger Haag Attachments: AlphaListHolder.java, TestPolyListHolder.java, betwixt-polylistholder-2006-05-24-svn-patch, poly.zip Referring to the thread http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL PROTECTED] on the commons-user mailing list: I've created a test case reproducing this issue. First of all I've extended the existing test case TestPolyList: The interface implementations of AlphaOneImpl and AlphaTwoImpl now have attributes which are serialized/deserialized. This is closer to real-world examples. Secondly, there is now a new javabean-like class, AlphaListHolder which holds an instance of AlphaList. The test case TestPolyListHolder tries to do the serialization/deserialization. Serialization works nicely, but reading the XML fails. I'll attach four files: - betwixt-polylistholder-2006-05-24-svn-patch: svn patch for existing files - TestPolyListHolder.java: new test case - AlphaListHolder.java: the holder class - poly.zip: the whole poly package, just in case (the above mentioned three files should be sufficient to patch the SVN trunk) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] commons karma for Jochen Wiedmann
On Tue, 2006-05-23 at 15:58 -0700, Martin Cooper wrote: On 5/23/06, robert burrell donkin [EMAIL PROTECTED] wrote: Jochen Wiedmann ([EMAIL PROTECTED]) is a pmc'er over in web services land. Jochen would like commons karma (http://mail-archives.apache.org/mod_mbox/jakarta-general/200605.mbox/% [EMAIL PROTECTED]) to help work on file-upload. Since when did we start inviting people into Jakarta based on their first (AFAIK) proposed - and not yet accepted - patch? Has anyone looked at the patch? I haven't seen any discussion on it, and I know that I'm not going to have time to look at it until the weekend, long after this vote will have closed, apparently. sorry - i didn't intend to cause any offence. IMO fileupload isn't inactive. perhaps i didn't make it clear enough that my intention for a vote for jakarta karma only. i probably made a misjudgement in calling for a 48 hour vote only. it sets a bad precedent. This is nothing personal against Jochen - I don't know him at all - and is not related to the fact that his contribution is for FileUpload. I'm just very concerned at how low we're setting the bar these days. i admit that i do have a lower bar for existing apache committers (in general) and for committers i know and trust (in particular). my personal matrix involves an estimate of how much energy i'll need to spare to effectively mentor them. IMHO it's a hard judgement call. i've been too conservative in proposing committers in the past. hopefully people will continue to jump in and correct me if i start going too far the other way... I, for one, do not subscribe to the Some of the guys over in project X think Fred is OK, so he must be OK modus operandum. i'm the guy you're talking about :-) jochen's ok by me. i've worked with him for a number of years. i trust him enough to propose him as a jakarta committer. but i'm glad you raised this as a more general issue and i'd like to hear you expand your opinions... Are we really saying that we'll allow other projects to decide on who merits commit access to Jakarta? That's what Hen appears to be saying, and I object strongly. personally speaking, i would be very happy for a low bar for existing apache committers. jakarta karma can be obtained on request in any case (in order to work on sandbox components). but i don't see that being the same thing at all as allowing unrestricted access to work on existing components. i hope that social pressures would be enough (as they have proved to be in the past). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BETWIXT-50) Versioning of XML Output
[
http://issues.apache.org/jira/browse/BETWIXT-50?page=comments#action_12413183 ]
Robert Burrell Donkin commented on BETWIXT-50:
--
Committed. Many thanks.
Versioning of XML Output
Key: BETWIXT-50
URL: http://issues.apache.org/jira/browse/BETWIXT-50
Project: Commons Betwixt
Type: Improvement
Reporter: Holger Haag
Assignee: Robert Burrell Donkin
Attachments: betwixt-versioning-patch, src.zip
Referring to the thread Versioning of XML Output
(http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL
PROTECTED]) on the jakarta-commons-user mailing list, I'll provide here a
SVN patch for the described problem.
- Two new strategies: Attribute and Element suppression. Chose interfaces
instead of abstract class so that one class (see test cases) can implement
both.
- After an element/attribute descriptor has been build completely (including
the options), the suppression strategies are evaluated. If the
element/attribute shall be suppressed, it is removed from the introspection
results.
- Important: use addDefaults add-properties=false / ! Otherwise the
effects of element/attribute suppression will be ... none.
- Test cases for illustration
=== Code snippets + explanation == :
* Added new Interfaces
org.apache.commons.betwixt.strategy.AttributeSuppressionStrategy
public boolean suppress(AttributeDescriptor descr);
org.apache.commons.betwixt.strategy.ElementSuppressionStrategy
public boolean suppress(ElementDescriptor descr);
* Added setter/getter methods for such strategies in
org.apache.commons.betwixt.IntrospectionConfiguration
* org.apache.commons.betwixt.digester.ElementRule: Remove element descriptor
if suppressed:
ElementDescriptor descriptor = (ElementDescriptor)digester.pop();
final Object peek = digester.peek();
if(peek instanceof ElementDescriptor) {
ElementDescriptor parent = (ElementDescriptor)digester.peek();
// check for element suppression
if(
getXMLIntrospector().getConfiguration().getElementSuppressionStrategy().suppress(descriptor))
{
parent.removeElementDescriptor(descriptor);
}
}
* org.apache.commons.betwixt.digester.AttributeRule: Remove attribute
descrptor if suppressed:
AttributeDescriptor descriptor =
(AttributeDescriptor)digester.pop();
ElementDescriptor parent = (ElementDescriptor)digester.peek();
// check for attribute suppression
if(
getXMLIntrospector().getConfiguration().getAttributeSuppressionStrategy().suppress(descriptor))
{
parent.removeAttributeDescriptor(descriptor);
}
* ElementDescriptor: new methods:
public void removeAttributeDescriptor(AttributeDescriptor descriptor) {
getAttributeList().remove(descriptor);
}
public void removeElementDescriptor(ElementDescriptor descriptor) {
getElementList().remove(descriptor);
getContentList().remove(descriptor);
}
public AttributeDescriptor getAttributeDescriptor(final String name)
{
for (int i = 0, size = attributeDescriptors.length; i size;
i++)
{
AttributeDescriptor descr = attributeDescriptors[i];
if (descr.getQualifiedName().equals(name)) {
return descr;
}
}
return null;
}
* Test cases: package org.apache.commons.betwixt.versioning
VersioningStrategy implements both an element and versioning strategy
VersioningTest well.. .test the versioning.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (BETWIXT-50) Versioning of XML Output
[ http://issues.apache.org/jira/browse/BETWIXT-50?page=all ]
Robert Burrell Donkin closed BETWIXT-50:
Resolution: Fixed
Committed. Many thanks.
Wrong issues number in commit message :-/
Maybe I'll learn one day...
Versioning of XML Output
Key: BETWIXT-50
URL: http://issues.apache.org/jira/browse/BETWIXT-50
Project: Commons Betwixt
Type: Improvement
Reporter: Holger Haag
Assignee: Robert Burrell Donkin
Attachments: betwixt-versioning-patch, src.zip
Referring to the thread Versioning of XML Output
(http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL
PROTECTED]) on the jakarta-commons-user mailing list, I'll provide here a
SVN patch for the described problem.
- Two new strategies: Attribute and Element suppression. Chose interfaces
instead of abstract class so that one class (see test cases) can implement
both.
- After an element/attribute descriptor has been build completely (including
the options), the suppression strategies are evaluated. If the
element/attribute shall be suppressed, it is removed from the introspection
results.
- Important: use addDefaults add-properties=false / ! Otherwise the
effects of element/attribute suppression will be ... none.
- Test cases for illustration
=== Code snippets + explanation == :
* Added new Interfaces
org.apache.commons.betwixt.strategy.AttributeSuppressionStrategy
public boolean suppress(AttributeDescriptor descr);
org.apache.commons.betwixt.strategy.ElementSuppressionStrategy
public boolean suppress(ElementDescriptor descr);
* Added setter/getter methods for such strategies in
org.apache.commons.betwixt.IntrospectionConfiguration
* org.apache.commons.betwixt.digester.ElementRule: Remove element descriptor
if suppressed:
ElementDescriptor descriptor = (ElementDescriptor)digester.pop();
final Object peek = digester.peek();
if(peek instanceof ElementDescriptor) {
ElementDescriptor parent = (ElementDescriptor)digester.peek();
// check for element suppression
if(
getXMLIntrospector().getConfiguration().getElementSuppressionStrategy().suppress(descriptor))
{
parent.removeElementDescriptor(descriptor);
}
}
* org.apache.commons.betwixt.digester.AttributeRule: Remove attribute
descrptor if suppressed:
AttributeDescriptor descriptor =
(AttributeDescriptor)digester.pop();
ElementDescriptor parent = (ElementDescriptor)digester.peek();
// check for attribute suppression
if(
getXMLIntrospector().getConfiguration().getAttributeSuppressionStrategy().suppress(descriptor))
{
parent.removeAttributeDescriptor(descriptor);
}
* ElementDescriptor: new methods:
public void removeAttributeDescriptor(AttributeDescriptor descriptor) {
getAttributeList().remove(descriptor);
}
public void removeElementDescriptor(ElementDescriptor descriptor) {
getElementList().remove(descriptor);
getContentList().remove(descriptor);
}
public AttributeDescriptor getAttributeDescriptor(final String name)
{
for (int i = 0, size = attributeDescriptors.length; i size;
i++)
{
AttributeDescriptor descr = attributeDescriptors[i];
if (descr.getQualifiedName().equals(name)) {
return descr;
}
}
return null;
}
* Test cases: package org.apache.commons.betwixt.versioning
VersioningStrategy implements both an element and versioning strategy
VersioningTest well.. .test the versioning.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] commons karma for Jochen Wiedmann
Jochen Wiedmann ([EMAIL PROTECTED]) is a pmc'er over in web services land. Jochen would like commons karma (http://mail-archives.apache.org/mod_mbox/jakarta-general/200605.mbox/% [EMAIL PROTECTED]) to help work on file-upload. i trust that he'll discuss any plans with the file upload team but i think we can use his help. since this is a vote for karma, i think this can be executed a little quicker than normal. i'll tally votes not earlier than 2230 hours GMT on Thursday 25th of May. here's my +1 - robert --8 [ ] +1 grant Jochen Wiedmann commons karma [ ] +0 [ ] -0 [ ] -1 do not grant Jochen Wiedmann commons karma --- signature.asc Description: This is a digitally signed message part
Re: [site]Sites for snapshots published
On Mon, 2006-05-22 at 20:45 +0200, Oliver Heger wrote: Hi, I just noticed that recently the sites of some components have been deployed directly from their svn trunk. So the sites refer to snapshot versions (e.g. BeanUtils, Configuration, Math, ...). Was this done by intension? yep - i did it. i went through and changed siteAddress then redeployed each site. please feel free to jump in and redeploy anything that isn't right. It might be confusing for users if the sites describe features that are not contained in the latest releases. IMHO it's a trade off. users get to see all the features that are available but have to actively search for documentation related to the version they have downloaded. many components provide link to the released documentation (for example http://jakarta.apache.org/commons/logging/) though it would probably be a good idea to add an indication on the navigation bar that these documents apply to the latest code... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Unifying maven reports?
On Sun, 2006-05-21 at 22:06 +0200, Dennis Lundberg wrote: Dion Gillard wrote: snip We're under resourced here as it is. Do we really have extra volunteers waiting to frack about making reports consistent? Does it really make it easier for our users? I haven't seen complaints about inconsistent maven reports lately. AFAICT, maintaining the project.xml files hasn't been a big hassle. First off, I wouldn't be starting this discussion if I wasn't prepared to work on it. This is one of many steps that I feel are needed to get a faster, more reliable and more automated system for handling our component sites. That would in turn free the developers, who might not be interested in the site stuff, to do more coding or whatever they feel like contributing with. sounds good to me :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] cvs.apache.org - people.apache.org
just to let everyone know that we need to change the site url from cvs.apache.org to people.apache.org. i plan to go through the project.xml's in trunks-proper and make this change but thought it best to let everyone know first. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On Thu, 2006-05-18 at 11:02 +1000, Torsten Curdt wrote: Opening this up again. groupId: org.apache.commons +1!! ditto - robet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Maven 2 POM(s) for commons-logging [Was: RE : [ANNOUNCEMENT] Apache Jakarta Commons Logging 1.1 Released]
On Tue, 2006-05-16 at 20:32 +1200, Simon Kitching wrote: On Mon, 2006-05-15 at 21:11 +0100, robert burrell donkin wrote: or should we try to create a POM for commons-logging-api or perhaps both? not sure the API works best as a virtual dependency. it can be satisfied by JCL 1.0.x, 1.1.x, by ceki's adapter or by Torsten's null implementation. not sure whether maven 2 handles this ATM. Not sure what you mean by a virtual dependency. I think the api jar should never be used as a dependency by anyone; it's really only for the use of tomcat. If other people provide jars that define classes o.a.c.l.Log and LogFactory, then that can be used as a dependency *instead* of depending on anything from the commons-logging group. Is that what you meant? pretty much - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Maven 2 POM(s) for commons-logging [Was: RE : [ANNOUNCEMENT] Apache Jakarta Commons Logging 1.1 Released]
On Mon, 2006-05-15 at 20:51 +0200, Dennis Lundberg wrote: Olivier Lamy wrote: Hi,n Thanks it's great job which fixes some troubles. But I have a trouble concerning the pom published [1]. I have recorded an MEV issue [2] A commons-logging developper's can put a comment or approve it ? Thanks, - Olivier [1] http://www.ibiblio.org/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom [2] http://jira.codehaus.org/browse/MEV-392 snip/ I have written a comment in the JIRA issue about why the situation is the way it is. looks good :-) The question is how we should proceed? Should we try to tweak the POM that is currently deployed [1] i didn't deploy that POM and don't have karma: we'd need to talk the to maven team. it's too late for me to change the release POM deployed to the Apache repository: it's cut. the easiest approach would be for one of the maven team (who has karma) to apply appropriate modifications to the POM version in the maven 2 repository. or should we try to create a POM for commons-logging-api or perhaps both? not sure the API works best as a virtual dependency. it can be satisfied by JCL 1.0.x, 1.1.x, by ceki's adapter or by Torsten's null implementation. not sure whether maven 2 handles this ATM. but the API jar contains more than is necessary for this purpose. probably carlos is right that all the dependencies need to be marked as optional but the full JCL jar shipped. not sure... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On Sun, 2006-05-14 at 12:32 -0700, Phil Steitz wrote: On 5/14/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sat, 2006-05-13 at 15:21 -0700, Henri Yandell wrote:# snip I feel that we should be using ACL's on the maven repository on minotaur such that only a PMC can release their code onto the maven repository - but there hasn't seemed much interest in trying to do such. IMHO bit pointless ATM. need to remove shell from the distribution machine before changes like this are worthwhile. but definitely worth bringing up again in a month or two. i've been thinking about using subversion to manage distributions. in addition to better ACLs, this would allow scripts to be run that could verify signatures. be a good thing to move to henk's system of key management as well. What is that system? many months ago, henk penning presented a system for ASF OpenPGP key management but i can't find a reference right now. with a bit of luck i might be able to catch up with henk at apachecon europe... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Maven 2 POM(s) for commons-logging
On Mon, 2006-05-15 at 14:21 -0700, Carlos Sanchez wrote: I'm gonna tweak the poms in the repository outside of apache, thanks please add the optional property in the optional dependencies for future versions. done do we need to roll this out for all commons projects? I'll take a look to the other jars to make poms. note that the api and adapters jars are not really modules: they are selections of the classes available in the main jar. they are used within containers (for example, tomcat) with complex hierarchical classloaders. whether api, adapter or full JCL should be used may depend on the particular container the application is targeted at. the api jar also doubles as a compilation time virtual dependency. so, a component listing the api jar as a dependency could have this dependency satisfied by the API jar, the full jar, ceki's bridging API, or Torsten's null implementation. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] JCL 1.1 FC available for final checks
On Sat, 2006-05-13 at 20:18 +0200, Dennis Lundberg wrote: robert burrell donkin wrote: i've uploaded JCL1.1FC to http://people.apache.org/~rdonkin/commons-logging/. it's not yet available through the distributions and it will be a day or two before the mirrors sync and i issue the official announcement. Robert, I have been unable to do a download earlier because of the problems with minotaur. Now that it has been brought back online again, the directory mentioned above is empty. Have you removed the files or does this have something to do with the downtime of minotaur? minotaur is now back up but i deleted the files yesterday. they are now in their final locations. once the mirrors have sync'd i'll be making the announcement (so if there are any problems it's too late to address with 1.1). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] JCL 1.1 FC available for final checks
On Sun, 2006-05-14 at 11:10 +0200, Dennis Lundberg wrote: robert burrell donkin wrote: On Sat, 2006-05-13 at 20:18 +0200, Dennis Lundberg wrote: robert burrell donkin wrote: snip minotaur is now back up but i deleted the files yesterday. they are now in their final locations. once the mirrors have sync'd i'll be making the announcement (so if there are any problems it's too late to address with 1.1). OK, I just checked my local mirror and the one on www.apache.org and on both it seems that the README.html file used by the httpd module mod_autoindex is wrong. Its heading says Commons-Logging v1.1.1. good spot 8-) Can someone fix that? fixed AIUI the site is currently being hosted on ajax so it will take a while to sync I don't know if I have the rights to do it myself. you have karma but it's best for the release manager to make changes to the distribution directory... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On Sat, 2006-05-13 at 15:21 -0700, Henri Yandell wrote:# snip I feel that we should be using ACL's on the maven repository on minotaur such that only a PMC can release their code onto the maven repository - but there hasn't seemed much interest in trying to do such. IMHO bit pointless ATM. need to remove shell from the distribution machine before changes like this are worthwhile. but definitely worth bringing up again in a month or two. i've been thinking about using subversion to manage distributions. in addition to better ACLs, this would allow scripts to be run that could verify signatures. be a good thing to move to henk's system of key management as well. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] [vote] Release commons-jelly-tags-interaction 1.1
On Tue, 2006-05-09 at 23:07 +0200, Paul Libbrecht wrote: The story seems quite simple so I thought I'd just ask for a vote sorry if too stressed. The interaction jelly tag-library is now ready for release 1.1. It has been recently boosted with a finer control on auto-completion, and maven console plugin is using it successfully. Thanks to give it a try* and provide a vote. is this a vote on the idea of releasing (in other words, a release plan) or on actually cutting a release? if it's an actual release vote then i'd like to be able to check a release candidate before casting a vote... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Apache Jakarta Commons Logging 1.1 Released
The Jakarta Commons team are pleased to announced that Apache Jakarta Commons Logging (JCL) 1.1 has been released. JCL is a thin bridging API for logging with adapters for many common logging systems. Read more about JCL at http://jakarta.apache.org/commons/logging. JCL 1.1 is a maintenance release. A few new configuration features are provided but the focus has been on improving the discovery of logging implementations and in error handling whilst maintaining backwards compatibility. A number of problems that have troubled some users in past releases will hopefully be significantly reduced or cured. This is covered in more detail in the release notes (http://jakarta.apache.org/commons/logging/RELEASE-NOTES.txt). Some changes have been made to the class-wise composition of the distributed jars. Some deprecated classes are no longer shipped. This is covered in more detail in the release notes (http://jakarta.apache.org/commons/logging/RELEASE-NOTES.txt. The JCL documentation has also been improved. A Technology Guide (http://jakarta.apache.org/commons/logging/tech.html) offering an introduction to classloading issues and a Troubleshooting Guide (http://jakarta.apache.org/commons/logging/troubleshooting.html') complement an improved User Guide (http://jakarta.apache.org/commons/logging/guide.html) Binary and source distributions are available at http://jakarta.apache.org/site/downloads/downloads_commons-logging.cgi. The jars are available from the usual repositories with codegroupId: commons-logging/code and codeartifactId: commons-logging/code. Please remember to verify the signatures. Robert Burrell Donkin signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release collections v3.2
On Sat, 2006-05-13 at 00:15 +0100, Stephen Colebourne wrote: Stephen Colebourne wrote: This is a vote for the release of [collections] v3.2 RC1 is here: http://people.apache.org/~scolebourne/commons-collections/ Site here: http://people.apache.org/~scolebourne/commons-collections/site/ Release notes here: http://people.apache.org/~scolebourne/commons-collections/site/release_3_2.html I have prepared an RC2 at the above URLs. This fixes all points raised by Michael, Simon and Robert except the maven website in binary issue (this require changes to my batch files and would be a higher risk change at this point) At present, the vote count is: +1 Stephen Colebourne +1 Torsten Curdt +1 (non-binding) Michael Heuer Robert Burrell Donkin voted +1 with qualifications which haven't been met. (Can you decide if this is a blocker for you? It'll need a re-vote if it is.) sorry - the +1 was not intended to be conditional. what i meant was i'm +1 (RC1 met my minimum standards for release) but could be improved. i'll try to be a bit more careful with my phrasing in future. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? how much hassle would this change be for downstream consumers? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release collections v3.2
On Thu, 2006-05-11 at 09:15 +0100, Stephen Colebourne wrote: Stephen Colebourne wrote: [X] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... I support the release, but I'm missing at least one more vote at this point... been a bit difficult given the current issues with minotaur... [X] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... with some qualifications Vote will remain open until Friday 20:00 UT seems a bit tight given the current problems with minotaur i note that commons collections binary distribution now ships with just API documentation. AFAIK this means that the user guide isn't distributed. assuming that this isn't an oversight, i'd like a full cut of the maven generated website to be made available on line. the JDK version for the MANIFEST.MF 'Created-By' property is 1.3.1_16-b06. the components claims 1.2 compatibility. i'd prefer either a 1.2 JDK to be used or X-Compile-Source-JDK: 1.2 X-Compile-Target-JDK: 1.2 to be added to the MANIFEST.MF. - robert signature.asc Description: This is a digitally signed message part
Re: [PROPOSAL] Move Commons Proxy to Proper
On Mon, 2006-05-08 at 20:30 +0200, Joerg Hohwiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, James Carman wrote: Outside projects (currently my Syringe project and the Crispy project at sourceforge) are beginning to want to use Commons Proxy, but are finding it difficult since it's in the sandbox and no releases are available. I believe Proxy's API is close to being ready for a release candidate. Moving it to the proper will help us prepare it for an official release. There are some classes that I might remove altogether, since they feel rather frameworky (the CachedProvider is one of them). I've cut/signed a mock 1.0 release and it can be found in my home directory (/home/jcarman/commons-proxy-1.0-release) on www.apache.org. Can you folks take a look at it and let me know what you think? A little late on this but anyways... Just to meantion that the framework of my open-source project at sourceforge is also looking at commons-proxy. I would apreciate if proxy would move to proper. It looks quite stable and ready to use for me... i'm generally in favour - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] JCL 1.1 FC available for final checks
i've uploaded JCL1.1FC to http://people.apache.org/~rdonkin/commons-logging/. it's not yet available through the distributions and it will be a day or two before the mirrors sync and i issue the official announcement. so, please check that i have made no errors in cutting the candidate (ideally by dropping the jar in as a replacement for a RC or 1.0.4) and report back promptly if i have made any mistakes whilst cutting the distribution. thanks for everyone's hard work in getting this release out :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Release RC11 As Jakarta Commons Logging 1.1
i count the votes as follows - binding votes: +1 Robert Burrell Donkin +1 Henri Yandell +1 Simon Kitching +1 Torsten Curdt +1 Rahul Akolkar non-binding votes: +1 Dennis Lundberg +1 Jörg Schaible please check this tally and post corrections for any mistakes. if there are no objections before 2000 hours GMT tomorrow Tuesday 9th May i will cut Jakarta Commons Logging 1.1. - robert signature.asc Description: This is a digitally signed message part
Re: [*] History of Commons
On Wed, 2006-05-03 at 09:44 -0700, Henri Yandell wrote: I don't think anythings written down, so the direction would be personal interviews, svn logs and mailing list history. +1 the ASF is self-recording: we try to keep our development as open and public as possible. Did anybody write down the history of Jakarta Commons? I couldn't find anything. Because of the charter 1.0 I suppose it started in March 2001. The first release I found was made in July 2001 (collections). Maybe I can get more detailed information, but where? the early history is recorded on the [EMAIL PROTECTED] unfortunately, i'm having problems finding a public archive for this list. if you need information from this list, i'll see if we can archive it. the list is then split into http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/ and http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/ and continues to the present. the pre-history of jakarta-commons (the events leading up the formation of the commons) is to be found on http://mail-archives.apache.org/mod_mbox/jakarta-general/ plus the (private) pmc and board lists. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r399792 - /jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml
On Thu, 2006-05-04 at 20:38 +0200, Dennis Lundberg wrote: The tags does not seem to be in sync, see some examples below... [EMAIL PROTECTED] wrote: Author: rdonkin Date: Thu May 4 10:46:51 2006 New Revision: 399792 URL: http://svn.apache.org/viewcvs?rev=399792view=rev Log: Updated contents. Snippet is generated from a stylesheet. Will commit stylesheet to committers later. Modified: jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml Modified: jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml?rev=399792r1=399791r2=399792view=diff == --- jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml (original) +++ jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml Thu May 4 10:46:51 2006 @@ -26,13 +26,90 @@ /properties body - section name='Contents' - ul - liContents/li - lia href='#Using JCL Diagnostics'Using JCL Diagnostics/a/li - lia href='#Containers With Custom LogFactory Implementations'Containers With Custom LogFactory Implementations/a/li - /ul - /section +section name=Contents +ul +li +a href=#ContentsContents/a +ul/ +/li An empty ul followed by end li??? Perhaps you meant /li /ul it's generated using a style sheet: good for ensuring all the contents are accurate but the xml isn't as pretty as it might be. (hence the empty list when there are no subsections.) i didn't think it did much harm but i'll tidy it up by hand. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] Final checks please for RC11
please check the trunk preferably by building and checking the distribution. i plan to cut the release candidate sometime around 2200 hrs UTC. i will call a vote as soon as the candidate is posted. - robet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Final checks please for RC11
On Thu, 2006-05-04 at 23:02 +0200, Dennis Lundberg wrote: robert burrell donkin wrote: please check the trunk preferably by building and checking the distribution. i plan to cut the release candidate sometime around 2200 hrs UTC. i will call a vote as soon as the candidate is posted. I did a clean checkout and everything builds like it should. Doing this required me (the builder) to create a copy of build.properties.sample. This file has as its default location for jars lib/... Faced with the task of setting things up for the first time I had an idea. The building instructions says to first run 'maven site' and then 'ant dist'. How about using the users local Maven repository as default values for the jars? the default values were chosen so that they could be populated by calling 'ant getlibs'. i've added some explanatory notes. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release RC11 As Jakarta Commons Logging 1.1
RC11 contains fixes to a few speilings and improvements to the documentation (thanks dennis). RC11 is available from: http://people.apache.org/~rdonkin/commons-logging. I will tally votes no earlier than 2400 hours GMT Sunday 7th May. here's my +1 - robert --8--- [ ] +1 Release Candidate 11 As JCL 1.1 [ ] +0 Positive but have not had time to check release [ ] -0 Negative [ ] -1 Do not release Candidate 11 AS JCL - signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release RC10 As Commons Logging 1.1
On Tue, 2006-05-02 at 22:27 +1200, Simon Kitching wrote: Hi, To save people reading through below, my summary is: summary Some excellent proofreading here, and a number of doc/release-notes issues have been found by Dennis, as well as a case where we could use constants instead of inline strings, and one where we should technically be using a param value instead of a constant in a diagnostic message (though it doesn't matter in that case anyway). However I don't see anything here that I think is worth cancelling the RC10 vote for. A few items would be good to put up on the wiki under 1.1 release addendum. an interesting one, this the release process we use here in the commons (release candidates rather than blessing a concrete distribution) means that there are always changes between the final release candidate and the release distributed. the question is what changes are acceptable and which necessitate another VOTE. we already have changes to the documentation and some to the code formatting committed. more changes (as outlined by dennis) shouldn't really effect the result: either no changes above the minimum version changes are acceptable or cosmetic and documentation ones are. it feels like a long, long we've travelled. after all this effort, i think one final push is worth it. given the fact that the changes are cosmetic and documentation, i think i'll cut one more candidate tomorrow but propose a short length for the vote. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] activation and javamail
FWIW geronimo has a clean room implementation of the 1.3 specification. they have a lot of spec implementations: it's a pity they aren't more widely available. - robert On Tue, 2006-05-02 at 18:08 -0700, Carlos Sanchez wrote: I had put them in ibiblio, will be available soon On 5/2/06, Henri Yandell [EMAIL PROTECTED] wrote: Downloads okay, though a bit of noise from cookies. Meant increasing the version that commons-email depends upon (or at least is compiled against). Currently the unit tests are hanging though, on the EmailTest. Hen On 5/2/06, Torsten Curdt [EMAIL PROTECTED] wrote: Hurray! http://weblogs.java.net/blog/kohsuke/archive/2006/05/javamail_and_ac.html Could someone add that to email, please? cheers -- Torsten - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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: [VOTE] Release RC10 As Commons Logging 1.1
On Wed, 2006-05-03 at 22:32 +0200, Dennis Lundberg wrote: robert burrell donkin wrote: On Tue, 2006-05-02 at 22:27 +1200, Simon Kitching wrote: Hi, To save people reading through below, my summary is: summary Some excellent proofreading here, and a number of doc/release-notes issues have been found by Dennis, as well as a case where we could use constants instead of inline strings, and one where we should technically be using a param value instead of a constant in a diagnostic message (though it doesn't matter in that case anyway). However I don't see anything here that I think is worth cancelling the RC10 vote for. A few items would be good to put up on the wiki under 1.1 release addendum. an interesting one, this the release process we use here in the commons (release candidates rather than blessing a concrete distribution) means that there are always changes between the final release candidate and the release distributed. the question is what changes are acceptable and which necessitate another VOTE. we already have changes to the documentation and some to the code formatting committed. more changes (as outlined by dennis) shouldn't really effect the result: either no changes above the minimum version changes are acceptable or cosmetic and documentation ones are. it feels like a long, long we've travelled. after all this effort, i think one final push is worth it. given the fact that the changes are cosmetic and documentation, i think i'll cut one more candidate tomorrow but propose a short length for the vote. +1 None of the changes that I have committed affect the actual running code of JCL. The changes made are: - Corrections and additions to JavaDoc - Corrections to documentation (xdocs) - Code formating regarding white space (transforming tabs into spaces) yep: it's more of a procedural issue. if we hadn't been working on this release for so long i'd probably been happy just to tally the votes... i have some more troubleshooting documentation which is yet to be tidied up and committed. i'd be grateful if you could find the time to check careful any changes i make. I deliberately did not check in the proposed *code* changes in LogFactory and LogFactoryImpl. As Simon correctly stated they really don't bring any added value. They are more design issues. yeh - i appreciate that :) Also I have not committed the proposed changes/additions to the RELEASE_NOTES.txt. If there will be another RC then these changes should be committed. - Upgrade recommendations for the api jar (Tomcat vs all others) - The api jar still contains Jdk14Logger - AvalonLogger no longer implements serializable please check my commits - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Committer criteria
On Mon, 2006-05-01 at 10:46 -0700, Henri Yandell wrote: I've been pondering if our critieria for granting committership is out of date. i'm not sure that we really have any objective criteria: just a subjective tradition :) personally speaking, i will not nominate a new committer unless i am convinced that i have the time to provide oversight and help for as long as i think i can be of assistance. this is also a considerable investment of my energy so i need to be convinced that it will be worth it. this means i need to be able to form a judgement from a number of contributions. i prefer to wait until those contributions demonstrate an understand of the way that apache and jakarta works. i am very liberal in supporting karma for committers already at apache. snip So, for people like Chris who are actively trying to get involved, are we setting a bar that just causes us pain? I don't think there are any social or legal issues that say we have to wait on people to submit a bunch of patches, and who cares if we end up with yet more inactive committers, each active committer will be worth 9 inactive ones. a few observations 1 infrastructure would definitely care: ATM every committer requires shell and a quantity of setup. both stress our limited volunteer infrastructure. hopefully this issue should go away sometime soon. 2 it is very possible some members may have philosophical objections to committership being given away too freely. some other notable projects set high bars for committers. 3 would this increase worries about oversight? allowing committers without a track record would need a lot more active supervision. it may just displace the issue. if there aren't enough people willing to patch the codebase, then are there going to be enough to supervise the codebase? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r398696 - in /jakarta/commons/proper/logging/trunk/xdocs: guide.xml tech.xml troubleshooting.xml
thanks :) - robert On Mon, 2006-05-01 at 21:39 +, [EMAIL PROTECTED] wrote: Author: dennisl Date: Mon May 1 14:39:36 2006 New Revision: 398696 URL: http://svn.apache.org/viewcvs?rev=398696view=rev Log: Correct spelling. Modified: jakarta/commons/proper/logging/trunk/xdocs/guide.xml jakarta/commons/proper/logging/trunk/xdocs/tech.xml jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml Modified: jakarta/commons/proper/logging/trunk/xdocs/guide.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/guide.xml?rev=398696r1=398695r2=398696view=diff == --- jakarta/commons/proper/logging/trunk/xdocs/guide.xml (original) +++ jakarta/commons/proper/logging/trunk/xdocs/guide.xml Mon May 1 14:39:36 2006 @@ -344,7 +344,7 @@ /subsection subsection name=Serialization Issues pPrior to release 1.0.4, none of the standard Log implementations were -Serializable. If you are using such a release and have a Serializable classe +Serializable. If you are using such a release and have a Serializable class with a member that is of type Log then it is necessary to declare that member to be transient and to ensure that the value is restored on deserialization. The recommended approach is to define a custom Modified: jakarta/commons/proper/logging/trunk/xdocs/tech.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/tech.xml?rev=398696r1=398695r2=398696view=diff == --- jakarta/commons/proper/logging/trunk/xdocs/tech.xml (original) +++ jakarta/commons/proper/logging/trunk/xdocs/tech.xml Mon May 1 14:39:36 2006 @@ -173,12 +173,12 @@ This guide is aimed at describing the technologies that JCL developers and expert users (and users who need to become experts) should be familiar with. The aim is to give an understanding whilst being precise but brief. - Details which are not relevent for JCL have been suppressed. + Details which are not relevant for JCL have been suppressed. References have been included. /p p - These topics are a little difficult and it's easy for even experience developers to make - mistakea. We need you to help us get it right! Please submit corrections, comments, additional references + These topics are a little difficult and it's easy for even experienced developers to make + mistakes. We need you to help us get it right! Please submit corrections, comments, additional references and requests for clarification by either: /p @@ -356,7 +356,7 @@ a href='http://java.sun.com/docs/books/vmspec/'VMSpec/a emThe Java Virtual Machine Specification, Second Edition/em /li li - a href='http://java.sun.com/docs/books/jls/'LangSpec/a emThe Java Language Specification Second Edition/em + a href='http://java.sun.com/docs/books/jls/'LangSpec/a emThe Java Language Specification, Second Edition/em /li /ul /subsection @@ -387,7 +387,7 @@ p strongNote:/strong the term child-first (though commonly used) is misleading. A better term (and one which may be encountered on the mailing list) is parent-last. - This more accurately describes the actual process of classloader performed + This more accurately describes the actual process of classloading performed by such a classloader. /p p @@ -448,14 +448,14 @@ codeThread.setContextClassLoader/code/a emphasizes the setting of the context classloader as an aspect of thread creation. However, in many applications the context classloader is not fixed at thread creation but - rather is changed throughout the life of thread as thread execution moves + rather is changed throughout the life of a thread as thread execution moves from one context to another. This usage of the context classloader is particularly important in container applications. /p p For example, in a hypothetical servlet container, a pool of threads is created to handle HTTP requests. When created these threads have their - context classloader set to a classloader that loads container classes. + context classloader set to a classloader that loads container classes. After the thread is assigned to handle a request, container code parses the request and then determines which of the deployed web applications
Re: [VOTE] Release RC10 As Commons Logging 1.1
On Thu, 2006-04-27 at 14:06 +0100, sebb wrote: On 27/04/06, Simon Kitching [EMAIL PROTECTED] wrote: On Wed, 2006-04-26 at 21:34 +0100, robert burrell donkin wrote: after some investigation, the issue which turned up with RC8 was determined not to be a bug. notes have been added to the troubleshooting documentation. RC10 is available from: http://people.apache.org/~rdonkin/commons-logging. please download, check and then vote. What's the file commons-logging-1.1-RC10-ide.zip in commons-logging-1.1-RC10.zip for? for IDEs that support a source zip for libraries The files in it don't have the leading directory name which is present in the top-level zips. yep AIUI that's the format they require - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release RC10 As Commons Logging 1.1
On Thu, 2006-04-27 at 11:59 -0700, Henri Yandell wrote: On 4/27/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-27 at 14:06 +0100, sebb wrote: On 27/04/06, Simon Kitching [EMAIL PROTECTED] wrote: On Wed, 2006-04-26 at 21:34 +0100, robert burrell donkin wrote: after some investigation, the issue which turned up with RC8 was determined not to be a bug. notes have been added to the troubleshooting documentation. RC10 is available from: http://people.apache.org/~rdonkin/commons-logging. please download, check and then vote. What's the file commons-logging-1.1-RC10-ide.zip in commons-logging-1.1-RC10.zip for? for IDEs that support a source zip for libraries Maven does them as a source jar - anyone know if there's a reason for the jar rather than zip extension in some of the iDEs? It also has a javadoc jar for IDEs. the jar's all-in-one (combined source+javadocs) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] Maven 1.0 vs. 2.0
On Fri, 2006-04-14 at 10:26 -0400, James Carman wrote: Robert Burrell Donkin suggested that I make it a proposal rather than a vote. sorry - my advice didn't prove too good, i'm afraid :-/ i've been busy and your proposal got buried in loads of general commons emails. (need to add another filter). i hope to take a look at it today. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Move Commons Proxy to Proper
On Fri, 2006-04-14 at 12:06 -0400, James Carman wrote: Outside projects (currently my Syringe project and the Crispy project at sourceforge) are beginning to want to use Commons Proxy, but are finding it difficult since it's in the sandbox and no releases are available. I believe Proxy's API is close to being ready for a release candidate. Moving it to the proper will help us prepare it for an official release. There are some classes that I might remove altogether, since they feel rather frameworky (the CachedProvider is one of them). I've cut/signed a mock 1.0 release and it can be found in my home directory (/home/jcarman/commons-proxy-1.0-release) on www.apache.org. just a FYI you account is on minotaur which is always people.apache.org. ATM it's also www.apache.org but ajax is also sometimes used. be easier for folks if you could add the material into public_html in your home directory so it's can be downloaded easily using a browser (http://people.apache.org/~jcarman). sigs and sums look fine to me. i can't find your key on pgp.mit.edu. if you haven't uploaded it, please do. a copy of your public key (but not your private) should also be in your home directory saved as .pgpkey. see http://www.apache.org/dev/release-signing.html for more details on signing releases. hope to be able to provide some more feedback at the weekend - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release RC10 As Commons Logging 1.1
after some investigation, the issue which turned up with RC8 was determined not to be a bug. notes have been added to the troubleshooting documentation. RC10 is available from: http://people.apache.org/~rdonkin/commons-logging. please download, check and then vote. i will tally the votes no earlier than 2300GMT Wednesday 3rd Mat 2006 here's my +1 - robert -- 8 - [ ] +1 Release Candidate 10 As JCL 1.1 [ ] +0 Positive but have not had time to check release [ ] -0 Negative [ ] -1 Do not release Candidate 10 AS JCL signature.asc Description: This is a digitally signed message part
[ANNOUNCEMENT] Commons Logging 1.1 Release Candidate 10 Available
Jakarta Commons Logging 1.1 Release Candidate 10 is now available. Distributions can be downloaded from: http://people.apache.org/~rdonkin/commons-logging jars are also available from the http://cvs.apache.org/repository/ repository. Please download, check and test this candidate. Robert signature.asc Description: This is a digitally signed message part
RE: [logging] diagnostics, RC failure in webapp
On Wed, 2006-04-19 at 10:50 +0200, Jörg Schaible wrote: Simon Kitching wrote on Wednesday, April 19, 2006 10:26 AM: On Wed, 2006-04-19 at 08:17 +0200, Jörg Schaible wrote: [snip] Well, I have the funny situation the other way round! Due to some plugins in Eclipse's DTP subproject, Eclipse can no longer launch the internal help, that is based on a Tomcat 4.x, because Log is no longer compatible with Log. I can only get the help running if I use a complete cl-1.0.4.jar as replacement for the -api version ... [snip] Is this tomcat 4.0.x or 4.1.x? I believe that tomcat 4.1.x effectively prevents overrides of JCL classes, ie that it's not possible to get duplicate Log classes. So I'm guessing this is tomcat 4.0.x you're dealing with. And yes, that will have problems with duplicate Log classes. In that case I believe the solution is really to deploy a commons-logging-adapters.jar in the webapp (ie a jar with ONLY adapter classes, no Log/LogFactoryImpl). Unfortunately there is no such jarfile in prior JCL releases; only JCL1.1 has such a jar. As you say, the alternative is to put a complete jarfile in tomcat (and delete the one from the webapp I presume). The Eclipse bundle claims Tomcat to be 4.1.130 and because of the bundle mechanism I will had to copy the commons-logging-1.0.4.jar over the contained commons-logging-api.jar. But remember, this is a pathologic case triggered by some interacting plugins with probably invalid extension point definitions. I just mensioned it, since Robert claimed, that such an action should never be done. i think they were simon's words but i snipped too much context (sorry). they were meant to refer only to tomcat 5.x. For me it was the only solution getting Eclipse help working again. yeh - with tomcat 4.x and 3.x putting complete libraries (full JCL plus log4j) in the top classloader was usually the quickest way of getting stuff working. looks like it won't work very well for tomcat 5.x (though). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395181 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
On Wed, 2006-04-19 at 21:09 +1200, Simon Kitching wrote:
Hi Robert,
As you can see I've had a go at fixing the odd diagnostic message. I'd
be grateful if you could double-check this sometime.
The initial code did:
// match package plus first 4 chars
if (candidate.regionMatches(true, 0, name, 0, 38)) {...}
I presume the 38 was meant to be
length(org.apache.commons.logging.impl.) + 4.
However that works out to be 32+4=36. So the old code was actually
testing the first 6 chars.
I decided to make the code a little more self-explanatory (defined
constants etc) and went with the 4 chars as stated by the comment,
rather than the 4 chars as implemented.
the comment's wrong: Jdk13Lumberjacklog and Jdk14Logger have the same
first 4 characters. 5 should be enough. (will need to check this when i
can find the time)
I also switched from candidate.regionMatches(true, 0, name, ..) to
name.regionMatches(true, 0, candidate, ...). Actually, on hindsight that
wasn't necessary; I had another test in there for a while which used
name and therefore made them all consistent. However
x.regionMatches(.., y, ..) and
y.regionMatches(.., x, ..)
are both the same, yes? (as long as x and y are both non-null which they
always are).
+1
Also, rather than trimming the user-specified classname only before
doing diagnostic output, the name is now trimmed within the
findUserSpecifiedLogClassName.
+1
looks good
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] diagnostics, RC failure in webapp
On Mon, 2006-04-17 at 20:48 +1200, Simon Kitching wrote:
snip
Conclusions:
There isn't really anything wrong with the current RC8 code, except for
the diagnostic message Foo unusable; did you mean Foo?, and the docs.
(Well, there was one bug I spotted by coincidence, where priority field
in first commons-logging.properties file was ignored; that's been
fixed).
I'll update JCL docs to say that tomcat's
${tomcat.home}/bin/commons-logging-api.jar must never be replaced with a
full jarfile.
+1
probably needs to go in the release notes too
I'm also planning to fix the minor diagnostic message issue in the next
hour or so.
And we should probably double-check behaviour of 1.1 adapter classes
when loaded by an old JCL version.
+1
it doesn't look like i'll be able to find the time i need for another
candidate before early next week.
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [VOTE] Release Commons Logging 1.1 (RC8)
an issue has been reported by simon with this release candidate. i think it best to abandon this VOTE. i'll post another release candidate once this issue has been resolved. - robert On Mon, 2006-04-10 at 21:38 +0100, robert burrell donkin wrote: Commons Logging 1.1 has been in development for 18 months. It has now reach it's 8th release candidate and it's second release VOTE. It's a long road but I'm convinced that the effort will prove worthwhile. The release candidate can be found here: http://people.apache.org/~rdonkin/commons-logging/. Note that the candidate contains the Jdk14Logger in the API jar to allow backwards compatibility for tomcat 5. Please check carefully before casting your vote. Here's my +1 - robert --8 [ ] +1 Release Jakarta Commons Logging 1.1 [ ] +0 Positive but can't find the time to check the release properly [ ] -0 Negative but not willing to block the release [ ] -1 Do Not Release Jakarta Commons Logging 1.1 -- signature.asc Description: This is a digitally signed message part
Re: [logging] Odd behaviour with 1.1-RC8
On Thu, 2006-04-13 at 22:30 +1200, Simon Kitching wrote: Hi, Unfortunately I have to report what appears to be a problem with 1.1-RC8. I haven't quite got to the cause of this issue yet, but as I'm unsure whether I'll have time over this Easter break to look into it I thought I should briefly describe it here. Setup: Tomcat 5.5.15, Java1.5, Windows. A webapp has commons-logging-1.0.4 and log4j-1.2.13 in its WEB-INF/lib directory. The webapp has a commons-logging.properties file specifying Log4JLogger. Everything works fine. Replacing tomcat's bin/commons-logging-api.jar file with commons-logging-1.1-RC8 causes the webapp to throw a LogConfigurationException on startup. Enabling diagnostics indicates that attempting to load class Log4JLogger causes NoClassDefFound on org.apache.log4j.Category. This class is *definitely* present in the log4j-1.2.13.jar file. Amusingly, the error message reported is: quote org.apache.commons.logging.LogConfigurationException: User-specified log class 'org.apache.commons.logging.impl.Log4JLogger' cannot be found or is not useable. Did you mean 'org.apache.commons.logging.impl.Log4JLogger'? /quote which isn't terribly helpful :-) mea culpa the last sentence in the message is added when the name of the custom implementation is similar. helps to catch mispeilings. when the name is identical to one of the usual suspects, should append a different message. i'll apply a fix (unless you get their first) I'm guessing that although the commons-logging.properties file is being found in the webapp, the Log4JLogger class is being loaded from the commons-logging jarfile in tomcat's bin directory (SYSTEM classloader), not the webapp classloader, hence log4j classes not being found. I don't understand why this would be, but it's the best theory at the moment. this sounds very plausible perhaps 1.0.4 doesn't check the child classloader for the commons-logging.properties file and instead defaults to using java.util.logging. extra logic was added to 1.1 in this area so perhaps this configuration is picked up now. not sure why the context classloader isn't loading the log from the jar in the web application, though. The situation is occurring in a real-life app which is too complicated to post here. I'll try to emulate it in a simpler test case when I have time. While reading the diagnostics output, I've noticed that there could be some improvement in this area. This isn't important enough to hold back release by itself, but if we're doing more work I might tweak this output too. i plan to post something to the list cancelling the vote so please go ahead. if you could update the troubleshooting document with any traces that have change that'd be great. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote SCXML to Proper
On Wed, 2006-04-12 at 12:42 -0400, Sandy McArthur wrote: -0 because for me, and mentioned by some others, the name scxml is so opaque. When I look at the name I have no clue what it is. I know it's verbose but simply expanding the SC to StateChartXML would change my mind to full support. (The StateChartXML name would be the same length as Configuration.) +1 i also prefer statechartXML or even commons-statechart i think that this will also help to attract users: it's not obvious what scxml means. given that jakarta is very well indexed by google, users looking for an scxml implementation will find commons-statechart. users browsing or looking for a general state management tool may not. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote SCXML to Proper
On Mon, 2006-04-10 at 23:08 +0100, Stephen Colebourne wrote: Oh, this is a tough one... - library-ness - if this were a library that assisted with state handling, with an optional ability to read from the scxml format, then that might fit better with a commons library style component an interesting point i see no reason why a component should be discounted just because it implements a specification but what we're looking for is a good component which happen to be useful for a specification. this is associated with the naming: we're more interested in a good lightweight state machine library than the fact that it can be loaded from a SCXML document. stephen's point about the naming is related: the component should be a lightweight state engine first and foremost. so commons-state would be more descriptive. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] redux: include jdk logger in API jar?
On Mon, 2006-04-10 at 17:19 +1000, Torsten Curdt wrote: The documentation for 1.1 makes it clear that the -api.jar has no real purpose, and should generally be avoided. Hopefully we can encourage the next tomcat release to include the full JCL 1.1 jar. The price paid is just mild offense to purists, who *are* correct that this class doesn't really belong in a jar labelled api. Right now, I'm rather tired of JCL (and I'm sure Robert feels worse). Anything that gets this out the door without any more debate and testing is good! So many RCs I can feel your pain, guys (thanks for pushing it through anyway) As for the inclusion: as long as we clearly state that the use from the API jar is deprecated and it will be gone (from the API jar) in the next release it should be ok. luckily i managed to add a comment for RC8 before cutting it. take a look at the language and feel free to dive if it isn't strong enough. i hope to put RC8 to the vote this week but i see no reason not to improve the documentation. ...at some stage we should just fix this. +1 one problem is that it's a transitional time over at tomcat: active development is moving over to tomcat 6. tomcat 6 should ship a statically bound custom JCL implementation created by costin. but will probably be a tomcat 5 release or two before this happens. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Commons Logging 1.1 (RC8)
Commons Logging 1.1 has been in development for 18 months. It has now reach it's 8th release candidate and it's second release VOTE. It's a long road but I'm convinced that the effort will prove worthwhile. The release candidate can be found here: http://people.apache.org/~rdonkin/commons-logging/. Note that the candidate contains the Jdk14Logger in the API jar to allow backwards compatibility for tomcat 5. Please check carefully before casting your vote. Here's my +1 - robert --8 [ ] +1 Release Jakarta Commons Logging 1.1 [ ] +0 Positive but can't find the time to check the release properly [ ] -0 Negative but not willing to block the release [ ] -1 Do Not Release Jakarta Commons Logging 1.1 -- signature.asc Description: This is a digitally signed message part
Re: [VOTE] Promote SCXML to Proper
On Sat, 2006-04-08 at 17:45 -0400, Rahul Akolkar wrote: snip i've had a think and i'm +1 -- [X] +1 Move [scxml] to Commons Proper [ ] +0 I am fine with this move [ ] -0 I am not too keen, because ... [ ] -1 I am against this move, because ... -- there seems to be plenty of user traffic: hopefully some of this will be translated into developer activity. it's probably the most actively developed sandbox component and looks reasonable polished. it's used elsewhere at apache. the scope may (at first glance) be a little problematic. it's an implementation of an specification. not all implementations of that specification would be suitable for the commons. however, i think the SCXML codebase is sufficiently brick-ish to qualify. it's a small engine with minimal dependencies (several of the other xml components here are similar). it's a library which isn't a framework. good enough for me. perhaps this could be made a little clearer in the proposal: i'd prefer a tighter definition perhaps talking about a lightweight engine. This VOTE will remain open for a minimum of 72 hours. seems very short: best to allow at least a week. i also prefer noting a time. - robert signature.asc Description: This is a digitally signed message part
RE: [VOTE] Release Commons Logging 1.1 (RC8)
On Mon, 2006-04-10 at 17:01 -0400, Gary Gregory wrote: Hello: What about generating the web site? In particular, I'd like to see the release notes that detail the changes from the previous versions. http://people.apache.org/~rdonkin/commons-logging/docs/ - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Commons Logging 1.1 Release Candidate 8 Now Available
Release Candidate 8 for the 1.1 release of Jakarta Commons Logging is now available: http://people.apache.org/~rdonkin/commons-logging/ http://cvs.apache.org/repository/commons-logging/jars/ Please download and check this candidate and report any defects. If no defects are found then this release will be proposed for election early next week. Robert signature.asc Description: This is a digitally signed message part
Re: [logging] RC on ibiblio ?
On Wed, 2006-04-05 at 20:41 +1200, Simon Kitching wrote: On Wed, 2006-04-05 at 10:05 +0200, Nicolas De Loof wrote: Hello, Can someone upload commons-logging RC on Maven2 ibiblio repository ? It would be very cool to also upload a POM and the sources jar... That would be a good idea. sadly policy dictates that we can't upload release candidates to ibiblio We should also provide a link on the downloads page or something similar. Just today a work colleague was looking for a later version than 1.0.4 in order to get log4j TRACE support. I told him there was an RC out, but there was just no way for him to locate it... i've been at work off list and things look good. i think i'm just about ready to cut the final release candidate this weekend and try a release vote. By the way, there is still an outstanding discussion about whether to add JDK14Logger back into the commons-logging-api.jar file. It was there in the previous release. It probably shouldn't be; it's not logical. However it does no harm as far as I can see, and the point was made that because the current RC doesn't include it, it isn't a drop-in replacement. yep i agree that it's not logical but ATM it would be good to ship a fixed replacement. it's likely that tomcat 6 will ship a JCL library created by costin which is static bound to java.util.logging. So I'm +1 on adding JDK14Logger back to the api jar, then cutting a new RC and uploading to ibiblio + linking from useful places. Alternatively, we could just make the above change then hold a release vote. I think we've given this RC enough time for feedback. i've got the feedback i wanted now (off list) so i think the time is right to cut another release candidate and hold a release vote next week. i'll probably give the vote two weeks this time. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Author tags [was Line width and such minutiae]
On Tue, 2006-04-04 at 09:16 -0700, Henri Yandell wrote: On 4/2/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/2/06, Sandy McArthur [EMAIL PROTECTED] wrote: For me that falls apart in two places: 1. authorship != ownership, this is made clear by the file's header. 2. subversion contains enough information to target critical contributors. In my mind that is like worrying about a second story window that may be unlocked when your front door is off the hinges. Subversion does indeed contain plenty of information. However, lawyers don't understand source control systems, but they do understand plain text. A technical perspective isn't what's important here; what lawyers understand, and what is supported by legal precedent, is. That's where the board is coming from, backed by legal advice. There's also a difference between push and pull, I believe. We are publishing/distributing the author names in the javadoc/source - we don't publish the subversion data. AIUI copyright is not the key issue here and (so) not ownership or authorship. the ASF tries to ensure that there is a public record of the entire process so that this should be clear and transparent. so, ownership and authorship should not be in doubt. however, the intent may be. use of the author tag was thought to increase the chance of a court ruling that when the source was created, the contributor intended to work for themselves rather than on the ASF's behalf. not sure how strong this argument would be but (since it was only a recommendation) quite possibly not very. but if you're interested in the legal side of this issue, it might be worth raising this on legal discuss when things are a little quieter than now... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [svn] Error validating server certificate for https://svn.apache.org:443
On Tue, 2006-04-04 at 16:19 -0400, Sandy McArthur wrote: On 4/4/06, Gary Gregory [EMAIL PROTECTED] wrote: I am getting the following in Eclipse when trying to update from SVN: Error validating server certificate for https://svn.apache.org:443: - Unknown certificate issuer subversion does not ship with CAs Fingerprint: 19:51:6b:9b:03:78:2b:4b:0f:02:77:ed:2a:85:ef:93:ed:b6:ff:95 19:51:6b:9b:03:78:2b:4b:0f:02:77:ed:2a:85:ef:93:ed:b6:ff:95 looks like a match to me Distinguished name: http://www.starfieldtech.com/repository, Starfield Technologies, Inc., Scottsdale, Arizona, US I am setting up a new PC and I do not recall if I saw this on my old PC. Is this normal That what I see and I remember approving a starfield cert a month or so ago. I cannot vouch for it's legitimacy though. http://www.apache.org/dev/version-control.html looks fine to me - robert signature.asc Description: This is a digitally signed message part
Re: [all] Author tags [was Line width and such minutiae]
Gary Gregory wrote: Based on the February 18, 2004, Apache Software Foundation Board of Directors Meeting Minutes, author tags are discouraged. snip Sandy McArthur wrote: I have searched some and the arguments don't hold water with me. :-) Many things from lawyers and the board don't make sense ;-) here's the only convincing argument i know of: what worries the board (and other open source folks) is the effective destruction of open source projects by targeting (with individual lawsuits) the limited number of critical contributors who do crucial things such as cutting releases. if these individuals are acting on their own behalf, as a non-profit the ASF cannot help them. if they are acting for the ASF then the ASF can defend them in court. so, the trick is setting up a structure which imposes as little friction on development as possible but which allows developers to develop for the ASF rather than on their own behalf. PMC'ers are part of the ASF organisation by their membership of an ASF committee and can bind the ASF to a particular course of action. they should therefore be protected from disruptive litigation by the ASF legal umbrella. committers are not. so, it's important for PMC's so recognise those who make important contributions to the ASF in a reasonably prompt fashion. the question of the policy on author tags is related to this. it was felt that PMC'ers may be weakening the legal argument (that they acting on behalf on the ASF) if they added author tags to the code. might look to a lawyer as if they were working for themselves. that's why recognition elsewhere is fine. note that this argument is only valid for PMC'ers and is not relevant for author tags for other developers. when committing patches from developers who are not committers, it is important that the source of the patch is noted in the commit (so that it can be tracked). I'm proud of the code I've contributed and I think an @author tag is proper recognition. I suppose that five years ago when I joined, I felt something similar. At that time author tags were allowed, so it wasn't a problem. Over time, that desire for such 'base' recognition has gone. You're probably right eventually. When I'm married and have kids I probably won't even remember this but until then I do care with respect to my own contributions. the maven generated team list and commit emails are better indexed (and analysed) than the source. so, as a form of recognition, these generally work better. author tags also seem to attract the wrong kind of recognition: spam from uneducated users (who should be posting their questions to the user list). we've also had arguments in the past about authors who no longer wished to be associated with particular classes. life is usually easier without them. I think the best policy is to stay true to yourself and be tolerant of people with different policies. In my mind that will work today, tomorrow, and up until the earth is swallowed by the sun. that's pretty much my approach. i generally leave author tags alone. for new classes, i add apache as the author. but my opinion is in the minority and i can understand why components with classes with long author lists prefer to insist on the maven team list. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Pool 1.3 based on 1.3-rc4
On Sun, 2006-04-02 at 16:21 -0400, Sandy McArthur wrote: Vote passes. +1 Sandy McArthur Robert Burrell Donkin Phil Steitz (changed from -0) Stephen Colebourne no other votes. I'll tag it, build it, and push it out once I figure out how to. should be covered here http://jakarta.apache.org/commons/releases/release.html it's a good idea to use a [RESULTS] prefix for this kind of mail. for releases, it's best to cc the pmc ([EMAIL PROTECTED]). you'll need to update the jakarta site. if you haven't done this before, you'll need to check out http://svn.apache.org/repos/asf/jakarta/site/ and read the README(s). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r390797 - in /jakarta/commons/proper/pool/trunk/src/test/org/apache/commons/pool/composite: TestCompositeKeyedObjectPoolFactory.java TestCompositeObjectPoolFactory.java
On Sun, 2006-04-02 at 04:04 -0400, Sandy McArthur wrote: FWIW: this commit put the trunk of pool over 90% test coverage according to clover excellent :) - robet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Pool 1.3 based on 1.3-rc4
On Sun, 2006-03-26 at 19:17 -0500, Sandy McArthur wrote: [X] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... - robert signature.asc Description: This is a digitally signed message part
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
On Mon, 2006-03-27 at 19:43 -0700, Phil Steitz wrote: snip/ * testPooling: This test method passes when you run it by itself. It fails because while it looks like it's written to handle either a FIFO or a LIFO pool implementation it doesn't if the GenericObjectPool backing Dbcp has more than 2 idle connections. When the test is run after other tests the GOP contains 4 idle connections. With a LIFO the most recently returned is the first one borrowed so it doesn't matter how many idle connections already exist at the start of the test. Since GOP is now a FIFO the test fails because is incorrectly assumes that a recently returned connection will be the next one borrowed. IMO testPooling should be removed as it really testing Pool's behavior and not Dbcp's behavior. Yes. This is bad and I agree this test case should be removed, as it depends on the implementation of the underlying pool, which is not part of [dbcp]. If there are no objections, I will remove this test case. or replace with a mock pool implementation (if possible) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Pool 1.3 based on 1.3-rc4
On Mon, 2006-03-27 at 02:29 -0500, Sandy McArthur wrote: On 3/26/06, Phil Steitz [EMAIL PROTECTED] wrote: -0 Could be a problem with setup or test itself, but with the 1.3-rc4 jar, I am getting failures in [dbcp] test org.apache.commons.dbcp.TestJOCLed. These tests pass with 1.2. The good news is the other [dbcp] test failures that pool 1.3 is supposed to fix succeed for me. Failures below happen on both Sun Linux JDK 1.5.0_06 and 1.4.2_10. These failures are really a problem with the unit test in Dbcp and not pool. See: http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg77500.html Another small nit is that the RELEASE-NOTES have an old paste reference to [io]. Oops, committed a fix. Assuming nothing else shows up can I just slip the fixes in instead of tagging and building another release candidate? you're the release manager so it's your call :) personally speaking, since it's a minor time, i'd wait a while to see whether any other problems turn up. if so, i'd create another release candidate. even if the dhcp issues is not a pool issue, probably best to wait to make sure (it's a bad feeling having to rush out a fix release). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: anyone working on comments and layout preservation in .properties files item of v1.3 ?
please prefix the subject with the name of the component - robert On Fri, 2006-03-24 at 11:07 +, Horaci Macias wrote: Hi all, I recently wrote custom code to read/write properties file while preserving comments and I've just noticed this is part of one of the items on the roadmap for v1.3. Just wanted to know if anyone else is already working on this to avoid duplication of efforts. If not then I'll try suggesting patches shortly. thanks, Horaci Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Validator 1.3.0 based on RC3
On Fri, 2006-03-24 at 12:44 +, Niall Pemberton wrote: P.S. Oliver isn't on the Jakarta whoweare page, although he was voted on to the PMC in January. sounds like it's time for oliver to add himself... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
