[jira] Commented: (JELLY-177) In JellyServlet, the procedure used to determine the script's location is too simplistic
[
http://issues.apache.org/jira/browse/JELLY-177?page=comments#action_57998 ]
Marc DeXeT commented on JELLY-177:
--
hans Gilde said :
Marc, could you give me an example of someting that works after this change
but not before?
Sure.
It's about url mapping.
I have create a little jelly web library (remind me to ask to create a new
subproject jelly web :)) where you can create a web page as a JSP : include,
forward and so on.
An url is http://myhost:8082/demo/appli.jelly?page=browse.jelly
URL mapping is in WEB-INF/web.xml
...
servlet
servlet-nameJelly/servlet-name
servlet-classfr.dsi.cnrs.jetty.servlet.ImprovedCachedJellyServlet/servlet-class
/servlet
...
servlet-mapping
servlet-nameJelly/servlet-name
url-pattern*.jelly/url-pattern
/servlet-mapping
when such url-mapping is used, the /appli.jelly part of path is not in
javax.servlet.http.HttpServletRequest.getPathInfo() _BUT_ in
javax.servlet.http.HttpServletRequest.getServletInfo().
So I get the script with this last (getServletInfo).
So this improvement (JELLY-177) enable real url-mapping to a jellyServlet.
Do I have answered to you ?
Waht do you think about create a jelly-web sandbox to use jelly script as an
full web application script ? :)
In JellyServlet, the procedure used to determine the script's location is too
simplistic
Key: JELLY-177
URL: http://issues.apache.org/jira/browse/JELLY-177
Project: jelly
Type: Bug
Components: core / taglib.core
Versions: 1.0-beta-5, 1.0-RC1
Environment: Servlet, 1.0RC1
Reporter: Denis Robert
Priority: Minor
Fix For: 1.0-RC2
In JellyServlet, the procedure used to determine the script's location is too
simplistic; it misses simple cases like the a *.jelly servlet-mapping.
I suggest replacing the getScript method with something like (taken in part
from the Freemarker servlet):
protected URL getScript(HttpServletRequest req)
throws MalformedURLException {
String scriptUrl = null;
String includedPath = (String)
req.getAttribute(javax.servlet.include.servlet_path);
if (includedPath != null) { //This is the result of a
RequestDispatcher include...
String includedPathInfo = (String)
req.getAttribute(javax.servlet.include.path_info);
if (includedPathInfo != null) {
scriptUrl = includedPathInfo;
} else {
scriptUrl = includedPath;
}
} else {
scriptUrl = req.getParameter(script);
if (scriptUrl == null) {
scriptUrl = req.getPathInfo();
}
if (scriptUrl == null) {
scriptUrl = req.getServletPath();
}
}
URL url = getServletContext().getResource(scriptUrl);
if (url == null) {
throw new IllegalArgumentException(Invalid script url:
+ scriptUrl);
}
return url;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [contract] Suggestions
Let user decides what form choose to use right? Good, I think is a very good idea!!! If he wants a programmatic or declarative form he only need to decide!! Hi, I've been reading this thread and I think Woody's suggestion to let the user decide is a really good one. It would not even be hard to parse some xml and turn them into Constraints objects. It'd be really great to see some metadata features of Java 1.5 in this project as I think that metadata is perfectly suited for this kind of stuff. But to let the user decide what form to choose could never be a bad thing :) Just my 2c, Matthijs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/jelly maven.xml
Would be fine with that as well. I noticed java:compile isn't invoked if there's no modified java sources... is java:jar-resources invoked every time maven jar is done ? (like, I think this too much btw, test) paul Le 24 janv. 05, à 01:40, Brett Porter a écrit : FYI, a postgoal on java:jar-resources is more appropriate than on java:compile. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-145) jelly -version should answer
[ http://issues.apache.org/jira/browse/JELLY-145?page=history ] Paul Libbrecht resolved JELLY-145: -- Assign To: Paul Libbrecht Resolution: Fixed Fix Version: 1.0-RC2 Now comitted a fix. Thanks to close to confirm. paul jelly -version should answer Key: JELLY-145 URL: http://issues.apache.org/jira/browse/JELLY-145 Project: jelly Type: Improvement Components: core / taglib.core Versions: 1.0-beta-4 Reporter: Paul Libbrecht Assignee: Paul Libbrecht Priority: Critical Fix For: 1.0-RC2 Currently jelly -version responds an exception whereas every normal software would like to have a current version given. This could be assorted to the version of each taglib (e.g. jelly --tagLibVersion=swing). My best wish would be to output this automagically out of the project.xml... I am pretty sure maven users have requested, made, or even standardized this already... thanks paul -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/jelly maven.xml
Paul Libbrecht wrote: Would be fine with that as well. I noticed java:compile isn't invoked if there's no modified java sources... it's always invoked, it only compiles what is changed is java:jar-resources invoked every time maven jar is done ? yes, but only copies what is changed (unless filtering is on) (like, I think this too much btw, test) I'm not sure what you mean here? - Brett paul Le 24 janv. 05, à 01:40, Brett Porter a écrit : FYI, a postgoal on java:jar-resources is more appropriate than on java:compile. - 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]
[jelly] Maven JSL memory leak and Jelly
Hi,
I did some testing and can confirm that the current site generation
memory leak occurs here:
j:file name=${outFile} encoding=${outputencoding}
omitXmlDeclaration=true outputMode=xml
prettyPrint=no
-- j:include uri=${stylesheet.toString()}/
/j:file
If I remove the include, nothing is leaked. So, while this is obviously
a whole lot of additional Jelly (actually, its this:
http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/xdoc/src/plugin-resources/site.jsl);
it is just Jelly - nothing about Maven's context creation AFAICT.
j:include does a context.runScript(uri, output, isExport(),
isInherit()); which is when the caching occurs, right?
So are there any further ideas about where the leak is? IS it the JSL
used in site.jsl, the j:include itself, or something else? Do you need
me to do more narrowing down within site.jsl or does someone have a hunch?
Thanks,
Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/jelly maven.xml
Le 24 janv. 05, à 12:09, Brett Porter a écrit : Paul Libbrecht wrote: Would be fine with that as well. I noticed java:compile isn't invoked if there's no modified java sources... it's always invoked, it only compiles what is changed The postGoal is not invoked... that's my problem. is java:jar-resources invoked every time maven jar is done ? yes, but only copies what is changed (unless filtering is on) There's no copy here, I'm injecting directly into target/classes/... The question is about postGoal invocation. (like, I think this too much btw, test) I'm not sure what you mean here? That making maven jar always runs the unit-tests where there are situations (e.g. when working on the website) that the project.xml, maven.xml, project.properties, and all source files are not changed so that tests have no reasons to reflect anything new. But I fear this is close to a religious war... I prefer tests to be thick and covering a lot than being a snap... paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/jelly maven.xml
The postGoal is not invoked... that's my problem. It should be. If this is on jelly, I can give it a quick test now. I'm not sure what you mean here? (like, I think this too much btw, test) That making maven jar always runs the unit-tests where there are situations (e.g. when working on the website) that the project.xml, maven.xml, project.properties, and all source files are not changed so that tests have no reasons to reflect anything new. Right, we have definitely talked about: - making sure tests only run once per session - and/or only when changed. Makes sense, but doesn't fit the current architecture well. But I fear this is close to a religious war... yep, that's why maven.test.skip exists I prefer tests to be thick and covering a lot than being a snap... Maven's encouragement is to run them often, and so keep them simple. If you have comprehensive, long tests like the memory leak tests, they should be a separate test suite, run pre-commit, through continuous integration, and pre-release but not necessarily for every change. Most of the time, the thick tests tend to be integration tests rather than unit tests. - Brett paul - 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: [jelly] Maven JSL memory leak and Jelly
Ideally, a test-case would be awesome, even if it refers to some
far-away stylesheet...
Can you try calling .clear() on the result of this
context.runScript(uri, output, isExport(), isInherit())
(and the other call).
Maybe that'll help.
In all cases, this context is gc-ed shortly after, I believe... so I
see no reasons for big leaks at the tag-cache level.
Also, maybe it would help to give more details where to go... I think
this was reported about very long ago so maybe a distribution
maven-1.0.2 or such should have this bug ?
paul
Le 24 janv. 05, à 12:35, Brett Porter a écrit :
Hi,
I did some testing and can confirm that the current site generation
memory leak occurs here:
j:file name=${outFile} encoding=${outputencoding}
omitXmlDeclaration=true outputMode=xml
prettyPrint=no
-- j:include uri=${stylesheet.toString()}/
/j:file
If I remove the include, nothing is leaked. So, while this is
obviously a whole lot of additional Jelly (actually, its this:
http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/xdoc/src/
plugin-resources/site.jsl); it is just Jelly - nothing about Maven's
context creation AFAICT.
j:include does a context.runScript(uri, output, isExport(),
isInherit()); which is when the caching occurs, right?
So are there any further ideas about where the leak is? IS it the JSL
used in site.jsl, the j:include itself, or something else? Do you need
me to do more narrowing down within site.jsl or does someone have a
hunch?
Thanks,
Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly maven.xml
brett 2005/01/24 04:19:44
Modified:jellymaven.xml
Log:
adjust generation of version/timestamp
Revision ChangesPath
1.93 +6 -6 jakarta-commons/jelly/maven.xml
Index: maven.xml
===
RCS file: /home/cvs/jakarta-commons/jelly/maven.xml,v
retrieving revision 1.92
retrieving revision 1.93
diff -u -r1.92 -r1.93
--- maven.xml 24 Jan 2005 00:34:06 - 1.92
+++ maven.xml 24 Jan 2005 12:19:44 - 1.93
@@ -48,13 +48,13 @@
!-- == --
!-- build the timestamp after compiling --
- postGoal name=java:compile
-echo
file=${maven.build.dest}/org/apache/commons/jelly/jelly-version.txt
- ${pom.currentVersion}/echo
+ postGoal name=java:jar-resources
+j:file
name=${maven.build.dest}/org/apache/commons/jelly/jelly-version.txt
omitXmlDeclaration=true
+ ${pom.currentVersion}/j:file
tstampformat property=now pattern=-MM-dd kk:mm:ss
zzz//tstamp
-echo
file=${maven.build.dest}/org/apache/commons/jelly/jelly-build-date.txt
- ${now}/echo
-/postGoal
+j:file
name=${maven.build.dest}/org/apache/commons/jelly/jelly-build-date.txt
omitXmlDeclaration=true
+ ${now}/j:file
+ /postGoal
!-- create the lib and bin directories in the binary distro --
preGoal name=dist:build
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/jelly maven.xml
Brett Porter wrote: The postGoal is not invoked... that's my problem. It should be. If this is on jelly, I can give it a quick test now. Changed, though I think it already worked. You may have been decieved by the fact that nothing is output unless it outputs something, but it is working now. I changed it from echo file / to j:file /, being jelly after all :) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly/jelly-tags/memory - Imported sources
brett 2005/01/24 04:24:06 Log: import a memory tag library to help debugging leaks mid jelly script Status: Vendor Tag: ASF Release Tags: INIT N jakarta-commons/jelly/jelly-tags/memory/.cvsignore N jakarta-commons/jelly/jelly-tags/memory/project.xml N jakarta-commons/jelly/jelly-tags/memory/src/java/org/apache/commons/jelly/tags/memory/FreeMemoryTag.java N jakarta-commons/jelly/jelly-tags/memory/src/java/org/apache/commons/jelly/tags/memory/GcTag.java N jakarta-commons/jelly/jelly-tags/memory/src/java/org/apache/commons/jelly/tags/memory/MemoryTagLibrary.java N jakarta-commons/jelly/jelly-tags/memory/xdocs/changes.xml N jakarta-commons/jelly/jelly-tags/memory/xdocs/index.xml N jakarta-commons/jelly/jelly-tags/memory/xdocs/navigation.xml No conflicts created by this import - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Maven JSL memory leak and Jelly
Paul Libbrecht wrote: Ideally, a test-case would be awesome, even if it refers to some far-away stylesheet... I'll try and narrow it down first by cutting down site.jsl to the minimum that leaks. Can you try calling .clear() on the result of this context.runScript(uri, output, isExport(), isInherit()) (and the other call). so try with context.clear() inside IncludeTag? Ok, will try tomorrow. Maybe that'll help. In all cases, this context is gc-ed shortly after, I believe... so I see no reasons for big leaks at the tag-cache level. It leaks 200k every time site.jsl is run, so should be easy to find, right? :) Also, maybe it would help to give more details where to go... I think this was reported about very long ago so maybe a distribution maven-1.0.2 or such should have this bug ? easiest to run it against Maven's trunk really as it is compatible with Jelly RC2 (RC1 was broken, so it currently uses beta-4 until RC2 is released). RC2 won't work with Maven 1.0.x. If you want to give it a go: - check out Maven from SVN and build: svn co http://svn.apache.org/repos/asf/maven/maven-1/core/trunk maven-1/core/trunk svn co http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk maven-1/plugins/trunk - build maven inside maven-1/core/trunk (see http://www.apache.org/~brett/maven-stage-site/developers/building-from-source.html, make sure you reassign a new MAVEN_HOME!) - run maven xdoc and watch memory go... - twiddle xdoc plugin and run maven plugin:install to test. Use the memory tag lib I just added to jelly to test. memory:gc/ and memory:showFree /. Hopefully I'll have more information tomorrow, I'm going to bed now. I'm keen to kill this before Jelly 1.0 if possible. Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33221] New: - null pointer exception in LogFactory.getLog
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=33221. 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=33221 Summary: null pointer exception in LogFactory.getLog Product: Commons Version: 1.0.4 Platform: Macintosh OS/Version: Mac OS X 10.3 Status: NEW Severity: normal Priority: P2 Component: Logging AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In running the LoggingTrial example from the book Pro Jakarta Commons by Oak from Apress on MacOSX 10.3.7, java version 1.4.2_05-141.3, I get the following error: run_example: [java] Exception in thread main org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException) (Caused by org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException)) [java] at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543) [java] at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235) [java] at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209) [java] at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351) [java] at com.commonsbook.chap3.LoggingTrial.main(LoggingTrial.java:8) [java] Caused by: org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException) [java] at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397) [java] at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529) [java] ... 4 more [java] Caused by: java.lang.NullPointerException [java] at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:374) [java] ... 5 more Up to this point everything in the book worked. I doubt user error. MacOSX java implementation? -- 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 33221] - [logging] null pointer exception in LogFactory.getLog
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=33221. 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=33221 [EMAIL PROTECTED] changed: What|Removed |Added Summary|null pointer exception in |[logging] null pointer |LogFactory.getLog |exception in ||LogFactory.getLog -- 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 33221] - [logging] null pointer exception in LogFactory.getLog
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=33221. 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=33221 --- Additional Comments From [EMAIL PROTECTED] 2005-01-24 17:27 --- I downloaded the example and tried it successfully on Windows XP with Java 1.4.2_06. Note that my locale is set to sv_SE. Here is the output: The Log being used [EMAIL PROTECTED] 2005-jan-24 17:19:46 com.commonsbook.chap3.LoggingTrial main INFO: INFO TEST 2005-jan-24 17:19:46 com.commonsbook.chap3.LoggingTrial main INFO: INFO TEST java.lang.Exception: A DUMMY EXCEPTION at com.commonsbook.chap3.LoggingTrial.main(LoggingTrial.java:14) 2005-jan-24 17:19:46 com.commonsbook.chap3.LoggingTrial main VARNING: WARN TEST 2005-jan-24 17:19:46 com.commonsbook.chap3.LoggingTrial main VARNING: WARN TEST java.lang.Exception: A DUMMY EXCEPTION at com.commonsbook.chap3.LoggingTrial.main(LoggingTrial.java:14) 2005-jan-24 17:19:46 com.commonsbook.chap3.LoggingTrial main ALLVARLIG: ERROR TEST 2005-jan-24 17:19:46 com.commonsbook.chap3.LoggingTrial main ALLVARLIG: ERROR TEST java.lang.Exception: A DUMMY EXCEPTION at com.commonsbook.chap3.LoggingTrial.main(LoggingTrial.java:14) 2005-jan-24 17:19:46 com.commonsbook.chap3.LoggingTrial main ALLVARLIG: FATAL TEST 2005-jan-24 17:19:46 com.commonsbook.chap3.LoggingTrial main ALLVARLIG: FATAL TEST java.lang.Exception: A DUMMY EXCEPTION at com.commonsbook.chap3.LoggingTrial.main(LoggingTrial.java:14) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] API - methods for logging entry and exit events
Richard Sitze wrote on 2005-01-21 20:07:49: The purpose of logging is to capture enough state of a system, so that when you identify *where* the error occurs in the logs, you have information that can help you identify the cause of the error. Class/method 'boundries' are convenient for many reasons, not least of which is that in a well designed [dare I say OO?] modularized software component the methods are [typically] relatively short and functionally defined by their parameters. Stack traces for exceptions [if you HAVE an exception] can identify a method, but don't capture the state of the system in the same way that an entry log entry [eeks] would. Entry/exit help you identify the state of the system at the time a fault occurs, and in many cases can identify the fault itself. In other words, you are advocating the use of logging as a sort of persistent debugger. Clearly, a debugger can provide a perfectly detailed view of the system, down to the register level. However, no one usually cares about that much detail. Not only is that level of detail distracting, it will noticeably slow down the application and hog megabytes of disk space. Is indiscriminate logging IBM's secret justification for ever bigger and faster machines? Likewise, errors can be caused by earlier eventsthe entry/exit flow information can help identify the factors related to such.. again based on conveniant boundries in the code. Theoretically speaking, there is no denying that as the quantity of information about the system increases, so does the probability of finding the cause of a given error. But where do you stop? I do agree that with some serious planning [thought], and effort that there may be more helpful bits of information to log in some cases, but if experience shows anything it is that these are typically identified from hindsight in many components. We don't always *have* the luxury of hindsight. In these cases, the more information logged the better. Let me present this from a different angle. Logging is about fixing the next run, not the current one. The current one failed, rememberer? So, in some sense, you always have the luxury of hindsight, almost by construction. You can rely on log files with tons and tons of noise, or you can look at less detailed logs but which still provide a view of the big picture. Armed with the big picture you can try to reproduce the problem on your side. Once you are able to reproduce the error, you can fix it. entry/exit logging is a best-practice that is *easily* understood by developers, it provides a minimal set of information that can offer a significant improvement over speriodic logging within the code. Now... if you feel that such methods are not appropriate for the 'general' case... while I disagree, I won't argue *too* strongly.. but I would point out that we have requested these API's under the guise of 'Enterprise Logging' services ;-). Now that you mention it, one the reasons which got me working on log4j and its filtering mechanisms, was the thousands of lines of garbage generated by the logs of an IBM product, which will go unnamed here. You seem approach logging from a different perspective altogether: Dump as much information as you can, worry about sorting through the mess later. Is that a fair description? -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[contract] OCL implementation
Anyone here knows this compiler? Dresden OCL Toolkit (http://dresden-ocl.sourceforge.net) Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] API - methods for logging entry and exit events
Ceki, You seem oddly disparaging of a technology that you've created one of the standard packages for :-), so let's explore a couple of your thoughts from a different perspective. On Mon, 24 Jan 2005 18:06:21 +0100, Ceki Gülcü [EMAIL PROTECTED] wrote: Richard Sitze wrote on 2005-01-21 20:07:49: The purpose of logging is to capture enough state of a system, so that when you identify *where* the error occurs in the logs, you have information that can help you identify the cause of the error. Class/method 'boundries' are convenient for many reasons, not least of which is that in a well designed [dare I say OO?] modularized software component the methods are [typically] relatively short and functionally defined by their parameters. Stack traces for exceptions [if you HAVE an exception] can identify a method, but don't capture the state of the system in the same way that an entry log entry [eeks] would. Entry/exit help you identify the state of the system at the time a fault occurs, and in many cases can identify the fault itself. In other words, you are advocating the use of logging as a sort of persistent debugger. Clearly, a debugger can provide a perfectly detailed view of the system, down to the register level. However, no one usually cares about that much detail. Not only is that level of detail distracting, it will noticeably slow down the application and hog megabytes of disk space. Is indiscriminate logging IBM's secret justification for ever bigger and faster machines? I'm certainly not a universal example of how developers work, but thinking back over 25 effort of work in this field, I have consistently found logging more helpful (and interactive debugging less than helpful) at understanding the behavior of complex systems. It's great to be able to dive in with a debugger and see aha, that value is set to 'foo' but it should really have been 'bar' -- but that tends not to be the kind of mistake that I make. I usually get the overall control flow wrong when I blow it ... and in a complex system (especially multithreaded ones) it becomes difficult and/or tiresome to locate these kinds of problems with debugging. If I can go back and tweak some logging levels, though, problems like this become much easier to locate. This isn't an argument for or against enter() and exit() as entry points in a logging API (I'm not a fan yet, but not an opponent either) -- but your arguments aren't about that either. You're simply arguing against logging at all, which doesn't seem to make sense to me. Likewise, errors can be caused by earlier eventsthe entry/exit flow information can help identify the factors related to such.. again based on conveniant boundries in the code. Theoretically speaking, there is no denying that as the quantity of information about the system increases, so does the probability of finding the cause of a given error. But where do you stop? You stop adding logging messages when you stop running into bugs :-). But you don't leave them enabled all the time, either. Or, at least *I* don't. If someone wants to leave Digester's debugging level set to trace all the time (which will generate quite a lot of output), though, that's not my concern anyway -- that is the conscious choice of the developer that is using it. On the other hand, without those logging statements being available, it is pretty difficult for most people to understand the dynamic behavior of something based on a SAX parser (as Digester is), which is pretty much backwards to the way most people write code. The ability to turn on those log messages on once in a while is tremendously helpful for this purpose. I do agree that with some serious planning [thought], and effort that there may be more helpful bits of information to log in some cases, but if experience shows anything it is that these are typically identified from hindsight in many components. We don't always *have* the luxury of hindsight. In these cases, the more information logged the better. Let me present this from a different angle. Logging is about fixing the next run, not the current one. The current one failed, rememberer? So, in some sense, you always have the luxury of hindsight, almost by construction. You can rely on log files with tons and tons of noise, or you can look at less detailed logs but which still provide a view of the big picture. Armed with the big picture you can try to reproduce the problem on your side. Once you are able to reproduce the error, you can fix it. entry/exit logging is a best-practice that is *easily* understood by developers, it provides a minimal set of information that can offer a significant improvement over speriodic logging within the code. Now... if you feel that such methods are not appropriate for the 'general' case... while I disagree, I won't argue *too* strongly.. but I would point out that we have requested
Re: [all][VOTE] svn migration
+1 -Mark Diggory Jerome Jar wrote: +1 On Sat, 22 Jan 2005 13:31:17 -0500, Tim O'Brien [EMAIL PROTECTED] wrote: Alright a sufficient amount of time has passed for public comments and testing. This is a vote thread for migrating commons to SVN. If this vote passes, I'll contact Justin and schedule the least disruptive migration time possible. Tim O'Brien - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] API - methods for logging entry and exit events
Ceki Gülcü [EMAIL PROTECTED] wrote on 01/24/2005 11:06:21 AM: Richard Sitze wrote on 2005-01-21 20:07:49: The purpose of logging is to capture enough state of a system, so that when you identify *where* the error occurs in the logs, you have information that can help you identify the cause of the error. Class/method 'boundries' are convenient for many reasons, not least of which is that in a well designed [dare I say OO?] modularized software component the methods are [typically] relatively short and functionally defined by their parameters. Stack traces for exceptions [if you HAVE an exception] can identify a method, but don't capture the state of the system in the same way that an entry log entry [eeks] would. Entry/exit help you identify the state of the system at the time a fault occurs, and in many cases can identify the fault itself. In other words, you are advocating the use of logging as a sort of persistent debugger. Clearly, a debugger can provide a perfectly detailed view of the system, down to the register level. However, no one usually cares about that much detail. Not only is that level of detail distracting, it will noticeably slow down the application and hog megabytes of disk space. Is indiscriminate logging IBM's secret justification for ever bigger and faster machines? 1. It's not indiscriminate logging. That's why we call it tracing, and that's why the logging impls [such as Log4J] allow us to turn it on/off. 2. The fact of the matter is that in many corporate operational environments, production-level [that's *not* development] systems are guarded carefully. Installing additional components [debuggers], never MIND running them, is not an option. When one fails to duplicate a problem in a development environment, customers *expect* us to be able to glean information from productions system that can demonstrate the problems. 3. Are your pokes/jabs at me for being an IBM employee necessary? I've spent 2/5 of my career at IBM. When I exceed 1/2, you come on back and I'll listen to you more seriously. My goal is to be an advocate of the technologies and techniques I see that can benefit the community. I *will* argue for what I believe to be in the best interest of the development community. And when the decisions are made, I will support them. That's the stance I take with my employer: defending open-source decisions that I may not agree with. That I am tainted by my experience, environment, etc., is a fact of life.. and part of the process. It's the strength of open source development. It's why we have developers from many backgrounds make up our community. Why do you want to make that a negative? Likewise, errors can be caused by earlier eventsthe entry/exit flow information can help identify the factors related to such.. again based on conveniant boundries in the code. Theoretically speaking, there is no denying that as the quantity of information about the system increases, so does the probability of finding the cause of a given error. But where do you stop? I claim that entry/exit at class/method is reasonable.. along with other best-practices I've described in other notes. It's easily identifiable, it's convenient, it's easy to automate [AspectJ or other tooling], and more importantly it's *useful*. Should it stop there? No. Is it a reasonable, and easily understood, starting point for instrumenting code with logging? Yes. I do agree that with some serious planning [thought], and effort that there may be more helpful bits of information to log in some cases, but if experience shows anything it is that these are typically identified from hindsight in many components. We don't always *have* the luxury of hindsight. In these cases, the more information logged the better. Let me present this from a different angle. Logging is about fixing the next run, not the current one. The current one failed, rememberer? So, in some sense, you always have the luxury of hindsight, almost by construction. You can rely on log files with tons and tons of noise, or you can look at less detailed logs but which still provide a view of the big picture. Armed with the big picture you can try to reproduce the problem on your side. Once you are able to reproduce the error, you can fix it. The more you understand about the macro picture, and where a problem lies, the more you want information on the micro picture in that area. I've personally been in situations where the errors could not be duplicated in the lab. Differences in hardware, and in the particular case in my mind, even to the extent of different revisions of firmware on otherwise similar systems introduce variable that are not always easily comprehended. entry/exit logging is a best-practice that is *easily* understood by developers, it provides a minimal set of information that can offer a significant
Re: [all][VOTE] svn migration
+1 - it really has proved its worth with Struts Don On Mon, 24 Jan 2005 14:14:12 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: +1 -Mark Diggory Jerome Jar wrote: +1 On Sat, 22 Jan 2005 13:31:17 -0500, Tim O'Brien [EMAIL PROTECTED] wrote: Alright a sufficient amount of time has passed for public comments and testing. This is a vote thread for migrating commons to SVN. If this vote passes, I'll contact Justin and schedule the least disruptive migration time possible. Tim O'Brien - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33221] - [logging] null pointer exception in LogFactory.getLog
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=33221.
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=33221
--- Additional Comments From [EMAIL PROTECTED] 2005-01-24 21:22 ---
LogFactoryImpl.java:543
541:if (logMethod != null) {
542:params[0] = this;
543:logMethod.invoke(instance, params);
544:}
So... not sure what version of the code you're using, but looks to me like
your line#543 can't be the same as the most recent source. This isn't a
recent code change either.
Please pull a recent build, retry, and supply us with a stack-trace that
matches current code. 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]
DO NOT REPLY [Bug 33221] - [logging] null pointer exception in LogFactory.getLog
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=33221. 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=33221 --- Additional Comments From [EMAIL PROTECTED] 2005-01-24 21:24 --- Oh wait.. this is a reflective invoke. How fun. Strike that last note. -- 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 33221] - [logging] null pointer exception in LogFactory.getLog
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=33221. 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=33221 --- Additional Comments From [EMAIL PROTECTED] 2005-01-24 21:29 --- I would still like to ensure that you are running this with a recent nightly build, to ensure line #'s line up. Also, if there is any more detail on the stacktrace, I'd like to see that... it looks like we're losing the interesting detail on the core problem. -- 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]
[lang] new token for FastDateFormat
I just noticed that there's no way to output the milliseconds since 1970 with SimpleDateFormat (or with FastDateFormat). Any interest in having a token for FastDateFormat that lets you do that? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] API - methods for logging entry and exit events
On 2005-01-24 17:28:06 Craig McClanahan wrote:
I'm certainly not a universal example of how developers work, but
thinking back over 25 effort of work in this field, I have
consistently found logging more helpful (and interactive debugging
less than helpful) at understanding the behavior of complex systems.
It's great to be able to dive in with a debugger and see aha, that
value is set to 'foo' but it should really have been 'bar' -- but
that tends not to be the kind of mistake that I make. I usually get
the overall control flow wrong when I blow it ... and in a complex
system (especially multithreaded ones) it becomes difficult and/or
tiresome to locate these kinds of problems with debugging. If I can
go back and tweak some logging levels, though, problems like this
become much easier to locate.
have not looked at a debugger in the last 10 years and have no plans
switching any time soon. :-)
This isn't an argument for or against enter() and exit() as entry
points in a logging API (I'm not a fan yet, but not an opponent
either) -- but your arguments aren't about that either. You're simply
arguing against logging at all, which doesn't seem to make sense to
me.
I am advocating against *indiscriminate* logging, not logging in
general. Since imho enter/exit methods encourage indiscriminate
logging, they should be avoided. (What indiscriminate logging means is
discussed below.)
Although log4j tries hard to reduce the computational cost of each log
statement, each log statement still has a cost. This cost can range
from just a few nanoseconds, for disabled statements, to roughly 1
millisecond when writing to a database.
On top of their computational cost, enabled log statements have a cost
related to processing by humans. These days, the costs associated with
1 second of (human) brain time is much higher than the cost associated
with 1 second of CPU time.
Likewise, errors can be caused by earlier eventsthe entry/exit flow
information can help identify the factors related to such.. again
based on
conveniant boundries in the code.
Theoretically speaking, there is no denying that as the quantity of
information about the system increases, so does the probability of
finding the cause of a given error. But where do you stop?
You stop adding logging messages when you stop running into bugs :-).
But you don't leave them enabled all the time, either. Or, at least
*I* don't. If someone wants to leave Digester's debugging level set
to trace all the time (which will generate quite a lot of output),
though, that's not my concern anyway -- that is the conscious choice
of the developer that is using it.
On the other hand, without those logging statements being available,
it is pretty difficult for most people to understand the dynamic
behavior of something based on a SAX parser (as Digester is), which is
pretty much backwards to the way most people write code. The ability
to turn on those log messages on once in a while is tremendously
helpful for this purpose.
Digester is a nice concrete example.
Considering that Digester is a mature package, let us assume that the
logging output is mostly intended to debug digester rule sets, not
Digester itself. In other words, logging will help clarify how
Digester interprets a given set of rules and how it applies them to a
given XML document. I call this use logging as whiteboxing a tool,
for example Digester.
When whiteboxing, the developer of the tool should ideally design the
logs to spit out enough output so that a new user can understand what
the tool is doing, without overwhelming her.
Here is a simple xml document:
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE hello
hello
world
/world
/hello
Here is a sample test application:
import org.apache.commons.digester.*;
import org.xml.sax.Attributes;
public class Dig {
public static void main(String[] args) throws Exception {
Digester digester = new Digester();
digester.addRule(*, new HelloRule());
digester.parse(args[0]);
}
}
class HelloRule extends Rule {
// nothing to do
}
When I run 'java Dig hello.xml', it generates the following log
output.
DEBUG org.apache.commons.digester.Digester.sax -
setDocumentLocator([EMAIL PROTECTED])
DEBUG org.apache.commons.digester.Digester.sax - startDocument()
DEBUG org.apache.commons.digester.Digester.sax - startElement(,,hello)
DEBUG org.apache.commons.digester.Digester - Pushing body text ''
DEBUG org.apache.commons.digester.Digester - New match='hello'
DEBUG org.apache.commons.digester.Digester - No rules found matching 'hello'.
DEBUG org.apache.commons.digester.Digester.sax - characters()
DEBUG org.apache.commons.digester.Digester.sax - characters(
)
DEBUG org.apache.commons.digester.Digester.sax - characters( )
DEBUG org.apache.commons.digester.Digester.sax - startElement(,,world)
DEBUG org.apache.commons.digester.Digester - Pushing body text '
'
DEBUG org.apache.commons.digester.Digester - New match='hello/world'
DEBUG
[lang] StringUtil reverseSplit
I noticed this method on the task list, so I've started implementing
it. I have a few questions:
1. Should it allow for nulls as the input string?
2. Is null a permissible delimiter?
3. If the string is mary had a little lamb and reverseSplit is applied to it:
a. if reverse is applied first, we get back bmal elttil a dah yram,
splitting this using as the delimiter, the first String of the
resulting array is bmal
b. If split is applied first, {mary, had, a, little, lamb},
and reverse yields lamb
Is 3a or 3b the correct behaviour?
Thanks in advance for the help!
--
Cheers,
Hasan Diwan [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Context management
hi mauro am i right in thinking that you mean NDC (nested diagnostic context) rather than MDC? as you might have noticed, there's quite a bit of debate at the moment about exactly where JCL should actually go. in the beginning, it was easy. (well actually no, it wasn't easy or fun in many other ways but the basic concept was straightforward.) JCL would be a thin bridging layer for bricks presenting the bare bones functionality required. even though it suffered from numerous technical imperfections, JCL became widely used not just as a solution to the original problem but also as a solution to a subtly different one: logging from what might loosely be termed enterprise components (large sub-systems which are complex enough to be regarded as applications in their own right but must be capable of deployment in a variety of environments as parts of larger applications). bricks are widely used in enterprise components and so this is an important use case for brick developers but enterprise components also have needs which bricks don't. i suspect that a layer to abstract NDCs would be useful for enterprise components but not bricks. so, i'd be unlikely to commit any extension to JCL in this area. that's where my personal line is drawn. other may think differently. i'd recommend choosing one of the following courses of action: 1. create a bug report and attach your code. join in the current debate and lobby for inclusion in JCL2. 2. create a project (at sourceforge, for example) aimed at extending JCL to solve problems common to enterprise components. i have high hopes that the new discovery code for JCL2 will be much more modular and allow others to tap into the same mechanism. if you go down this route, feel free to add a link to this new project to the wiki. - robert On 23 Jan 2005, at 17:08, Mauro Franceschini wrote: For my needs I've developed a series of patches to the standard 1.0.4 commons-logging code base in order to make available the MDC (in the case of log4j) or ContextMap (in the case of logkit) to commons-logging using applications. How can I contribute to commons-logging codebase with this new functions? Mauro. - 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 33221] - [logging] null pointer exception in LogFactory.getLog
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=33221. 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=33221 --- Additional Comments From [EMAIL PROTECTED] 2005-01-24 22:21 --- I am using 1.0.4 version which I believe is the most recent. I have the commons-logging in the java endorsed directory as well as in a separate classpath listed lib directory. Removing it from classpath doesn't change anything, have not removed it from endorsed. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] API - methods for logging entry and exit events
On 2005-01-24 19:39:06 Richard Sitze wrote: 1. It's not indiscriminate logging. That's why we call it tracing, and that's why the logging impls [such as Log4J] allow us to turn it on/off. 2. The fact of the matter is that in many corporate operational environments, production-level [that's *not* development] systems are guarded carefully. Installing additional components [debuggers], never MIND running them, is not an option. When one fails to duplicate a problem in a development environment, customers *expect* us to be able to glean information from productions system that can demonstrate the problems. I was not suggesting the use of debuggers at all, not one bit. When you attempt to log everything, then logging can be abstractly viewed as a persistent debugger. 3. Are your pokes/jabs at me for being an IBM employee necessary? I've spent 2/5 of my career at IBM. When I exceed 1/2, you come on back and I'll listen to you more seriously. No jabs at you personally. I am an ex-IBM employee. Some of the IBM products we struggled with at the time generated so much log output that I still vividly recall the frustration. The lesson from that experience: Too much logging can as bad as the absence of logging. My goal is to be an advocate of the technologies and techniques I see that can benefit the community. I *will* argue for what I believe to be in the best interest of the development community. And when the decisions are made, I will support them. That's the stance I take with my employer: defending open-source decisions that I may not agree with. That I am tainted by my experience, environment, etc., is a fact of life.. and part of the process. It's the strength of open source development. It's why we have developers from many backgrounds make up our community. Why do you want to make that a negative? Having personally experienced the negative effects of the approach advocated by IBM, I am trying to warn to community. However, you and IBM have every right to advocate your point of view. I sincerely apologize if my comments came across as disparaging IBM or you personally, that was not my intention. I claim that entry/exit at class/method is reasonable.. along with other best-practices I've described in other notes. It's easily identifiable, it's convenient, it's easy to automate [AspectJ or other tooling], and more importantly it's *useful*. Should it stop there? No. Is it a reasonable, and easily understood, starting point for instrumenting code with logging? Yes. You can go overboard with logging. Method entry/exit logs happens to be convenient and easy way of generating tons of garbage. :-) I've personally been in situations where the errors could not be duplicated in the lab. Differences in hardware, and in the particular case in my mind, even to the extent of different revisions of firmware on otherwise similar systems introduce variable that are not always easily comprehended. Instead of instrument every copy of your application, you can instrument a special version to identify the problem on that special environment. Once the problem is identified, you move on. There is no need to pollute every copy of your application. -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33221] - [logging] null pointer exception in LogFactory.getLog
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=33221. 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=33221 --- Additional Comments From [EMAIL PROTECTED] 2005-01-24 23:21 --- I removed commons-logging from endorsed and left it in classpath. It now works as it suppose to, except, it defaults to log4j and not simplelog. Something I don't understand happens when commons-logging is in the java/lib/endorsed directory. -- 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]
[contract] german translate ...
Please, anyone with german knowledge can translate the missing parts in exceptions.xml? Thanx Woody PS: David, I know you knows german (because you write this xml) but can you do this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] new token for FastDateFormat
Adding any token would be a backwards incompatible change, as it would previously have been output as text. Why not just have a DateUtils.getMillisAsText(Date) method? (Well maybe because it seems like a very odd case.) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] I just noticed that there's no way to output the milliseconds since 1970 with SimpleDateFormat (or with FastDateFormat). Any interest in having a token for FastDateFormat that lets you do that? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] new token for FastDateFormat
Last time I checked, Long.toString(date.getTime()) did that anyway, and in less characters :) Cheers, Brett Quoting Stephen Colebourne [EMAIL PROTECTED]: Adding any token would be a backwards incompatible change, as it would previously have been output as text. Why not just have a DateUtils.getMillisAsText(Date) method? (Well maybe because it seems like a very odd case.) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] I just noticed that there's no way to output the milliseconds since 1970 with SimpleDateFormat (or with FastDateFormat). Any interest in having a token for FastDateFormat that lets you do that? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[contract] german translate
Please, anyone with german knowledge can translate the missing parts in exceptions.xml? Thanx Woody PS: David, I know you knows german (because you write this xml) but can you do this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
codec : Bas64.isArrayByteBase64() issue
There seem to be 2 issues.
Only 255 byte values are used when creating
base64Alphabet, but there are 256 possible values
octect (shouldn't that be octet ?) isn't shifted
despite the fact that Java uses unsigned bytes. It is used unchanged as
on offset into an array (zero based).
As a result I can produce test cases that cause
isBase64() to throw IndexOutOfBounds exceptions.
While at it, I suggest one line be added to
discardWhitespace() that will improve performance under some circumstances
(i.e., when there is no whitespace in the input).
Patch file is attached.Patch file is based on latest version in CVS of Base64.java file:
1.23
= Ezra E.
P.S., I can provide a jUnit TestCase if that's useful.
--- Base64.java.cvs.1.232005-01-24 16:59:46.211939200 -0800
+++ Base64.java.changed 2005-01-24 17:03:42.782110400 -0800
@@ -55,7 +55,7 @@
/**
* The base length.
*/
-static final int BASELENGTH = 255;
+static final int BASELENGTH = 256;
/**
* Lookup length.
@@ -162,7 +162,7 @@
private static boolean isBase64(byte octect) {
if (octect == PAD) {
return true;
-} else if (octect 0 || base64Alphabet[octect] == -1) {
+} else if (octect 0 || base64Alphabet[(octect 0) ? octect : 256 +
octect] == -1) {
return false;
} else {
return true;
@@ -482,6 +482,9 @@
}
}
+ // Check if we're done and save resources if we are.
+ if (bytesCopied == data.length) return groomedData;
+
byte packedData[] = new byte[bytesCopied];
System.arraycopy(groomedData, 0, packedData, 0, bytesCopied);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] API - methods for logging entry and exit events
Ceki Gülcü wrote: On 2005-01-24 19:39:06 Richard Sitze wrote: 1. It's not indiscriminate logging. That's why we call it tracing, and that's why the logging impls [such as Log4J] allow us to turn it on/off. 2. The fact of the matter is that in many corporate operational environments, production-level [that's *not* development] systems are guarded carefully. Installing additional components [debuggers], never MIND running them, is not an option. When one fails to duplicate a problem in a development environment, customers *expect* us to be able to glean information from productions system that can demonstrate the problems. I was not suggesting the use of debuggers at all, not one bit. When you attempt to log everything, then logging can be abstractly viewed as a persistent debugger. 3. Are your pokes/jabs at me for being an IBM employee necessary? I've spent 2/5 of my career at IBM. When I exceed 1/2, you come on back and I'll listen to you more seriously. No jabs at you personally. I am an ex-IBM employee. Some of the IBM products we struggled with at the time generated so much log output that I still vividly recall the frustration. The lesson from that experience: Too much logging can as bad as the absence of logging. My goal is to be an advocate of the technologies and techniques I see that can benefit the community. I *will* argue for what I believe to be in the best interest of the development community. And when the decisions are made, I will support them. That's the stance I take with my employer: defending open-source decisions that I may not agree with. That I am tainted by my experience, environment, etc., is a fact of life.. and part of the process. It's the strength of open source development. It's why we have developers from many backgrounds make up our community. Why do you want to make that a negative? Having personally experienced the negative effects of the approach advocated by IBM, I am trying to warn to community. However, you and IBM have every right to advocate your point of view. I sincerely apologize if my comments came across as disparaging IBM or you personally, that was not my intention. I claim that entry/exit at class/method is reasonable.. along with other best-practices I've described in other notes. It's easily identifiable, it's convenient, it's easy to automate [AspectJ or other tooling], and more importantly it's *useful*. Should it stop there? No. Is it a reasonable, and easily understood, starting point for instrumenting code with logging? Yes. You can go overboard with logging. Method entry/exit logs happens to be convenient and easy way of generating tons of garbage. :-) I've personally been in situations where the errors could not be duplicated in the lab. Differences in hardware, and in the particular case in my mind, even to the extent of different revisions of firmware on otherwise similar systems introduce variable that are not always easily comprehended. Instead of instrument every copy of your application, you can instrument a special version to identify the problem on that special environment. Once the problem is identified, you move on. There is no need to pollute every copy of your application. While I agree with everything that you have said about indiscriminate logging, I think you are missing Richard's point here. In some environments, this sort of ad hoc change is not allowed or cannot be executed quickly enough to help resolve a production problem. The relevant information simply needs to be available in the logs. I agree with you that entry/exit logging and other forms of automatic instrumentation can create more problems than they solve. The challenge is to get the right info into the logs without, as you put it, polluting them with junk that strains the infrastructure and makes it hard to find the relevant info. Sadly, success here depends much less on what the logging framework provides than what the developer is thinking when deciding when and what to log. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: codec : Bas64.isArrayByteBase64() issue
Oooops. Wrong patch
file. Correct one is attached.
= Ezra E.
From: Ezra Epstein
[mailto:[EMAIL PROTECTED]Sent: Mon 1/24/2005 5:22 PMTo:
commons-dev@jakarta.apache.orgSubject: codec :
Bas64.isArrayByteBase64() issue
There seem to be 2
issues.
Only 255 byte values are used when creating
base64Alphabet, but there are 256 possible values
octect (shouldn't that be octet ?) isn't shifted
despite the fact that Java uses unsigned bytes. It is used unchanged as
on offset into an array (zero based).
As a result I can produce test cases that cause
isBase64() to throw IndexOutOfBounds exceptions.
While at it, I suggest one line be added to
discardWhitespace() that will improve performance under some circumstances
(i.e., when there is no whitespace in the input).
Patch file is attached.Patch file is based on latest version in CVS of Base64.java file:
1.23
= Ezra E.
P.S., I can provide a jUnit TestCase if that's useful.
--- Base64.java.cvs.1.232005-01-24 16:59:46.211939200 -0800
+++ Base64.java.changed 2005-01-24 17:03:42.782110400 -0800
@@ -55,7 +55,7 @@
/**
* The base length.
*/
-static final int BASELENGTH = 255;
+static final int BASELENGTH = 256;
/**
* Lookup length.
@@ -162,7 +162,7 @@
private static boolean isBase64(byte octect) {
if (octect == PAD) {
return true;
-} else if (octect 0 || base64Alphabet[octect] == -1) {
+} else if (octect 0 || base64Alphabet[(octect 0) ? 256 + octect :
octect] == -1) {
return false;
} else {
return true;
@@ -482,6 +482,9 @@
}
}
+ // Check if we're done and save resources if we are.
+ if (bytesCopied == data.length) return groomedData;
+
byte packedData[] = new byte[bytesCopied];
System.arraycopy(groomedData, 0, packedData, 0, bytesCopied);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jelly] Maven JSL memory leak and Jelly
Why won't RC2 work with maven 1.0.x? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, January 24, 2005 7:30 AM To: Jakarta Commons Developers List Subject: Re: [jelly] Maven JSL memory leak and Jelly Paul Libbrecht wrote: Ideally, a test-case would be awesome, even if it refers to some far-away stylesheet... I'll try and narrow it down first by cutting down site.jsl to the minimum that leaks. Can you try calling .clear() on the result of this context.runScript(uri, output, isExport(), isInherit()) (and the other call). so try with context.clear() inside IncludeTag? Ok, will try tomorrow. Maybe that'll help. In all cases, this context is gc-ed shortly after, I believe... so I see no reasons for big leaks at the tag-cache level. It leaks 200k every time site.jsl is run, so should be easy to find, right? :) Also, maybe it would help to give more details where to go... I think this was reported about very long ago so maybe a distribution maven-1.0.2 or such should have this bug ? easiest to run it against Maven's trunk really as it is compatible with Jelly RC2 (RC1 was broken, so it currently uses beta-4 until RC2 is released). RC2 won't work with Maven 1.0.x. If you want to give it a go: - check out Maven from SVN and build: svn co http://svn.apache.org/repos/asf/maven/maven-1/core/trunk maven-1/core/trunk svn co http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk maven-1/plugins/trunk - build maven inside maven-1/core/trunk (see http://www.apache.org/~brett/maven-stage-site/developers/building-from-sourc e.html, make sure you reassign a new MAVEN_HOME!) - run maven xdoc and watch memory go... - twiddle xdoc plugin and run maven plugin:install to test. Use the memory tag lib I just added to jelly to test. memory:gc/ and memory:showFree /. Hopefully I'll have more information tomorrow, I'm going to bed now. I'm keen to kill this before Jelly 1.0 if possible. Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] Base64.isArrayByteBase64() issue (WAS: codec : Bas64.isArrayByteBase64() issue)
Hello Ezra: Yes, it would be great if you could provide a unit test patch when you submit a bug report. This is more effective than me or another codec volunteer recreating the issue from scratch. It would be best to for you to create a Bugzilla issue when you want to report an issue in order to make sure it does not get lost. Thank you, Gary From: Ezra Epstein [mailto:[EMAIL PROTECTED] Sent: Monday, January 24, 2005 5:27 PM To: commons-dev@jakarta.apache.org Subject: RE: codec : Bas64.isArrayByteBase64() issue Oooops. Wrong patch file. Correct one is attached. = Ezra E. From: Ezra Epstein [mailto:[EMAIL PROTECTED] Sent: Mon 1/24/2005 5:22 PM To: commons-dev@jakarta.apache.org Subject: codec : Bas64.isArrayByteBase64() issue There seem to be 2 issues. 1. Only 255 byte values are used when creating base64Alphabet, but there are 256 possible values 2. octect (shouldn't that be octet ?) isn't shifted despite the fact that Java uses unsigned bytes. It is used unchanged as on offset into an array (zero based). As a result I can produce test cases that cause isBase64() to throw IndexOutOfBounds exceptions. While at it, I suggest one line be added to discardWhitespace() that will improve performance under some circumstances (i.e., when there is no whitespace in the input). Patch file is attached.Patch file is based on latest version in CVS of Base64.java file: 1.23 = Ezra E. P.S., I can provide a jUnit TestCase if that's useful.
RE: [jelly] Maven JSL memory leak and Jelly
Because I'd have to backport the fixes to the 1.0.x branch of Maven, which is closed for development now. - Brett Quoting Hans Gilde [EMAIL PROTECTED]: Why won't RC2 work with maven 1.0.x? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, January 24, 2005 7:30 AM To: Jakarta Commons Developers List Subject: Re: [jelly] Maven JSL memory leak and Jelly Paul Libbrecht wrote: Ideally, a test-case would be awesome, even if it refers to some far-away stylesheet... I'll try and narrow it down first by cutting down site.jsl to the minimum that leaks. Can you try calling .clear() on the result of this context.runScript(uri, output, isExport(), isInherit()) (and the other call). so try with context.clear() inside IncludeTag? Ok, will try tomorrow. Maybe that'll help. In all cases, this context is gc-ed shortly after, I believe... so I see no reasons for big leaks at the tag-cache level. It leaks 200k every time site.jsl is run, so should be easy to find, right? :) Also, maybe it would help to give more details where to go... I think this was reported about very long ago so maybe a distribution maven-1.0.2 or such should have this bug ? easiest to run it against Maven's trunk really as it is compatible with Jelly RC2 (RC1 was broken, so it currently uses beta-4 until RC2 is released). RC2 won't work with Maven 1.0.x. If you want to give it a go: - check out Maven from SVN and build: svn co http://svn.apache.org/repos/asf/maven/maven-1/core/trunk maven-1/core/trunk svn co http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk maven-1/plugins/trunk - build maven inside maven-1/core/trunk (see http://www.apache.org/~brett/maven-stage-site/developers/building-from-sourc e.html, make sure you reassign a new MAVEN_HOME!) - run maven xdoc and watch memory go... - twiddle xdoc plugin and run maven plugin:install to test. Use the memory tag lib I just added to jelly to test. memory:gc/ and memory:showFree /. Hopefully I'll have more information tomorrow, I'm going to bed now. I'm keen to kill this before Jelly 1.0 if possible. Thanks, Brett - 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]
RE: [jelly] Maven JSL memory leak and Jelly
There's definitely a leak in the include tag. Brett, I'm guessing that this leak also exists pre-RC2, right? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, January 24, 2005 7:30 AM To: Jakarta Commons Developers List Subject: Re: [jelly] Maven JSL memory leak and Jelly Paul Libbrecht wrote: Ideally, a test-case would be awesome, even if it refers to some far-away stylesheet... I'll try and narrow it down first by cutting down site.jsl to the minimum that leaks. Can you try calling .clear() on the result of this context.runScript(uri, output, isExport(), isInherit()) (and the other call). so try with context.clear() inside IncludeTag? Ok, will try tomorrow. Maybe that'll help. In all cases, this context is gc-ed shortly after, I believe... so I see no reasons for big leaks at the tag-cache level. It leaks 200k every time site.jsl is run, so should be easy to find, right? :) Also, maybe it would help to give more details where to go... I think this was reported about very long ago so maybe a distribution maven-1.0.2 or such should have this bug ? easiest to run it against Maven's trunk really as it is compatible with Jelly RC2 (RC1 was broken, so it currently uses beta-4 until RC2 is released). RC2 won't work with Maven 1.0.x. If you want to give it a go: - check out Maven from SVN and build: svn co http://svn.apache.org/repos/asf/maven/maven-1/core/trunk maven-1/core/trunk svn co http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk maven-1/plugins/trunk - build maven inside maven-1/core/trunk (see http://www.apache.org/~brett/maven-stage-site/developers/building-from-sourc e.html, make sure you reassign a new MAVEN_HOME!) - run maven xdoc and watch memory go... - twiddle xdoc plugin and run maven plugin:install to test. Use the memory tag lib I just added to jelly to test. memory:gc/ and memory:showFree /. Hopefully I'll have more information tomorrow, I'm going to bed now. I'm keen to kill this before Jelly 1.0 if possible. Thanks, Brett - 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: [jelly] Maven JSL memory leak and Jelly
Yup. AFAICT, it's been there since it's creation. Do you need some additional info from me? I'm happy to try to make a smaller test case and/or test with Maven later if required. - Brett Quoting Hans Gilde [EMAIL PROTECTED]: There's definitely a leak in the include tag. Brett, I'm guessing that this leak also exists pre-RC2, right? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, January 24, 2005 7:30 AM To: Jakarta Commons Developers List Subject: Re: [jelly] Maven JSL memory leak and Jelly Paul Libbrecht wrote: Ideally, a test-case would be awesome, even if it refers to some far-away stylesheet... I'll try and narrow it down first by cutting down site.jsl to the minimum that leaks. Can you try calling .clear() on the result of this context.runScript(uri, output, isExport(), isInherit()) (and the other call). so try with context.clear() inside IncludeTag? Ok, will try tomorrow. Maybe that'll help. In all cases, this context is gc-ed shortly after, I believe... so I see no reasons for big leaks at the tag-cache level. It leaks 200k every time site.jsl is run, so should be easy to find, right? :) Also, maybe it would help to give more details where to go... I think this was reported about very long ago so maybe a distribution maven-1.0.2 or such should have this bug ? easiest to run it against Maven's trunk really as it is compatible with Jelly RC2 (RC1 was broken, so it currently uses beta-4 until RC2 is released). RC2 won't work with Maven 1.0.x. If you want to give it a go: - check out Maven from SVN and build: svn co http://svn.apache.org/repos/asf/maven/maven-1/core/trunk maven-1/core/trunk svn co http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk maven-1/plugins/trunk - build maven inside maven-1/core/trunk (see http://www.apache.org/~brett/maven-stage-site/developers/building-from-sourc e.html, make sure you reassign a new MAVEN_HOME!) - run maven xdoc and watch memory go... - twiddle xdoc plugin and run maven plugin:install to test. Use the memory tag lib I just added to jelly to test. memory:gc/ and memory:showFree /. Hopefully I'll have more information tomorrow, I'm going to bed now. I'm keen to kill this before Jelly 1.0 if possible. Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly/src/test/org/apache/commons/jelly/core TestCoreMemoryLeak.java
hgilde 2005/01/24 18:53:56
Modified:jelly/src/test/org/apache/commons/jelly/core
TestCoreMemoryLeak.java
Log:
added a test for a leak in IncludeTag
Revision ChangesPath
1.2 +5 -1
jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestCoreMemoryLeak.java
Index: TestCoreMemoryLeak.java
===
RCS file:
/home/cvs/jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestCoreMemoryLeak.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestCoreMemoryLeak.java 28 Dec 2004 01:39:23 - 1.1
+++ TestCoreMemoryLeak.java 25 Jan 2005 02:53:56 - 1.2
@@ -29,7 +29,11 @@
}
public void testBasicScriptForLeak() throws Exception {
-assertTrue(runScriptManyTimes(c.jelly, 1) 20);
+assertTrue(Leak in core library, runScriptManyTimes(c.jelly,
1) 20);
+}
+
+public void testIncludeTagForLeak() throws Exception {
+assertTrue(Leak in include tag, runScriptManyTimes(a.jelly,
1) 20);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jelly] Maven JSL memory leak and Jelly
I just added a super-simple test case for the include tag to the core test suite. Include is a special kind of tag, so hopefully it's the only one leaking. Once we fix this problem, a retest will definitely be in order. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, January 24, 2005 9:47 PM To: Jakarta Commons Developers List Subject: RE: [jelly] Maven JSL memory leak and Jelly Yup. AFAICT, it's been there since it's creation. Do you need some additional info from me? I'm happy to try to make a smaller test case and/or test with Maven later if required. - Brett Quoting Hans Gilde [EMAIL PROTECTED]: There's definitely a leak in the include tag. Brett, I'm guessing that this leak also exists pre-RC2, right? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, January 24, 2005 7:30 AM To: Jakarta Commons Developers List Subject: Re: [jelly] Maven JSL memory leak and Jelly Paul Libbrecht wrote: Ideally, a test-case would be awesome, even if it refers to some far-away stylesheet... I'll try and narrow it down first by cutting down site.jsl to the minimum that leaks. Can you try calling .clear() on the result of this context.runScript(uri, output, isExport(), isInherit()) (and the other call). so try with context.clear() inside IncludeTag? Ok, will try tomorrow. Maybe that'll help. In all cases, this context is gc-ed shortly after, I believe... so I see no reasons for big leaks at the tag-cache level. It leaks 200k every time site.jsl is run, so should be easy to find, right? :) Also, maybe it would help to give more details where to go... I think this was reported about very long ago so maybe a distribution maven-1.0.2 or such should have this bug ? easiest to run it against Maven's trunk really as it is compatible with Jelly RC2 (RC1 was broken, so it currently uses beta-4 until RC2 is released). RC2 won't work with Maven 1.0.x. If you want to give it a go: - check out Maven from SVN and build: svn co http://svn.apache.org/repos/asf/maven/maven-1/core/trunk maven-1/core/trunk svn co http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk maven-1/plugins/trunk - build maven inside maven-1/core/trunk (see http://www.apache.org/~brett/maven-stage-site/developers/building-from-sourc e.html, make sure you reassign a new MAVEN_HOME!) - run maven xdoc and watch memory go... - twiddle xdoc plugin and run maven plugin:install to test. Use the memory tag lib I just added to jelly to test. memory:gc/ and memory:showFree /. Hopefully I'll have more information tomorrow, I'm going to bed now. I'm keen to kill this before Jelly 1.0 if possible. Thanks, Brett - 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]
RE: [jelly] Maven JSL memory leak and Jelly
Thanks Hans! That's what I was thinking of doing, so I'm glad you've got it under control. When I was testing, the size of the included JSL affected the amount of memory leaked, so I guess it is tag caching again? I tried a context.clear[Thread]ScriptData after the execution of runScript in include, but that didn't help. Unfortunately that's all I had time for this morning before work. Good luck... Cheers, Brett Quoting Hans Gilde [EMAIL PROTECTED]: I just added a super-simple test case for the include tag to the core test suite. Include is a special kind of tag, so hopefully it's the only one leaking. Once we fix this problem, a retest will definitely be in order. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, January 24, 2005 9:47 PM To: Jakarta Commons Developers List Subject: RE: [jelly] Maven JSL memory leak and Jelly Yup. AFAICT, it's been there since it's creation. Do you need some additional info from me? I'm happy to try to make a smaller test case and/or test with Maven later if required. - Brett Quoting Hans Gilde [EMAIL PROTECTED]: There's definitely a leak in the include tag. Brett, I'm guessing that this leak also exists pre-RC2, right? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, January 24, 2005 7:30 AM To: Jakarta Commons Developers List Subject: Re: [jelly] Maven JSL memory leak and Jelly Paul Libbrecht wrote: Ideally, a test-case would be awesome, even if it refers to some far-away stylesheet... I'll try and narrow it down first by cutting down site.jsl to the minimum that leaks. Can you try calling .clear() on the result of this context.runScript(uri, output, isExport(), isInherit()) (and the other call). so try with context.clear() inside IncludeTag? Ok, will try tomorrow. Maybe that'll help. In all cases, this context is gc-ed shortly after, I believe... so I see no reasons for big leaks at the tag-cache level. It leaks 200k every time site.jsl is run, so should be easy to find, right? :) Also, maybe it would help to give more details where to go... I think this was reported about very long ago so maybe a distribution maven-1.0.2 or such should have this bug ? easiest to run it against Maven's trunk really as it is compatible with Jelly RC2 (RC1 was broken, so it currently uses beta-4 until RC2 is released). RC2 won't work with Maven 1.0.x. If you want to give it a go: - check out Maven from SVN and build: svn co http://svn.apache.org/repos/asf/maven/maven-1/core/trunk maven-1/core/trunk svn co http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk maven-1/plugins/trunk - build maven inside maven-1/core/trunk (see http://www.apache.org/~brett/maven-stage-site/developers/building-from-sourc e.html, make sure you reassign a new MAVEN_HOME!) - run maven xdoc and watch memory go... - twiddle xdoc plugin and run maven plugin:install to test. Use the memory tag lib I just added to jelly to test. memory:gc/ and memory:showFree /. Hopefully I'll have more information tomorrow, I'm going to bed now. I'm keen to kill this before Jelly 1.0 if possible. Thanks, Brett - 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]
[jira] Created: (JELLY-199) Leak in IncludeTag or JellyContext.runScript
Leak in IncludeTag or JellyContext.runScript Key: JELLY-199 URL: http://issues.apache.org/jira/browse/JELLY-199 Project: jelly Type: Bug Components: core / taglib.core Versions: 1.0-RC1 Reporter: Hans Gilde Priority: Critical Now that the new tag caching has solved some problems, we have a leak in the IncludeTag. This leak probably comes from some interaction between JellyContext.runScript an the tag cache. I marked this one critical because it's (hopefully) the last leak affecting Maven. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] changes
How can I send some changes I have made in i18n? David? I see some guys putting cvs dif here. This is the normal process? Thanx Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33228] New: - Can't access mapped property in some case
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=33228. 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=33228 Summary: Can't access mapped property in some case Product: Commons Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Bean Utilities AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In the following case, access to mapped property fails by IllegalAccessException. Assume that 'bean' is an instance of package scoped class which implements public interface 'I', and interface 'I' has a method 'getValue(String key)'. In the case PropertyUtils.getProperty(bean, value(key)) is called, IllegalAccessException occures. -- 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 33228] - Can't access mapped property in some case
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=33228. 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=33228 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 05:15 --- Created an attachment (id=14083) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14083action=view) Sample program to see the issue This is sample codes to see the issue. After Compiling, please execute test.T.class, so IllegalAccessException will occure. -- 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]
[jira] Commented: (JELLY-199) Leak in IncludeTag or JellyContext.runScript
[ http://issues.apache.org/jira/browse/JELLY-199?page=comments#action_58027 ] Hans Gilde commented on JELLY-199: -- It's definitely something to do with JellyContext.runScript Leak in IncludeTag or JellyContext.runScript Key: JELLY-199 URL: http://issues.apache.org/jira/browse/JELLY-199 Project: jelly Type: Bug Components: core / taglib.core Versions: 1.0-RC1 Reporter: Hans Gilde Priority: Critical Now that the new tag caching has solved some problems, we have a leak in the IncludeTag. This leak probably comes from some interaction between JellyContext.runScript an the tag cache. I marked this one critical because it's (hopefully) the last leak affecting Maven. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28358] - [beanutils] Problems on indexed property with 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=28358. 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=28358 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 07:02 --- Created an attachment (id=14084) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14084action=view) Additional test for BeanUtilsBean to show problem with indexed property (In reply to comment #10) The only observation I have on this is that you are naming your property and indexed property methods with the same name. If you modify one of the method names does it then work properly? This came up again on the struts user list: http://marc.theaimsgroup.com/?l=struts-userm=110660079112504w=2 Having four accessor methods for an indexed property is legal according to 7.2 and 8.3.3 of the JavaBeans specification. I'm attaching a patch to BeanUtilsTestCase and a bean with a single indexed property to illustrate the problem. This test fails with the same error noted in the struts-user message: [java] There was 1 error: [java] 1) testIndexedProperty(org.apache.commons.beanutils.BeanUtilsTestCas e)java.lang.IllegalArgumentException: Cannot invoke org.apache.commons.beanutils .IndexedBean.setThings - argument type mismatch -- 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 28358] - [beanutils] Problems on indexed property with 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=28358. 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=28358 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 07:03 --- Created an attachment (id=14085) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14085action=view) IndexedBean required by the patch to BeanUtilsBean -- 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 28358] - [beanutils] Problems on indexed property with 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=28358. 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=28358 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #14085|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 07:07 --- Created an attachment (id=14086) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14086action=view) IndexedBean required by the patch to BeanUtilsTestCase (Comment was wrong, plus Bugzilla auto-detected source code as binary. Trying again...) -- 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]
[DBCP] Management of transactions...
Hello , Interests everything, that is connected to managements of transactions at use DBCP... Who Can will share experience or links? The database is not essential. The principle of work with transactions through DBCP is necessary... -- Best regards, ksv mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20903] - [digester] CallFactoryMethodRule
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=20903. 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=20903 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 08:24 --- Hi Gilles, Sorry it took so long to get around to having a look at this bugzilla entry. A lot of work has clearly gone into the attached code. However I don't really understand what the purpose of it is. Could you please subscribe to the commons-dev@jakarta.apache.org email list, and send a summary of what this code achieves, so that we can all discuss this patch? Note that when posting to commons-dev, the email subject should start with [digester]. If you can't subscribe for some reason, then an alternative is to post comments to this entry. However for involved discussions, using a web interface can be awkward.. I am concerned about the significant complexity of the code (as will other digester maintainers), and so would like to understand what benefits users would gain by having this CallFactoryMethodRule available Thanks for your offer of this code, and hope to see your email soon. Regards, Simon PS: send an email to [EMAIL PROTECTED] to subscribe. -- 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 21903] - [digester] Include filename or uri if Digester.parse(File file or String uri throws a SAXException
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=21903.
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=21903
--- Additional Comments From [EMAIL PROTECTED] 2005-01-25 08:32 ---
I don't understand this request. Under what circumstances would the user code
that called digester.parse and caught the exception not know the filename/uri of
the xml input it was parsing?
In other words, why is this not acceptable?
String filename=foo.xml;
try {
digester.parse(filename);
} catch(SAXException ex) {
System.err.println(
Failed to process file [ + filename + ]:
+ ex.getMessage());
}
--
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 33228] - Can't access mapped property in some case
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=33228. 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=33228 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 08:43 --- If you check the BeanUtils API (http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.6.1/docs/api/): the required characteristics of JavaBeans that are important for most development scenarios are listed here: * The class must be public, and provide a public constructor that accepts no arguments. This allows tools and applications to dynamically create new instances of your bean, without necessarily knowing what Java class name will be used ahead Class S was not public. If you make S public, your code works. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/network - New directory
burton 2005/01/24 23:53:47 jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/network - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
