[
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
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
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
[ 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
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
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
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
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
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
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
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.
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
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,
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.
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.
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.
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
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]
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
+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
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
+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
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.
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.
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.
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:
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
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
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
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.
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*
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.
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
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
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
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
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
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,
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
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
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
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,
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
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
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
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]
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
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
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
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.
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/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
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.
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.
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.
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
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.
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.
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.
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]
60 matches
Mail list logo
