Re: [Jelly] Could jelly be used instead of jsp for JSF development? Would it perform well?
On Thu, 10 Mar 2005 16:12:20 -0600, Jeff Barczewski [EMAIL PROTECTED] wrote: Summary - Could jelly be used instead of jsp for JSF development (givent the proper jelly jsf tags were created)? Would it perform well? I must confess that I've never thought deeply about this idea, so I'm sure that I am missing something in what you have in mind. But a key issue would be whether you can represent components from arbitrary third party JSF component libraries, without requiring the component developer to create a Jelly tag for each of their components. On the other hand, if you're contemplating a generic this is a JSF component Jelly tag, which takes arbitrary attributes to set the underlying component properties, what would this buy you over a straightforward implementation of JSF's ViewHandler API that can read any arbitrary source format that you might like? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-xml (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-xml has an issue affecting its community integration. This issue affects 11 projects, and has been outstanding for 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - maven : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-xml-15032005.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/gump_work/build_commons-jelly_commons-jelly-tags-xml.html Work Name: build_commons-jelly_commons-jelly-tags-xml (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-15032005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-15032005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-15032005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-15032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-15032005.jar - [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 16 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports test:test-resources: Copying 36 files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes
RE: Moving benchmark out of sandbox?
I took a spin around benchmark, and it looked good however.. I think you need some sort of tutorial and demo. Unlike other tools like email,lang, which are very obvious how you use them (Answer: you write code with them!), benchmark is more of a tool. There were references to other tools that I didn't quite get, and maybe some sort of sample report would be good. Maybe run benchmark against the tomcat codebase or something. On a certain level, if my understanding is right that benchmark is a tool, not a library, I somewhat wonder if this shouldn't be out from under commons and part of some sort of jakarta project instead? Building community is tough from the sandbox. However, I have done it with Configuration, (which is really thriving), and to a certain extent with Email, although I need to get some of the contributors voted in as committers. When people express interest, grab 'em! Ask for feedback, take their concerns seriously, and pretty soon you'll be getting patches! Eric -Original Message- From: Kevin A. Burton [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 15, 2005 4:50 AM To: Jakarta Commons Developers List Subject: Re: Moving benchmark out of sandbox? Dion Gillard wrote: Using nightly builds? Thats a step in the right direction I guess ;) I'll setup nightly builds and then blog about the benchmark package and what you can do with it... then build really nice javadoc. I guess I'm getting ahead of myself because I want to integrate it within FeedParser :) Thanks! Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - 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] [email] promote RC4 to 1.0 status
Ugh. Cygwin. Fast way to frustration on windows.. Actually, I just got my new powerbook, so theoretically I can run MacPGP from http://macgpg.sf.net and do it. However, when I generate a new keypair, that means that I'll either have two keypairs, or I just don't use the first one anymore? I haven't signed anything else with it, and haven't cross signed it at all, so theorectically moving to a new keypair is fine, correct? Eric -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, March 14, 2005 6:51 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] [email] promote RC4 to 1.0 status The gpg docs are here http://www.gnupg.org/gph/en/manual.html and yes, you need to generate a keypair first before trying to sign something. I don't know if it is ok to gen and store keys on apache boxes, though. Anyone know? If you can get Cygwin or something equivalent that lets you run gpg and shell scripts locally, you can use the scripts that I added to /committers/releases to create and verify the sigs once you have created the keypair using gpg --gen-key hth, Phil On Mon, 14 Mar 2005 09:56:17 -, Eric Pugh [EMAIL PROTECTED] wrote: I was taking a swing at ascii armour'ing the signatures, and have a couple questions. Following the directions in http://wiki.apache.org/jakarta-commons/SigningReleases, there is a section about using gpg. I logged onto my Apache account, and tried to do the command: gpg --armor --export 'your name' However, nothing gets produced. What I am wondering is if I need to somehow install my key? I followed the PGPMail directions, so my private key is on my windows laptop. Do I need to create using gpg my main key instead? There are some tantalizing mentions in PGPMail's documentation about ascii armouring, but no details on how to do it, just that it exists. Eric -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Friday, March 11, 2005 9:01 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] [email] promote RC4 to 1.0 status hi eric could you ascii armour the signatures? (it's not essential but it makes them a lot nicer to read and download) - robert On Fri, 2005-03-11 at 20:30, Eric Pugh wrote: Hi all, A couple of packaging issues were discovered in Email 1.0 RC3. I was encouraged to fix them and then call for a fresh vote, so I appreciate the understanding of the community that the (now) 4 release candidates it's taken to get email to 1.0. My first time signing a project. The release candidate is available at http://www.apache.org/~epugh/email/distributions/ and is just RC3 with some packaging tweaks, not Java code changes. The documentation is available at http://www.apache.org/~epugh/email/docs This is a full release vote (and so three +1's are required). please check the release before voting +1. i will not tally the votes before 2300 hours GMT on Tuesday 15th of March. here's my +1 - Eric -8- [ ] +1 Promote RC4 to commons-email-1.0 [ ] +0 In favour of this release [ ] -0 Against this release [ ] -1 Do not release RC4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28291] - [logging] ContextClassLoader may load Log impl from wrong context in JDK 1.4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28291. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28291 --- Additional Comments From [EMAIL PROTECTED] 2005-03-15 15:57 --- (In reply to comment #7) If the thread context classloader is adhering to the parent first search behavior, then this would only be a problem if the thread context classloader did not have the current class's classloader in it's hierarchy. I would like to reopen the discussion from this point. The behaviour described above can actually lead (and actually did) to a significant memory leak in the following circumstance: I deploy a web application in Tomcat. The application uses log4j to log, and has commons-logging.jar and log4j.jar in WEB-INF/lib. Tomcat also uses common-loggings. The problem is that I find myslef in the situation where tomcat classes get to use a Log instance loaded by the class loader of my web application (which is, of course, the context class loader during the execution of servlets). This will prevent the web app from being garbage collected when I stop it. The only workaroung for this was to put common-logging.jar and log4j.jar in share/lib instead of WEB-INF/lib, but I'm not really happy with this solution. Could somebody confirm this problem? The guys from Tomcat do not admit this is a bug for them, but I belive this actually affects Tomcat. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Could jelly be used instead of jsp for JSF development? Would it perform well?
Le 14 mars 05, à 07:08, Craig McClanahan a écrit : On Thu, 10 Mar 2005 16:12:20 -0600, Jeff Barczewski [EMAIL PROTECTED] wrote: Summary - Could jelly be used instead of jsp for JSF development (givent the proper jelly jsf tags were created)? Would it perform well? I must confess that I've never thought deeply about this idea, so I'm sure that I am missing something in what you have in mind. But a key issue would be whether you can represent components from arbitrary third party JSF component libraries, without requiring the component developer to create a Jelly tag for each of their components. See the ant tag-library for this. I think it has less than five classes. I think, Jeff, your suggestion sounds very doable and may be very easy... consider sub-classing UseBeanTag. paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving benchmark out of sandbox?
JRobin is LGPL License: http://www.jrobin.org/license.html http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg55722.html Niall - Original Message - From: Kevin A. Burton [EMAIL PROTECTED] Sent: Monday, March 14, 2005 7:15 AM Has annyone had a chance to take a look at the benchmark project I've been working on? http://jakarta.apache.org/commons/sandbox/benchmark/ I'm really happy with the way everything is turning out and I'd like to move from the sandbox to proper so that I can do a release. Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34020] New: - PropertyUtils.copyProperties seems to call Constructor
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34020. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34020 Summary: PropertyUtils.copyProperties seems to call Constructor Product: Commons Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Bean Utilities AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Using BeanUtils 1.7 I Have two classes X and Y. Y is a subclass of X. Y has a default constructor that initializes some class properties that are NOT present in X (in my example, the constructor creates 2 objects and places them into a map). When I call PropertyUtils.copyProperties(Y,X) what I am finding is the following: The properties of X ARE copied onto Y, no problem. That part works. But Y's constructor seems to get called inside of copyProperties(). (The instance of Y passed in is NOT the same instance of Y that is returned?). In any case, the initializations declared in Y's constructor occured, and blew away the current state on the property that got re-initialized. copyProperties(Y,X) should not have touched this element of Y as it is NOT an element of X. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34020] - PropertyUtils.copyProperties seems to call Constructor
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34020. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34020 --- Additional Comments From [EMAIL PROTECTED] 2005-03-15 18:31 --- Can you attach a test case which demonstrates this behavior? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28291] - [logging] ContextClassLoader may load Log impl from wrong context in JDK 1.4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28291. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28291 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2005-03-15 18:37 --- It's hard to be categorical since there are variations between JVMs. There are known circumstances where 1.0.4 holds references to classloaders in some containers (but not tomcat) preventing recycling of memory in undeployment. It would not surprise me to find that this is one of those circumstances (at least on some platforms). If this is a concern, there are a number of actions you might take (any of which should be effective): 1 If you are going to be hot deploying applications frequently and deploying your logging systems in the child classloader for the web application, then it is a very good idea to add a lifecycle listener to ensure that all logging resources are correctly closed. If you are logging to Log4J, you should be doing this anyway. If you are concerned about releasing references then you should call JCL release during this cleanup. 2 Download the new JCL alpha and install the optional jar. The weak references should allow the memory to be recycled (sooner or later). 3 Reconsider your deployment decision. I'm not sure why you are unhappy to deploy your logging system in share/lib. Logging systems tend to hold a number of resources open for performance reasons. Hot deployment therefore isn't particularly pretty for them. There are sometimes good reasons why people are forced to deploy all libraries in the application loader (perhaps because they do not control the container). In other cases, it's worth considering the best deployment strategy. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r157573 - jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/TestPerformance.java
Author: burton Date: Tue Mar 15 10:35:33 2005 New Revision: 157573 URL: http://svn.apache.org/viewcvs?view=revrev=157573 Log: ... Modified: jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/TestPerformance.java Modified: jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/TestPerformance.java URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/TestPerformance.java?view=diffr1=157572r2=157573 == --- jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/TestPerformance.java (original) +++ jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/TestPerformance.java Tue Mar 15 10:35:33 2005 @@ -47,7 +47,7 @@ double tps = ((double)TEST1_COUNT / (double)bmeta.duration) * 1000D; -assertTrue( Not meeting minimum TPS, tps 20 ); +assertTrue( Not meeting minimum TPS, tps 15 ); //NOW disable the whole thing and trytry again. Benchmark.DISABLED=true; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r157578 - in jakarta/commons/proper/configuration/trunk/xdocs: howtos_index.xml howtos_index_1.0.xml navigation.xml
Author: oheger Date: Tue Mar 15 11:38:05 2005 New Revision: 157578 URL: http://svn.apache.org/viewcvs?view=revrev=157578 Log: Modified xdocs to link to the old and new user guide Added: jakarta/commons/proper/configuration/trunk/xdocs/howtos_index.xml (with props) jakarta/commons/proper/configuration/trunk/xdocs/howtos_index_1.0.xml (with props) Modified: jakarta/commons/proper/configuration/trunk/xdocs/navigation.xml Added: jakarta/commons/proper/configuration/trunk/xdocs/howtos_index.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/xdocs/howtos_index.xml?view=autorev=157578 == --- jakarta/commons/proper/configuration/trunk/xdocs/howtos_index.xml (added) +++ jakarta/commons/proper/configuration/trunk/xdocs/howtos_index.xml Tue Mar 15 11:38:05 2005 @@ -0,0 +1,48 @@ +?xml version=1.0? +!-- + Copyright 2004-2005 The Apache Software Foundation + + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- +document + + properties +author email=[EMAIL PROTECTED]Oliver Heger/author +titleConfiguration howtos index/title + /properties + + body +section name=Howtos + p +Here you can find a short user guide for the Configuration project. +Note that these documents deal with the latest emdevelopment/em version of the +Configuration API, i.e. the main trunk in SVN or the nightly builds. +If you use the latest emreleased/em version, some of the features +described here may not be available. In this case please jump to the +old version of this guide, which can be found +a href=howtos_index_1.0.htmlhere/a. + /p + p +The following doucments are available: +ul + lia href=overview.htmlUsing Configuration/a/li + lia href=howto_properties.htmlProperties Howto/a/li + lia href=howto_configurationfactory.htmlConfigurationFactory Howto/a/li + lia href=howto_xml.htmlXML Howto/a/li + lia href=howto_compositeconfiguration.htmlComposite Config Howto/a/li +/ul + /p +/section + + /body +/document Propchange: jakarta/commons/proper/configuration/trunk/xdocs/howtos_index.xml -- svn:eol-style = native Added: jakarta/commons/proper/configuration/trunk/xdocs/howtos_index_1.0.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/xdocs/howtos_index_1.0.xml?view=autorev=157578 == --- jakarta/commons/proper/configuration/trunk/xdocs/howtos_index_1.0.xml (added) +++ jakarta/commons/proper/configuration/trunk/xdocs/howtos_index_1.0.xml Tue Mar 15 11:38:05 2005 @@ -0,0 +1,40 @@ +?xml version=1.0? +!-- + Copyright 2004-2005 The Apache Software Foundation + + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- +document + + properties +author email=[EMAIL PROTECTED]Oliver Heger/author +titleConfiguration 1.0 howtos index/title + /properties + + body +section name=Howtos + p +Here you can find a short user guide for the Configuration release 1.0. +The following doucments are available: +ul + lia href=howtos_1.0/overview.htmlUsing Configuration/a/li + lia href=howtos_1.0/howto_properties.htmlProperties Howto/a/li + lia href=howtos_1.0/howto_configurationfactory.htmlConfigurationFactory Howto/a/li + lia href=howtos_1.0/howto_xml.htmlXML Howto/a/li + lia href=howtos_1.0/howto_compositeconfiguration.htmlComposite Config Howto/a/li +/ul + /p +/section + + /body +/document Propchange: jakarta/commons/proper/configuration/trunk/xdocs/howtos_index_1.0.xml -- svn:eol-style = native Modified:
DO NOT REPLY [Bug 34022] New: - [chain] Update servlet implementation classes to be aware of CatalogFactory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34022. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34022 Summary: [chain] Update servlet implementation classes to be aware of CatalogFactory Product: Commons Version: 1.0 Final Platform: Other OS/Version: other Status: NEW Severity: major Priority: P2 Component: chain AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] As brought up by Howard Lin in this thread http://thread.gmane.org/gmane.comp.jakarta.commons.devel/63506 the ChainProcessor and related classes were not updated to work with CatalogFactory in the 1.0 release. This should be corrected before the next release of commons-chain. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration]Site update of howtos
Our current site seems to be very confusing for our users as can be seen in multiple postings on the user list. The main reason is probably the user guide (the howtos), which describes the latest version in SVN rather than the 1.0 release, which is used by most users. I have now applied a quick and dirty fix for this situation: I manually uploaded the 1.0 howtos on the server. Then I created two index pages for the old and new howtos and linked to them in the main navigation bar, analogous as for the API docs. In the index page for the SVN howtos there is an explicit warning that this may not be compatible with the latest released version. This is of course only a temporary solution because it requires manual processing on the server. I don't know how we should deal with this problem. Would it make sense to store both the old and new howtos in the xdocs and let maven generate it all? I guess that would be the easiest way. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving benchmark out of sandbox?
Niall Pemberton wrote: JRobin is LGPL License: http://www.jrobin.org/license.html Crap.. I totally forgot about that! I'm going to ask the author if he's interested in a BSD version :) Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] j2ee unit tests added: memory leak demonstrated (?)
Simon, I spent some time last night looking at this, mostly just familiarizing myself with how beanutils works so I could understand the problem. I think you're right to be concerned about JCL, as from what I can see the two applications are very similar: weak-keyed map (aka WeakMap) held statically by class loaded by container (beanutils: BeanUtilsBean.beanByClassLoader; JCL: LogFactory.factories). WeakMap key is the TCCL. WeakMap value is a class loaded by container, but value is instantiated while component loader is the TCCL (beanutils: BeanUtilsBean; JCL: LogFactoryImpl). WeakMap value holds another map (aka StrongMap) (beanutils: BeanUtilsBean.convertUtilsBean.converters; JCL: LogFactory.instances) StrongMap value is a class loaded by the component loader (beanutils: FloatConverter; JCL: Log4jLogger). Class implements an interface loaded by the container loader (beanutils: Converter; JCL: Log). This reference is likely what's preventing release of the classloader in beanutils. I noticed that the JCL unit test I wrote for memory release has a weakness in that it doesn't add the Log instance to LogFactoryImpl.instances. I noticed that a week ago and added the required call so I could check the tests still passed. They did. But, didn't get a chance to clean up the code and submit a proper patch for the tests. My bad :( I'll for sure do that tonight, plus add some more assertions like the beanutils test has in order to ensure that classes are being loaded by the intended loader. This should either surface a problem in JCL or help shed some light on the beanutils problem. Regards, Brian --- Simon Kitching [EMAIL PROTECTED] wrote: Hi, I've just added a unit test o.a.c.beanutils.converter.MemoryTestCase. This test case currently fails, demonstrating (I believe) that there is a serious memory leak in beanutils in j2ee-like environments when components are undeployed. The tests show that if a Converter is registered while Thread.getContextClassLoader is set to a component-specific classloader, then when the component is undeployed that classloader cannot be garbage-collected. The problem is: I can't spot what is *causing* this bug. It would be great if someone else could have a look too. Given the new code in commons-logging that is intended to address a similar issue, I think this is worth resolving before releasing commons-logging 1.0.5 Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration]Site update of howtos
Over in Turbine land we have the advantage of a separate turbine-site project. We have generic site doucmentation, and then the maven generated docs seperated by version: / generic site docs /2.3 /2.3.1 /2.4-M1 And so on. What we could do is have /commons/configuration/ - current site docs symlinked to /commons/configuration/1.0 /commons/configuration/1.1/ -- new site docs /commons/configuration/1.0/ -- old site docs And provide a link to the 1.1 and 1.0 from both projects Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 15, 2005 8:28 PM To: Jakarta Commons Developer List Subject: [configuration]Site update of howtos Our current site seems to be very confusing for our users as can be seen in multiple postings on the user list. The main reason is probably the user guide (the howtos), which describes the latest version in SVN rather than the 1.0 release, which is used by most users. I have now applied a quick and dirty fix for this situation: I manually uploaded the 1.0 howtos on the server. Then I created two index pages for the old and new howtos and linked to them in the main navigation bar, analogous as for the API docs. In the index page for the SVN howtos there is an explicit warning that this may not be compatible with the latest released version. This is of course only a temporary solution because it requires manual processing on the server. I don't know how we should deal with this problem. Would it make sense to store both the old and new howtos in the xdocs and let maven generate it all? I guess that would be the easiest way. Oliver - 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: [lang] 2.1-rc1 take 2 Was: [lang] 2.1 rc (practice)
From: Henri Yandell [EMAIL PROTECTED] Issue-wise; there seemed to be a pretty big issue on encoding for Entities on the user's list. Stephen, any view on whether that's a blocker? I don't really understand the request. I think we would have to get a unit test, and this could take some time and organising. I think we could probably release without this, but I don't really know anything about this area (in fact its one part of [lang] that escaped its original scope IMHO.) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33965] - [lang] Can't XMLDecode an Enum
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33965. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33965 --- Additional Comments From [EMAIL PROTECTED] 2005-03-16 00:00 --- Can you write a test case to clarify the issue for us, thanks. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r157627 - in jakarta/commons/sandbox/benchmark/trunk: project.xml src/java/org/apache/commons/benchmark/rrd/GraphTask.java
Author: burton
Date: Tue Mar 15 18:13:59 2005
New Revision: 157627
URL: http://svn.apache.org/viewcvs?view=revrev=157627
Log:
cactch all throwables:
Modified:
jakarta/commons/sandbox/benchmark/trunk/project.xml
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/rrd/GraphTask.java
Modified: jakarta/commons/sandbox/benchmark/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/project.xml?view=diffr1=157626r2=157627
==
--- jakarta/commons/sandbox/benchmark/trunk/project.xml (original)
+++ jakarta/commons/sandbox/benchmark/trunk/project.xml Tue Mar 15 18:13:59 2005
@@ -83,6 +83,7 @@
unitTest
includes
include**/Test*.java/include
+exclude**/TestPerformance.java/exclude
/includes
/unitTest
Modified:
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/rrd/GraphTask.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/rrd/GraphTask.java?view=diffr1=157626r2=157627
==
---
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/rrd/GraphTask.java
(original)
+++
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/rrd/GraphTask.java
Tue Mar 15 18:13:59 2005
@@ -329,8 +329,8 @@
exec();
generateGraphs();
-} catch ( Exception e ) {
-e.printStackTrace();
+} catch ( Throwable t ) {
+t.printStackTrace();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r157635 - jakarta/commons/proper/chain/trunk
Author: germuska Date: Tue Mar 15 19:14:18 2005 New Revision: 157635 URL: http://svn.apache.org/viewcvs?view=revrev=157635 Log: Add eclipse project files to svn:ignore. Modified: jakarta/commons/proper/chain/trunk/ (props changed) Propchange: jakarta/commons/proper/chain/trunk/ -- --- svn:ignore (original) +++ svn:ignore Tue Mar 15 19:14:18 2005 @@ -1,3 +1,5 @@ dist target *.log +.project +.classpath - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34022] - [chain] Update servlet implementation classes to be aware of CatalogFactory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34022. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34022 --- Additional Comments From [EMAIL PROTECTED] 2005-03-16 05:29 --- This link is a better pointer to the initial statement of the problem: http://thread.gmane.org/gmane.comp.jakarta.commons.devel/63264 I'm attaching a patch and a new class which I think deal with the main issue -- that the catalog is sometimes stored in the request scope instead of in the context -- but I would really prefer someone who is using this stuff to champion this ticket, review the patches and such. I don't have time to build and test a ChainProcessor servlet. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34022] - [chain] Update servlet implementation classes to be aware of CatalogFactory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34022. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34022 --- Additional Comments From [EMAIL PROTECTED] 2005-03-16 05:31 --- Created an attachment (id=14495) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14495action=view) Superclass for mappers to share common behavior. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34022] - [chain] Update servlet implementation classes to be aware of CatalogFactory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34022. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34022 --- Additional Comments From [EMAIL PROTECTED] 2005-03-16 05:32 --- Created an attachment (id=14496) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14496action=view) Patch three *Mapper classes to extend AbstractMapper Since the mappers all work in about the same way, it makes sense to have an AbstractMapper which looks up the commands and just uses a different mechanism for determining the command name. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r157681 - jakarta/commons/proper/lang/trunk/maven.xml
Author: bayard Date: Tue Mar 15 21:05:08 2005 New Revision: 157681 URL: http://svn.apache.org/viewcvs?view=revrev=157681 Log: includes default.properties in src builds now Modified: jakarta/commons/proper/lang/trunk/maven.xml Modified: jakarta/commons/proper/lang/trunk/maven.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/maven.xml?view=diffr1=157680r2=157681 == --- jakarta/commons/proper/lang/trunk/maven.xml (original) +++ jakarta/commons/proper/lang/trunk/maven.xml Tue Mar 15 21:05:08 2005 @@ -44,6 +44,7 @@ include name=NOTICE.txt/ include name=PROPOSAL.html/ include name=STATUS.html/ +include name=default.properties/ /fileset /copy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r157689 - jakarta/commons/proper/commons-build/trunk/menus/downloads.ent
Author: bayard Date: Tue Mar 15 21:17:43 2005 New Revision: 157689 URL: http://svn.apache.org/viewcvs?view=revrev=157689 Log: direct link to commons download page Modified: jakarta/commons/proper/commons-build/trunk/menus/downloads.ent Modified: jakarta/commons/proper/commons-build/trunk/menus/downloads.ent URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/commons-build/trunk/menus/downloads.ent?view=diffr1=157688r2=157689 == --- jakarta/commons/proper/commons-build/trunk/menus/downloads.ent (original) +++ jakarta/commons/proper/commons-build/trunk/menus/downloads.ent Tue Mar 15 21:17:43 2005 @@ -2,7 +2,6 @@ The Download menu element -- menu name=Download -item name=Binaries#xA0;(mirrored) href=http://jakarta.apache.org/site/binindex.cgi/ -item name=Source#xA0;Code#xA0;(mirrored) href=http://jakarta.apache.org/site/sourceindex.cgi/ +item name=Releases#xA0;(mirrored) href=http://jakarta.apache.org/site/downloads/downloads_commons.html/ item name=Nightly#xA0;Snapshots href=http://cvs.apache.org/builds/jakarta-commons/nightly// /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 2.1-rc1 take 2 Was: [lang] 2.1 rc (practice)
On Tue, 15 Mar 2005 22:58:47 -, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Henri Yandell [EMAIL PROTECTED] Issue-wise; there seemed to be a pretty big issue on encoding for Entities on the user's list. Stephen, any view on whether that's a blocker? I don't really understand the request. I think we would have to get a unit test, and this could take some time and organising. I think we could probably release without this, but I don't really know anything about this area (in fact its one part of [lang] that escaped its original scope IMHO.) Agreed on all of that. Let's fix it after 2.1. On the 2.1 release, I've fixed the default.properties not being in the src jar. I've also removed the text package which I had included in the src build (I was doing src builds on one box and binary builds on another). Unzipping the created src.zip, and running both 'ant jar' and 'maven jar' successfully compile/jar. Anything else which should hold up a release? (other than a vote and the time it takes me to stumble my way through a release...) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
