[PATCH] [website] small fix in lang.xml
Spotted a wrong date in the resources section of the Lang homepage. Attached is a patch to change Oct 17, 2003 to Oct 17, 2002...a much more sensible date. :) mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-66) tag body as unescaped xml
The following comment has been added to this issue:
Author: Knut Wannheden
Created: Thu, 4 Sep 2003 2:33 AM
Body:
I suppose this is really two problems then. The first being that j:set sets the
value of the variable to a String value even though the body is XML. And the second
being that XMLOutput by default escapes text using XML entities.
But of course these two are linked to each other. If just one of them is fixed my
problem is solved.
The first one probably requires some thought and should maybe be implemented using a
new tag as you say.
The second one is really easy to solve, and makes a lot of sense IMHO. Also it makes
a workaround for the first problem possible:
j:set var=foo
foo/
/j:set
xml:parse var=foo
${foo}
/xml:parse
Of course that would already be possible now, but you would have to do the second step
like this:
xml:parse var=foo text=${foo}/
Now that these two don't behave the same is really ugly.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-66
Here is an overview of the issue:
-
Key: JELLY-66
Summary: tag body as unescaped xml
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
taglib.core
tags
Assignee:
Reporter: Knut Wannheden
Created: Mon, 28 Jul 2003 2:32 AM
Updated: Mon, 28 Jul 2003 2:32 AM
Description:
(I've reported this problem to commons-user before. See thread [jelly] body as
unescaped xml.)
The following snippet exposes the problem:
j:set var=foo
foo/
/j:set
${foo}
I expected the output to be foo/foo (or foo/) but it is actually
lt;foogt;lt;/foogt;.
The problem is that there is no way to control this behaviour. The reason is that the
factory methods of XMLOutput by default return an instance which escapes body text
with XML entities (as in the example). In many applications this makes sense, but ss
Jelly is primarily a tool to manipulate XML, I think the default should be _not_ to
escape XML. (Also read the discussion in http://www.mail-archive.com/[EMAIL
PROTECTED]/msg02750.html.)
In the example the variable foo actually gets assigned the String value
foo/foo, which is escaped when it's dereferenced using ${foo}. The question
is whether the value should really be a String. Shouldn't it really be XML?
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-66) tag body as unescaped xml
The following comment has been added to this issue:
Author: Knut Wannheden
Created: Thu, 4 Sep 2003 2:37 AM
Body:
Also note that changing XMLOutput's default behaviour would also make the patch of
JELLY-55 unnecessary. Or should there maybe be a global attribute escapexml to
control this? Much like the trim attribute.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-66
Here is an overview of the issue:
-
Key: JELLY-66
Summary: tag body as unescaped xml
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
taglib.core
tags
Assignee:
Reporter: Knut Wannheden
Created: Mon, 28 Jul 2003 2:32 AM
Updated: Mon, 28 Jul 2003 2:32 AM
Description:
(I've reported this problem to commons-user before. See thread [jelly] body as
unescaped xml.)
The following snippet exposes the problem:
j:set var=foo
foo/
/j:set
${foo}
I expected the output to be foo/foo (or foo/) but it is actually
lt;foogt;lt;/foogt;.
The problem is that there is no way to control this behaviour. The reason is that the
factory methods of XMLOutput by default return an instance which escapes body text
with XML entities (as in the example). In many applications this makes sense, but ss
Jelly is primarily a tool to manipulate XML, I think the default should be _not_ to
escape XML. (Also read the discussion in http://www.mail-archive.com/[EMAIL
PROTECTED]/msg02750.html.)
In the example the variable foo actually gets assigned the String value
foo/foo, which is escaped when it's dereferenced using ${foo}. The question
is whether the value should really be a String. Shouldn't it really be XML?
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/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]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/math NumberUtilsTest.java
psteitz 2003/09/04 00:27:12
Modified:lang/src/java/org/apache/commons/lang/math NumberUtils.java
lang/src/test/org/apache/commons/lang/math
NumberUtilsTest.java
Log:
Added stringToFloat to NumberUtils
Patch contributed by Fredrik Westermarck
Reviewed by Phil Steitz
Revision ChangesPath
1.11 +43 -1
jakarta-commons/lang/src/java/org/apache/commons/lang/math/NumberUtils.java
Index: NumberUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/math/NumberUtils.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- NumberUtils.java 18 Aug 2003 02:22:24 - 1.10
+++ NumberUtils.java 4 Sep 2003 07:27:12 - 1.11
@@ -69,6 +69,7 @@
* @author Phil Steitz
* @author Matthew Hawthorne
* @author a href=mailto:[EMAIL PROTECTED]Gary Gregory/a
+ * @author a href=mailto:[EMAIL PROTECTED]Fredrik Westermarck/a
* @since 2.0
* @version $Id$
*/
@@ -152,6 +153,47 @@
} catch (NumberFormatException nfe) {
return defaultValue;
}
+}
+
+/**
+ * pConvert a codeString/code to a codefloat/code, returning
+ * code0.0f/code if the conversion fails./p
+ *
+ * pIf the string codestr/code is codenull/code,
+ * code0.0f/code is returned./p
+ *
+ * @param str the string to convert, may be codenull/code
+ * @return the float represented by the string, or code0.0f/code
+ * if conversion fails
+ * @since 2.1
+ */
+public static float stringToFloat(String str) {
+return stringToFloat(str, 0.0f);
+}
+
+/**
+ * pConvert a codeString/code to a codefloat/code, returning a
+ * default value if the conversion fails./p
+ *
+ * pIf the string codestr/code is codenull/code, the default
+ * value is returned./p
+ *
+ * @param str the string to convert, may be codenull/code
+ * @param defaultValue the default value
+ * @return the float represented by the string, or defaultValue
+ * if conversion fails
+ * @since 2.1
+ */
+public static float stringToFloat(String str, float defaultValue) {
+ if(str==null) {
+ return defaultValue;
+ }
+
+ try {
+ return Float.parseFloat(str);
+ } catch (NumberFormatException nfe) {
+ return defaultValue;
+ }
}
//---
1.8 +20 -1
jakarta-commons/lang/src/test/org/apache/commons/lang/math/NumberUtilsTest.java
Index: NumberUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/math/NumberUtilsTest.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- NumberUtilsTest.java 18 Aug 2003 02:22:27 - 1.7
+++ NumberUtilsTest.java 4 Sep 2003 07:27:12 - 1.8
@@ -123,6 +123,25 @@
assertTrue(stringToInt(String,int) 2 failed,
NumberUtils.stringToInt(1234.5, 5) == 5);
}
+/**
+ * Test for float stringToFloat(String)
+ */
+public void testStringToFloatString() {
+assertTrue(stringToFloat(String) 1 failed,
NumberUtils.stringToFloat(-1.2345) == -1.2345f);
+assertTrue(stringToFloat(String) 2 failed,
NumberUtils.stringToFloat(1.2345) == 1.2345f);
+assertTrue(stringToFloat(String) 3 failed,
NumberUtils.stringToFloat(abc) == 0.0f);
+assertTrue(stringToFloat(empty) failed, NumberUtils.stringToFloat() ==
0.0f);
+assertTrue(stringToFloat(null) failed, NumberUtils.stringToFloat(null) ==
0.0f);
+}
+
+/**
+ * Test for float stringToFloat(String, float)
+ */
+public void testStringToFloatStringF() {
+assertTrue(stringToFloat(String,int) 1 failed,
NumberUtils.stringToFloat(1.2345, 5.1f) == 1.2345f);
+assertTrue(stringToFloat(String,int) 2 failed,
NumberUtils.stringToFloat(a, 5.0f) == 5.0f);
+}
+
public void testCreateNumber() {
//a lot of things can go wrong
assertEquals(createNumber(String) 1 failed, new Float(1234.5),
NumberUtils.createNumber(1234.5));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] [patch] Conversion of String to float
Fredrik Westermarck wrote: Hi! Here is a patch that adds stringToFloat(String) and stringToFloat(String, float) in o.a.c.lang.math.NumberUtils (including testcases in NumberUtilsTest). Patch applied. Thanks. Similar methods for doubles and longs would also be nice ;-) Phil - 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: Wanted: Regex[Input|Output]Stream
Leo Sutic observed:
Just a comment: Instead of using exceptions, how about this:
public interface MatchObserver {
public void onMatch (long offset, byte b, String pattern);
}
Excellent comment; even better. :-) And since we're not interrupting the
I/O stream with the exception, we can probably get rid of the byte.
An alternative would be to add an Observer (actually, wouldn't that be a
Listener, to remain consistent with Java terminology? :-)) with the pattern,
although it seems that none of the regex engines support compiling multiple
patterns, which I find truely bizzare. That would allow the Listener code
to execute as each pattern is found in the stream.
I would expect further interface tweaking, but the first thing we need is
code capable of supporting this construct.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wanted: Regex[Input|Output]Stream
Any reason why this wouldn't be better served if it were on the ORO or
Regexp lists?
Am just assuming they'd be the experts here.
Hen
On Thu, 4 Sep 2003, Noel J. Bergman wrote:
Leo Sutic observed:
Just a comment: Instead of using exceptions, how about this:
public interface MatchObserver {
public void onMatch (long offset, byte b, String pattern);
}
Excellent comment; even better. :-) And since we're not interrupting the
I/O stream with the exception, we can probably get rid of the byte.
An alternative would be to add an Observer (actually, wouldn't that be a
Listener, to remain consistent with Java terminology? :-)) with the pattern,
although it seems that none of the regex engines support compiling multiple
patterns, which I find truely bizzare. That would allow the Listener code
to execute as each pattern is found in the stream.
I would expect further interface tweaking, but the first thing we need is
code capable of supporting this construct.
--- Noel
-
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] Commented: (JELLY-64) Current Jelly doesn't compile with maven b10
The following comment has been added to this issue:
Author: Paul Libbrecht
Created: Thu, 4 Sep 2003 9:27 AM
Body:
Actually, this might mean the time for a soon release. Just of jelly.
Indeed, the tests run fine in jelly so there's few reasons except the patches of the
documentation (indicating that unit/xml/swing/swt maven instructions should be called
from their taglib directories).
We shall send patches in a few weeks about applet-running.
But as of now, it looks good.
Paul
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-64
Here is an overview of the issue:
-
Key: JELLY-64
Summary: Current Jelly doesn't compile with maven b10
Type: Bug
Status: Reopened
Priority: Critical
Time Spent: Unknown
Remaining: 2 hours
Project: jelly
Assignee:
Reporter: Paul Libbrecht
Created: Fri, 25 Jul 2003 6:47 AM
Updated: Thu, 4 Sep 2003 6:30 AM
Environment: Whichever JDK but maven 1.0b10
Description:
The project.xml files of jelly and its taglibs are somewhat old.
Aside of the fact that they don't validate, they also don't compile as they don't
contain a sourceDirectory child of build.
Also tests are not run as they don't contain a unitTestSourceDirectory...
The following should be added at least in all project.xml, I would like it if these
project.xml were valid also...
sourceDirectory${basedir}/src/java/sourceDirectory
unitTestSourceDirectory${basedir}/src/test/unitTestSourceDirectory
Also, unit-tests fail currently (the missing-tag unit-test fails).
Paul
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/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]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/math IntRangeTest.java
psteitz 2003/09/04 09:25:56
Modified:lang/src/test/org/apache/commons/lang/math IntRangeTest.java
Log:
Added missing constructor calls to complete path coverage in IntRangeTest.
Suggested by Janek Bogucki.
Revision ChangesPath
1.6 +7 -1
jakarta-commons/lang/src/test/org/apache/commons/lang/math/IntRangeTest.java
Index: IntRangeTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/math/IntRangeTest.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- IntRangeTest.java 18 Aug 2003 02:22:27 - 1.5
+++ IntRangeTest.java 4 Sep 2003 16:25:56 - 1.6
@@ -60,6 +60,8 @@
* Test cases for the [EMAIL PROTECTED] IntRange} class.
*
* @author Stephen Colebourne
+ * @author Janek Bogucki
+ * @author Phil Steitz
* @version $Id$
*/
public final class IntRangeTest extends AbstractRangeTest {
@@ -134,6 +136,10 @@
// test non Integer, for full coverage
Long fiveL = new Long(5L);
Long tenL = new Long(10L);
+nr = new IntRange(fiveL, tenL);
+assertEquals(five, nr.getMinimumNumber());
+assertEquals(ten, nr.getMaximumNumber());
+nr = new IntRange(tenL, fiveL);
assertEquals(five, nr.getMinimumNumber());
assertEquals(ten, nr.getMaximumNumber());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Should IntRangeTest use variables fiveL, tenL?
Stephen Colebourne wrote: Looks like nr = new IntRange(fiveL, tenL); is missing. Stephen Yes. Fixed now in CVS. Path coverage is now 100%. Thanks, Janek. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] [patch] Conversion of String to long/double
Hi! Here is the patch that adds stringToLong(String str), stringToLong(String str, long), stringToDouble(String str) and stringToDouble(String str, double), testcases are also included. I have also improved the testcase for stringToFloat(String). Hopefully I managed to get the diff right. I had to remove several lines by hand because of differences in the indentation (space vs tabs?). Is there any document that describes what codestyle commons-lang is supposed to use? commons-lang-NumberUtils.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] [patch] Conversion of String to long/double
On Thu, 4 Sep 2003, Fredrik Westermarck wrote: Hopefully I managed to get the diff right. I had to remove several lines by hand because of differences in the indentation (space vs tabs?). Is there any document that describes what codestyle commons-lang is supposed to use? In the long term, a maven site and checkstyle might enforce this, but in real terms the codestyle to use is the same as the nearest neighbour. So if you're adding a method to NumberUtils, follow the style of NumberUtils. If you're adding a new class to lang.time, follow the style of a core class in lang.time. If you're adding a new package, you should have a good general feel for the style already :) Basic rules of working on a community codebase I guess. There are some basic concepts in the DESIGN-GUIDE file which state how XxxUtils classes should be, and there is a checkstyle.xml in there, if you know how to read that. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[HiveMind] Why was overridable reomved from service?
As I see the option to override the contribution to a service was removed. The cvs log just states that this was a bad idea. Why was override a bad idea?. I thing it was a good idea. Especially in an api which requires a service a default working implementation could be defined (without requiring the user to do anything). A user however could overwrite it (maybe using the default implementation with differnt properties). I think this is what overridable was thought for. When overridable is not present I don't know a realy convient way with which you could achieve this. Ie if you use extension-points, it is much less convinient for the programmer (I guess you would always use more classes / interfaces) and generally less flexible for the user. Maybe you could tell me a way how to achive the same effect without overridable. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] New committer - Matthew Hawthorne
* Stephen Colebourne ([EMAIL PROTECTED]) wrote : Please can a new Apache committer account be created for Matthew: Requested username: matth Name: Matthew Hawthorne Email: [EMAIL PROTECTED] As soon as we get a signed CLA on file for him, sure. -Thom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)
Henri Yandell wrote: Hopefully I managed to get the diff right. I had to remove several lines by hand because of differences in the indentation (space vs tabs?). Is there any document that describes what codestyle commons-lang is supposed to use? In the long term, a maven site and checkstyle might enforce this, but in real terms the codestyle to use is the same as the nearest neighbour. Since I haven't used maven yet, will it still be possible to build with ant only? So if you're adding a method to NumberUtils, follow the style of NumberUtils. If you're adding a new class to lang.time, follow the style of a core class in lang.time. If you're adding a new package, you should have a good general feel for the style already :) Basic rules of working on a community codebase I guess. I used the same codestyle this time as for my previous patch to NumberUtils. When creating the diff for my previous patch I didn't have any problem with the indentation so I guess that the codestyle for the class changed when Phil commited it... :) There are some basic concepts in the DESIGN-GUIDE file which state how XxxUtils classes should be, and there is a checkstyle.xml in there, if you know how to read that. No, I don't know how checkstyle.xml works, but it never too late to learn... I'll have a look at them and try to create a codestyle for my IDE. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[General] Moving a component from sandbox to proper
Howdy, Is there a defined (and dare I ask, documented? ;)) process somewhere for moving a component from the commons sandbox into the commons proper. I imagine a CVS admin needs to move the files across the repositories, and someone (e.g. me) would update the commons web site, but I must be missing some steps? Thanks, Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-81) TagSupport doesn't compile
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-81 Here is an overview of the issue: - Key: JELLY-81 Summary: TagSupport doesn't compile Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 1 minute Project: jelly Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 12:30 PM Updated: Thu, 4 Sep 2003 12:30 PM Environment: Windows XP Java 1.4.2 Description: TagSupport doesn't compile due to unreachable catch block in the method getBodyText since the XMLOutput.createXMLOutput no longer throws an UnsupportedEncodingException exception. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/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: [General] Moving a component from sandbox to proper
Anyone with commit rights to sandbox and proper can move the files across repositories. Anyone with the usual site ones would handle changing things on the site. I don't think there's a documented process yet though, and I'm not sure how much is needed other than what you list. Bugzilla is the only one that springs to mind. Maybe announcing it as news in the newsletter. Hen On Thu, 4 Sep 2003, Shapira, Yoav wrote: Howdy, Is there a defined (and dare I ask, documented? ;)) process somewhere for moving a component from the commons sandbox into the commons proper. I imagine a CVS admin needs to move the files across the repositories, and someone (e.g. me) would update the commons web site, but I must be missing some steps? Thanks, Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-80) GbcTag doesn't compile
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-80 Here is an overview of the issue: - Key: JELLY-80 Summary: GbcTag doesn't compile Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 1 minute Project: jelly Components: tags Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 12:16 PM Updated: Thu, 4 Sep 2003 12:16 PM Environment: Windows XP Java 1.4.2 Description: GbcTag doesn't compile because it doesn't include imports for Tag and Insets. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/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: Wanted: Regex[Input|Output]Stream
Henri, Any reason why this wouldn't be better served if it were on the ORO or Regexp lists? I cc'd dfs, and embarrassingly, I forgot at the time that regex isn't in Commons. Irony is that ORO is talking about moving to Commons, AIUI. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-82) Add UseVector tag
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-82 Here is an overview of the issue: - Key: JELLY-82 Summary: Add UseVector tag Type: New Feature Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 30 minutes Project: jelly Components: tags Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 12:59 PM Updated: Thu, 4 Sep 2003 12:59 PM Environment: Windows XP Java 1.4.2 Description: In support of the updated ExpressionTableModel class, adding a Vector tag since DefaultTableModel uses Vectors instead of Lists for the rows. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-82) Add UseVector tag
The following issue has been updated: Updater: Sean Ferguson (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:00 PM Comment: Patch to the core tag library registering the UseVector tag. Changes: Attachment changed to CoreTagLibrary-patch.txt - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-82page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-82 Here is an overview of the issue: - Key: JELLY-82 Summary: Add UseVector tag Type: New Feature Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 30 minutes Project: jelly Components: tags Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 12:59 PM Updated: Thu, 4 Sep 2003 1:00 PM Environment: Windows XP Java 1.4.2 Description: In support of the updated ExpressionTableModel class, adding a Vector tag since DefaultTableModel uses Vectors instead of Lists for the rows. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-82) Add UseVector tag
The following issue has been updated: Updater: Sean Ferguson (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:00 PM Comment: The UseVector tag Changes: Attachment changed to UseVectorTag.java - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-82page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-82 Here is an overview of the issue: - Key: JELLY-82 Summary: Add UseVector tag Type: New Feature Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 30 minutes Project: jelly Components: tags Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 12:59 PM Updated: Thu, 4 Sep 2003 1:00 PM Environment: Windows XP Java 1.4.2 Description: In support of the updated ExpressionTableModel class, adding a Vector tag since DefaultTableModel uses Vectors instead of Lists for the rows. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-83) ExpressionTableModel now extends DefaultTableModel
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-83 Here is an overview of the issue: - Key: JELLY-83 Summary: ExpressionTableModel now extends DefaultTableModel Type: Improvement Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: 1 hour Project: jelly Components: tags Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 1:03 PM Updated: Thu, 4 Sep 2003 1:03 PM Environment: Windows XP Java 1.4.2 Description: Updated ExpressionTableModel to extend DefaultTableModel to reduce the amount of code necessary to describe the table model. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-83) ExpressionTableModel now extends DefaultTableModel
The following issue has been updated: Updater: Sean Ferguson (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:04 PM Comment: Updated expression table model. Changes: Attachment changed to ExpressionTableModel-patch.txt - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-83page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-83 Here is an overview of the issue: - Key: JELLY-83 Summary: ExpressionTableModel now extends DefaultTableModel Type: Improvement Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: 1 hour Project: jelly Components: tags Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 1:03 PM Updated: Thu, 4 Sep 2003 1:04 PM Environment: Windows XP Java 1.4.2 Description: Updated ExpressionTableModel to extend DefaultTableModel to reduce the amount of code necessary to describe the table model. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/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: [lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)
Fredrik Westermarck wrote: Henri Yandell wrote: Hopefully I managed to get the diff right. I had to remove several lines by hand because of differences in the indentation (space vs tabs?). Is there any document that describes what codestyle commons-lang is supposed to use? In the long term, a maven site and checkstyle might enforce this, but in real terms the codestyle to use is the same as the nearest neighbour. Since I haven't used maven yet, will it still be possible to build with ant only? The ant build still works fine. So if you're adding a method to NumberUtils, follow the style of NumberUtils. If you're adding a new class to lang.time, follow the style of a core class in lang.time. If you're adding a new package, you should have a good general feel for the style already :) Basic rules of working on a community codebase I guess. I used the same codestyle this time as for my previous patch to NumberUtils. When creating the diff for my previous patch I didn't have any problem with the indentation so I guess that the codestyle for the class changed when Phil commited it... :) If it did, that was certainly not intentional. Strangely, the checkstyle plugin is not complaining about any tabs in the code. Are you finding these in the tests or in the /java sources? There are some basic concepts in the DESIGN-GUIDE file which state how XxxUtils classes should be, and there is a checkstyle.xml in there, if you know how to read that. No, I don't know how checkstyle.xml works, but it never too late to learn... I'll have a look at them and try to create a codestyle for my IDE. Just check out the docs here: http://checkstyle.sourceforge.net/ Phil - 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] [patch] Conversion of String to long/double
Henri Yandell wrote: On Thu, 4 Sep 2003, Fredrik Westermarck wrote: Hopefully I managed to get the diff right. I had to remove several lines by hand because of differences in the indentation (space vs tabs?). Is there any document that describes what codestyle commons-lang is supposed to use? In general, follow Hen's sage advice below. If you are finding tabs in the source, however, these should be eliminated. If you run maven site:generate, the checkstyle plugin should flag this. It is also always a good idea to run either maven or ant clean dist and review the javadoc report to make sure that all tests run and the patch is not introducing any javadoc warnings or errors. Thanks for the patches! Phil In the long term, a maven site and checkstyle might enforce this, but in real terms the codestyle to use is the same as the nearest neighbour. So if you're adding a method to NumberUtils, follow the style of NumberUtils. If you're adding a new class to lang.time, follow the style of a core class in lang.time. If you're adding a new package, you should have a good general feel for the style already :) Basic rules of working on a community codebase I guess. There are some basic concepts in the DESIGN-GUIDE file which state how XxxUtils classes should be, and there is a checkstyle.xml in there, if you know how to read 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]
[jira] Updated: (JELLY-60) [SOAP] InvokeRaw tag and Username/Password features for Invoke tag
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:10 PM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to taglib.soap Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-60page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-60 Here is an overview of the issue: - Key: JELLY-60 Summary: [SOAP] InvokeRaw tag and Username/Password features for Invoke tag Type: New Feature Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.soap Assignee: Reporter: Dan Diephouse Created: Tue, 24 Jun 2003 2:24 PM Updated: Thu, 4 Sep 2003 1:10 PM Description: I decided to go ahead and create a soap:invoke tag that takes a whole soap request. I called it soap:invokeraw/. If anyone has a better name, I'm up for it . I found this is actually a great capability for testing since it allows me to completely simulate other toolkits - like MS.NET's Compact Framework. I just capture the request with Axis's tcpmon and throw it into jelly. So I use it like this: soap:invokeraw endpoint=http://localhost/some/service; var=response soap:Envelope soap:Header Your headers /soap:Header soap:Body ns:yourMethod / /soap:Body /soap:Envelope /soap:invokeraw Also in the patch is username/password support for the invoke tag. That one isn't well tested though. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/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]
[Daemon] Moving from commons-sandbox to commons CVS repository
Howdy, Per the recent promotion, I will move the daemon component's files from the jakarta-commons-sandbox CVS tree to the jakarta-commons one tonight around 10pm EST. If you have files checked out for daemon, please check them back in. I plan on doing the simplest move: $ cd /home/cvs $ mv jakarta-commons-sandbox/daemon jakarta-commons/daemon $ cvs remove jakarta-commons-sandbox/daemon $ cvs add jakarta-commons/daemon $ cvs commit -m Moved jakarta-commons-sandbox/daemon to commons proper jakarta-commons-sandbox/daemon jakarta-commons/daemon I'll update the commons web site after that. Thanks, Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jelly] Moving some bugs around
Hey all, I'm going to move some bugs around into some more coherent buckets in jira. I'll be adding new taglib component categories where we don't have any, and I'll probably delete the generic tags component once it is empty. Does it make sense to have distinct core and taglib.core buckets, or should they be combined? They are somewhat independent, but still part of the same distribution. - Morgan = Morgan Delagrange http://jakarta.apache.org/commons http://axion.tigris.org __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [General] Moving a component from sandbox to proper
Howdy, OK... I'll do the CVS moves and site updates, send out an announcement before and after... Thanks ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 1:34 PM To: Jakarta Commons Developers List Subject: Re: [General] Moving a component from sandbox to proper Anyone with commit rights to sandbox and proper can move the files across repositories. Anyone with the usual site ones would handle changing things on the site. I don't think there's a documented process yet though, and I'm not sure how much is needed other than what you list. Bugzilla is the only one that springs to mind. Maybe announcing it as news in the newsletter. Hen On Thu, 4 Sep 2003, Shapira, Yoav wrote: Howdy, Is there a defined (and dare I ask, documented? ;)) process somewhere for moving a component from the commons sandbox into the commons proper. I imagine a CVS admin needs to move the files across the repositories, and someone (e.g. me) would update the commons web site, but I must be missing some steps? Thanks, Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Moving some bugs around
On Thursday, September 4, 2003, at 02:01 PM, Morgan Delagrange wrote: Does it make sense to have distinct core and taglib.core buckets, or should they be combined? They are somewhat independent, but still part of the same distribution. I say combine them.. -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-38) [JFAce taglib] remove dependency + fix examples
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:20 PM Changes: description changed to environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to taglib.jface - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-38page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-38 Here is an overview of the issue: - Key: JELLY-38 Summary: [JFAce taglib] remove dependency + fix examples Type: New Feature Status: Assigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.jface Assignee: james strachan Reporter: Christiaan ten Klooster Created: Wed, 26 Feb 2003 6:25 AM Updated: Thu, 4 Sep 2003 1:20 PM Description: - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-40) [JFace taglib] PreferenceDialogTag handleSave event
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:21 PM Changes: environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to taglib.jface - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-40page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-40 Here is an overview of the issue: - Key: JELLY-40 Summary: [JFace taglib] PreferenceDialogTag handleSave event Type: Improvement Status: Assigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.jface Assignee: james strachan Reporter: Christiaan ten Klooster Created: Thu, 27 Feb 2003 6:01 AM Updated: Thu, 4 Sep 2003 1:21 PM Description: allows a script to be run on handleSave event, for example reloading the properties file. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-42) [SWT taglib] add cTabFolder + cTabItem widgets
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:21 PM Changes: description changed to environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to taglib.swt - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-42page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-42 Here is an overview of the issue: - Key: JELLY-42 Summary: [SWT taglib] add cTabFolder + cTabItem widgets Type: New Feature Status: Assigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.swt Assignee: james strachan Reporter: Christiaan ten Klooster Created: Wed, 5 Mar 2003 11:03 AM Updated: Thu, 4 Sep 2003 1:21 PM Description: - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-59) multi-part mime http request
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:23 PM Changes: Component changed to taglib.http - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-59page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-59 Here is an overview of the issue: - Key: JELLY-59 Summary: multi-part mime http request Type: New Feature Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 4 hours Project: jelly Components: taglib.http Assignee: Reporter: Bill Keese Created: Sun, 22 Jun 2003 9:55 PM Updated: Thu, 4 Sep 2003 1:23 PM Description: This patch support multi-part mime requests (in the HTTP library). I will attach the two new files, Part.java and MPPost.java. Besides those files you just need to modify HttpTagLibrary.java to include the new files: +registerTag(mppost, MppostTag.class); +registerTag(part, PartTag.class); - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-43) [jelly] Bug in TransformTag with nested ImportTag
The following issue has been updated:
Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED])
Date: Thu, 4 Sep 2003 1:27 PM
Changes:
timeoriginalestimate changed from 0
timeestimate changed from 0 minutes
Component changed to taglib.xml
Component changed from tags
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-43page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-43
Here is an overview of the issue:
-
Key: JELLY-43
Summary: [jelly] Bug in TransformTag with nested ImportTag
Type: Bug
Status: Assigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
taglib.xml
Assignee: peter royal
Reporter: Vincenz Braun
Created: Thu, 20 Mar 2003 1:45 PM
Updated: Thu, 4 Sep 2003 1:27 PM
Description:
when transforming an imported jelly file an exception is thrown:
Use case;
import.jelly:
?xml version=1.0 encoding=ISO-8859-1?
j:jelly xmlns:j=jelly:core xmlns:x=jelly:xml
x:transform xslt=import.xsl
j:import inherit=true uri=imported.jelly/
/x:transform
/j:jelly
imported.jelly:
?xml version=1.0 encoding=ISO-8859-1?
j:jelly xmlns:j=jelly:core
root/
/j:jelly
imported.xsl:
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE xsl:stylesheet
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template match=root
html/html
/xsl:template
/xsl:stylesheet
The exception is:
[snip] j:import could not import script
at org.apache.commons.jelly.tags.xml.TransformTag.doTag
(TransformTag.java:204)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.JellyTag.doTag(JellyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.JellyContext.runScript
(JellyContext.java:623)
at org.apache.commons.jelly.JellyContext.runScript
(JellyContext.java:529)
[snip]
[snip] j:import could not import script
at
org.apache.commons.jelly.tags.xml.TransformTag$TagBodyXMLReader.doInvokeBody
(TransformTag.java:527)
at
org.apache.commons.jelly.tags.xml.TransformTag$TagBodyXMLReader.parse
(TransformTag.java:482)
at org.apache.commons.jelly.tags.xml.TransformTag.doTag
(TransformTag.java:190)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.JellyTag.doTag(JellyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.JellyContext.runScript
(JellyContext.java:623)
at org.apache.commons.jelly.JellyContext.runScript
(JellyContext.java:529)
[snip]
Root cause
Exception in thread main
This script works:
import2.jelly:
?xml version=1.0 encoding=ISO-8859-1?
j:jelly xmlns:j=jelly:core xmlns:x=jelly:xml
j:import inherit=true uri=imported.jelly/
/j:jelly
-
After some investigation I found the following:
The root cause of this exception is an ArrayIndexOutOfBoundsException in
xalan. (Unfortunately you can not see this root exception in the stacktrace.
I had to use the debugger...)
My first guess was that is due to inproper setup of the
TransformContentHandler. This is right because the nested import tag does
not fire startDocument() and endDocument() events that the xalan content
handler depends on to setup itself.
This works with import and content that needs parsing.
in TagBodyXMLReader
/**
* Actually invoke the tag body to generate the SAX events
*
* @throws SAXException -
* Any SAX exception, possibly wrapping another exception.
*/
private void doInvokeBody() throws SAXException {
try {
if (this.shouldParseBody()) {
XMLReader anXMLReader = XMLReaderFactory.createXMLReader();
anXMLReader.setContentHandler(this.xmlOutput);
anXMLReader.setProperty
(LEXICAL_HANDLER_PROPERTY,this.xmlOutput);
StringWriter writer = new StringWriter();
this.tag.invokeBody(XMLOutput.createXMLOutput(writer));
Reader reader = new
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
ggregory2003/09/04 11:18:18
Modified:lang/src/test/org/apache/commons/lang
StringUtilsEqualsIndexOfTest.java
lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Added ordinalIndexOf() and associated unit tests.
Revision ChangesPath
1.9 +63 -1
jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsEqualsIndexOfTest.java
Index: StringUtilsEqualsIndexOfTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsEqualsIndexOfTest.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- StringUtilsEqualsIndexOfTest.java 18 Aug 2003 02:22:25 - 1.8
+++ StringUtilsEqualsIndexOfTest.java 4 Sep 2003 18:18:18 - 1.9
@@ -146,6 +146,68 @@
assertEquals(0, StringUtils.indexOf(aabaabaa, ));
}
+public void testOrdinalIndexOf() {
+assertEquals(-1, StringUtils.ordinalIndexOf(null, null, Integer.MIN_VALUE));
+assertEquals(-1, StringUtils.ordinalIndexOf(, null, Integer.MIN_VALUE));
+assertEquals(-1, StringUtils.ordinalIndexOf(, , Integer.MIN_VALUE));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, a,
Integer.MIN_VALUE));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, b,
Integer.MIN_VALUE));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, ab,
Integer.MIN_VALUE));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, ,
Integer.MIN_VALUE));
+
+assertEquals(-1, StringUtils.ordinalIndexOf(null, null, -1));
+assertEquals(-1, StringUtils.ordinalIndexOf(, null, -1));
+assertEquals(-1, StringUtils.ordinalIndexOf(, , -1));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, a, -1));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, b, -1));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, ab, -1));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, , -1));
+
+assertEquals(-1, StringUtils.ordinalIndexOf(null, null, 0));
+assertEquals(-1, StringUtils.ordinalIndexOf(, null, 0));
+assertEquals(-1, StringUtils.ordinalIndexOf(, , 0));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, a, 0));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, b, 0));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, ab, 0));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, , 0));
+
+assertEquals(-1, StringUtils.ordinalIndexOf(null, null, 1));
+assertEquals(-1, StringUtils.ordinalIndexOf(, null, 1));
+assertEquals(0, StringUtils.ordinalIndexOf(, , 1));
+assertEquals(0, StringUtils.ordinalIndexOf(aabaabaa, a, 1));
+assertEquals(2, StringUtils.ordinalIndexOf(aabaabaa, b, 1));
+assertEquals(1, StringUtils.ordinalIndexOf(aabaabaa, ab, 1));
+assertEquals(0, StringUtils.ordinalIndexOf(aabaabaa, , 1));
+
+assertEquals(-1, StringUtils.ordinalIndexOf(null, null, 2));
+assertEquals(-1, StringUtils.ordinalIndexOf(, null, 2));
+assertEquals(0, StringUtils.ordinalIndexOf(, , 2));
+assertEquals(1, StringUtils.ordinalIndexOf(aabaabaa, a, 2));
+assertEquals(5, StringUtils.ordinalIndexOf(aabaabaa, b, 2));
+assertEquals(4, StringUtils.ordinalIndexOf(aabaabaa, ab, 2));
+assertEquals(0, StringUtils.ordinalIndexOf(aabaabaa, , 2));
+
+assertEquals(-1, StringUtils.ordinalIndexOf(null, null, Integer.MAX_VALUE));
+assertEquals(-1, StringUtils.ordinalIndexOf(, null, Integer.MAX_VALUE));
+assertEquals(0, StringUtils.ordinalIndexOf(, , Integer.MAX_VALUE));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, a,
Integer.MAX_VALUE));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, b,
Integer.MAX_VALUE));
+assertEquals(-1, StringUtils.ordinalIndexOf(aabaabaa, ab,
Integer.MAX_VALUE));
+assertEquals(0, StringUtils.ordinalIndexOf(aabaabaa, ,
Integer.MAX_VALUE));
+
+assertEquals(-1, StringUtils.ordinalIndexOf(a, a, 0));
+assertEquals(0, StringUtils.ordinalIndexOf(a, a, 1));
+assertEquals(1, StringUtils.ordinalIndexOf(a, a, 2));
+assertEquals(2, StringUtils.ordinalIndexOf(a, a, 3));
+assertEquals(3, StringUtils.ordinalIndexOf(a, a, 4));
+assertEquals(4, StringUtils.ordinalIndexOf(a, a, 5));
+assertEquals(5, StringUtils.ordinalIndexOf(a, a, 6));
+assertEquals(6, StringUtils.ordinalIndexOf(a, a, 7));
+assertEquals(7, StringUtils.ordinalIndexOf(a, a, 8));
+assertEquals(8, StringUtils.ordinalIndexOf(a, a, 9));
+
[lang] StringUtils.ordinalIndexOf() and INDEX_NOT_FOUND
Hello All, I've added StringUtils.ordinalIndexOf() and introduced a new constant StringUtils.INDEX_NOT_FOUND = -1. Currently, only ordinalIndexOf uses this constant. I would like to get a fell if folks think that replacing (where appropriate), the -1 magic number usage in StringUtils with this constant is a good idea or refactoring gone wild. Thanks, Gary
Re: [General] Moving a component from sandbox to proper
would you mind creating a document (as you go along)? it will probably be of little use to you but those that come after you will certainly appreciate it. - robert On Thursday, September 4, 2003, at 06:16 PM, Shapira, Yoav wrote: Howdy, Is there a defined (and dare I ask, documented? ;)) process somewhere for moving a component from the commons sandbox into the commons proper. I imagine a CVS admin needs to move the files across the repositories, and someone (e.g. me) would update the commons web site, but I must be missing some steps? Thanks, Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-48) [SWT Taglibrary] dialog tag
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:17 PM Changes: Component changed to taglib.swt - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-48page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-48 Here is an overview of the issue: - Key: JELLY-48 Summary: [SWT Taglibrary] dialog tag Type: New Feature Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.swt Fix Fors: 1.0 Assignee: Reporter: Christiaan ten Klooster Created: Tue, 15 Apr 2003 5:57 AM Updated: Thu, 4 Sep 2003 1:17 PM Description: - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-41) [JFace taglib] set size applicationWindow
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:25 PM Changes: Component changed to taglib.jface Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-41page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-41 Here is an overview of the issue: - Key: JELLY-41 Summary: [JFace taglib] set size applicationWindow Type: Improvement Status: Assigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.jface Fix Fors: 1.0-beta-4 Assignee: james strachan Reporter: Christiaan ten Klooster Created: Tue, 4 Mar 2003 10:31 AM Updated: Thu, 4 Sep 2003 1:25 PM Description: - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-83) ExpressionTableModel now extends DefaultTableModel
The following issue has been updated: Updater: Sean Ferguson (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:21 PM Comment: This is the correct patch, previous one was missing the isEditable returning false. Changes: Attachment changed to ExpressionTableModel-patch.txt - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-83page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-83 Here is an overview of the issue: - Key: JELLY-83 Summary: ExpressionTableModel now extends DefaultTableModel Type: Improvement Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: 1 hour Project: jelly Components: tags Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 1:03 PM Updated: Thu, 4 Sep 2003 1:21 PM Environment: Windows XP Java 1.4.2 Description: Updated ExpressionTableModel to extend DefaultTableModel to reduce the amount of code necessary to describe the table model. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-77) [patch] Update jelly:util replace tag to replace entire strings
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 1:25 PM Changes: Component changed to taglib.util Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-77page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-77 Here is an overview of the issue: - Key: JELLY-77 Summary: [patch] Update jelly:util replace tag to replace entire strings Type: Improvement Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.util Assignee: Reporter: Paul O'Fallon Created: Sun, 24 Aug 2003 2:25 PM Updated: Thu, 4 Sep 2003 1:25 PM Environment: win xp, jdk1.3.1 Description: The replace tag documentation indicates that it replaces occurrances of strings, but the code only replaces instances of the first character in the old string with the first character in the new string. It also does not accept an empty string as the new string. I have a patch that updates the replace tag to replace whole strings, as well as accept empty strings, available here: http://home.earthlink.net/~ofallon/patches/jelly-util-diff.txt it updates both the code and the project.xml file to add a dependency on commons-lang. All of the existing util tag tests still passed after making this change. If this change is implemented, it may also make sense to change the attributes oldChar and newChar to just old and new, but I'll leave decision that up to someone else :-) Thanks, Paul - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-57) support encoding parameter for util:loadText
The following issue has been updated:
Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED])
Date: Thu, 4 Sep 2003 1:19 PM
Changes:
Component changed to taglib.util
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-57page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-57
Here is an overview of the issue:
-
Key: JELLY-57
Summary: support encoding parameter for util:loadText
Type: Improvement
Status: Unassigned
Priority: Minor
Time Spent: Unknown
Remaining: 2 hours
Project: jelly
Components:
taglib.util
Assignee:
Reporter: Bill Keese
Created: Sun, 22 Jun 2003 9:42 PM
Updated: Thu, 4 Sep 2003 1:19 PM
Description:
This patch lets you specify the encoding of files you read in with
LoadTextTag.java.
Index: LoadTextTag.java
===
RCS file:
/home/cvspublic/jakarta-commons/jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/LoadTextTag.java,v
retrieving revision 1.2
diff -u -r1.2 LoadTextTag.java
--- LoadTextTag.java 25 Jan 2003 19:31:48 - 1.2
+++ LoadTextTag.java 20 Jun 2003 04:06:02 -
@@ -64,7 +64,8 @@
import java.io.BufferedReader;
import java.io.File;
import java.io.FileNotFoundException;
-import java.io.FileReader;
+import java.io.UnsupportedEncodingException;
+import java.io.FileInputStream;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.IOException;
@@ -92,6 +93,7 @@
private String var;
private File file;
private String uri;
+private String encoding=utf-8;
public LoadTextTag() {
}
@@ -105,27 +107,31 @@
if (file == null uri == null) {
throw new JellyTagException( This tag must have a 'file' or 'uri'
specified );
}
-Reader reader = null;
+
+InputStream in = null;
if (file != null) {
if (! file.exists()) {
throw new JellyTagException( The file: + file + does not exist
);
}
-
try {
-reader = new FileReader(file);
+in = new FileInputStream(file);
} catch (FileNotFoundException e) {
throw new JellyTagException(could not find the file,e);
}
-}
-else {
-InputStream in = context.getResourceAsStream(uri);
+} else {
+in = context.getResourceAsStream(uri);
if (in == null) {
throw new JellyTagException( Could not find uri: + uri );
}
-// @todo should we allow an encoding to be specified?
-reader = new InputStreamReader(in);
}
-
+
+Reader reader = null;
+try {
+reader = new InputStreamReader(in, encoding);
+} catch (UnsupportedEncodingException e) {
+throw new JellyTagException(unsupported encoding,e);
+}
+
String text = null;
try {
@@ -177,6 +183,13 @@
*/
public void setFile(File file) {
this.file = file;
+}
+
+/**
+ * Sets the encoding to use to read the file
+ */
+public void setEncoding(String encoding) {
+this.encoding = encoding;
}
/**
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/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: [General] Moving a component from sandbox to proper
Howdy, No problem. I'll document the process, and put the document where? Yoav Shapira Millennium ChemInformatics -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 2:40 PM To: Jakarta Commons Developers List Subject: Re: [General] Moving a component from sandbox to proper would you mind creating a document (as you go along)? it will probably be of little use to you but those that come after you will certainly appreciate it. - robert On Thursday, September 4, 2003, at 06:16 PM, Shapira, Yoav wrote: Howdy, Is there a defined (and dare I ask, documented? ;)) process somewhere for moving a component from the commons sandbox into the commons proper. I imagine a CVS admin needs to move the files across the repositories, and someone (e.g. me) would update the commons web site, but I must be missing some steps? Thanks, Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [HiveMind] Why was overridable reomved from service?
As I see the option to override the contribution to a service
was removed.
The cvs log just states that this was
a bad idea. Why was override a bad idea?.
It led to a lot of ambiguities as I was adding new service models. I found other,
better ways to
accomplish the same kind of thing.
service id=OriginalService
/service
extension point-id=hivemind.FactoryDefaults
default symbol=ServiceToUse value=mymodule.OriginalService/
/extension
service id=MyDependentService ...
invoke-factory service-id=hivemind.BuilderFactory
construct ...
set-service property=otherService service-id=${ServiceToUse}/
/construct
/invoke-factory
/service
Using symbols for indirection, MyDependentService will be linked to OriginalService.
Now, in another module:
service id=ReplacementService ...
extension point-id=hivemind.ApplicationDefaults
default symbol=ServiceToUse value=newmodule.ReplacementService/
/extension
ApplicationDefaults override FactoryDefaults. MyDependentService will now be linked to
ReplacementService.
The advantage to this system is that ReplacementService can gain access to
OriginalService. This is
important to me, because this is a very common pattern in Tapestry, where it is common
to wrap the
default service implementation with a thin wrapper that adds some special features. I
want a
graceful way to accomplish the same thing in HiveMind.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [General] Moving a component from sandbox to proper
Could just start by documenting in Wiki, then migrating to the site later? That's how I feel Wiki should be used. To draft up documents that later get declared authentic and moved into the xdocs. Hen On Thu, 4 Sep 2003, Shapira, Yoav wrote: Howdy, No problem. I'll document the process, and put the document where? Yoav Shapira Millennium ChemInformatics -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 2:40 PM To: Jakarta Commons Developers List Subject: Re: [General] Moving a component from sandbox to proper would you mind creating a document (as you go along)? it will probably be of little use to you but those that come after you will certainly appreciate it. - robert On Thursday, September 4, 2003, at 06:16 PM, Shapira, Yoav wrote: Howdy, Is there a defined (and dare I ask, documented? ;)) process somewhere for moving a component from the commons sandbox into the commons proper. I imagine a CVS admin needs to move the files across the repositories, and someone (e.g. me) would update the commons web site, but I must be missing some steps? Thanks, Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [General] Moving a component from sandbox to proper
Howdy, Alright... Seems reasonable ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 3:03 PM To: Jakarta Commons Developers List Subject: RE: [General] Moving a component from sandbox to proper Could just start by documenting in Wiki, then migrating to the site later? That's how I feel Wiki should be used. To draft up documents that later get declared authentic and moved into the xdocs. Hen On Thu, 4 Sep 2003, Shapira, Yoav wrote: Howdy, No problem. I'll document the process, and put the document where? Yoav Shapira Millennium ChemInformatics -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 2:40 PM To: Jakarta Commons Developers List Subject: Re: [General] Moving a component from sandbox to proper would you mind creating a document (as you go along)? it will probably be of little use to you but those that come after you will certainly appreciate it. - robert On Thursday, September 4, 2003, at 06:16 PM, Shapira, Yoav wrote: Howdy, Is there a defined (and dare I ask, documented? ;)) process somewhere for moving a component from the commons sandbox into the commons proper. I imagine a CVS admin needs to move the files across the repositories, and someone (e.g. me) would update the commons web site, but I must be missing some steps? Thanks, Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [hivemind] Getting Registry in Initilizable
Sorry for delay in responding; it's hard to pick out the HiveMind stuff in this list; I need to add a filter. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: Christian Essl [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: [hivemind] Getting Registry in Initilizable First I want to congratulate and thank you for hivemind. It brings 80 % of what you need from a container for 20 % of the overhead in one and only one implementation. The eclipse style plugin style has proved to be very useful. And it's only getting better, with the new service models. However as I see a CoreService can get the Registry only from the static HiveMind.getDefault() method in an implementation independent way. I think this could lead to problems in enviroments where different registries are used in the same classloader or classloader-hierarchy. I.E. HiveMind is used by the ServletContainer and in the Webapps or different Frameworks within the same WebApp use their own Registry with their own modules.xml files (stored in separate directories). It is possible to get to the registry indirectly, by implementing Initializable. The ServiceExtensionPoint includes a module property, which includes a registry property, from which you can get anything. However, that's not the ideal way; if you need (or may need) another service, create a property for the service and have the hivemind.BuilderFactory assign the other service as a property of your implementation. The latest releases of HiveMind will create a deferred proxy to the service (so that you don't incur the overhead of constructing the service until you actually invoke a method on the service). Therefore I want to suggest that from the Initilizable.initializeService() parameters there would be a way to get the Registry instance which acutally manages the Service. For example the ServiceExtensionPoint interface could have a method getModule() from which you could get the Registry or the Registry would be passed directly as a parameter to the initilizeService() method. Yep, getModule() is already in there, in GenericExtensionPoint (super-interface of ServiceExtensionPoint). -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [HiveMind] Question about snapshot or releas
Javassist 2.6 is in ibiblio.com/maven, so it is possible to build HiveMind with no issues. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: Howard M. Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Sunday, August 31, 2003 11:47 AM To: 'Jakarta Commons Developers List' Subject: RE: [HiveMind] Question about snapshot or releas As I understand it, sandbox components are not supposed to be released. HiveMind builds with Maven, therefore if you can obtain a copy via anonymous CVS, you can build it as easily as I can ... with one caveat: Currently, HiveMind references library Javassist 2.6, which does not exist in the Maven repo (in fact, S. Chiba hasn't released this version of the library yet). If you are really interested, I can provide you with a copy. HiveMind will shortly enter a beta stage; I will be starting to drum up support for it so that we can progress into a full commons component; this requires we have some form of community for HiveMind. There will likely be some overlap with the Tapestry developers. Thanks for the interest; I'm quite proud of how well HiveMind has come out and am myself looking forward to using it in a number of areas ... including the 3.1 release of Tapestry. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: Christian Essl [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 8:41 AM To: [EMAIL PROTECTED] Subject: [HiveMind] Question about snapshot or releas What is to do or how long can it take until we can see a snapshot or release of HiveMind? - 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: [HiveMind] Proposal for adding Interceptors to a set of Services
This is an interesting idea; I'll take a peek when I get the chance. Some other ideas I've considered: a) Defining interceptor sets and identify one or more sets for a service. This is more of a drag in approach than a push in approach you described. b) Having a hivemind.InterceptorConsultant service that would be hooked into the code that constructs the interceptor stack. The consultant acts as a delegate to the ServiceExtensionPoint, and can provide additional interceptors to the normal list. The InterceptorConsultant could be driven off of an extension point and could achieve something very similar to what you've described. I've also through about: 1) A mechanism to allow you to enable/disable a contributed interceptor at runtime, perhaps driven off of system properties. 2) Passing parameters to interceptor factories in the same way that we do to ImplementationFactories. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: Christian Essl [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 1:58 PM To: [EMAIL PROTECTED] Subject: [HiveMind] Proposal for adding Interceptors to a set of Services I'd like to propose a module level tag, with which it is possible to register Interceptors with all in the Registry Services or all Services which implement a (some) certain interface(s). I've implemented a proposal for this feature and tested it - the diff is attached. These 'global-interceptors' have some advantages. Ie it would be possible to register (unregister) a Logger for all Services with just a little change to just one module. Also services implementing a certain interface could be given automatically parameters through such an Interceptor (Avalon like) without the need to specify the interceptor in each service. This therefore also reduces the amount of failure because of forgetting the interceptor. The same way a stop-service could be implemented, which informs all loaded Services that implement iE StopInterface when the program exits. For the code of my proposal I have changed the module xml format to include under module the following tag: global-interceptor service-id=id of ServiceInterceptorFactory order=interceptor-order class name=full.interface.name/ class name=full.interface.name2/ /global-interceptor The global-interceptor tag takes the same arguments as the interceptor tag. If no class tag is specified the interceptor will be registered with all Services in all modules. If there are one ore more class tags the Services which are intercepted must implement all the given interface(s) (AND). If there are more global-interceptors with the same ServiceInterceptorFactory-Id than the Interceptor is wrapped if at least one fits (OR) The ServiceInterceptorFactories specified and the Services requested of the Factory at creation time are never wrapped by global Interceptors (because of circularity - actually the implementation loads all the ServiceInterceptorFactories in RegistryBuilder.constructRegistry() as non deferred). My implementation works following: First the DescriptorParser builds up GlobalInterceptorDescriptors which are added to the ModuleDescriptor. In the RegistryBuilder one instance of orghivemind.impl.GlobalInterceptorRegistry is build up from the Descriptors. There is only one instance - held in an field - per RegistryBuilder (and so per Registry). This instance is used to hold all the mappings of interfaces to ServiceInterceptorContributions. The instance is given to each ServiceExtensionPointImpl when it is constructed. The point will use the instance in addInterceptors() to request the global- mapped Interceptors for itself and add it to it's own interceptors list. When the Modules are processed in the RegistryBuilder the GlobalInterceptorRegistry is populated but not yet ready to use. As the last step in the RegistryBuilder.constructRegistry() the GlobalInterceptorRegistry is build up. Here some optimizations are done (or better could be done) and all the needed ServiceInterceptorFactories are loaded - non deffered. Till this time the ServiceExtensionPointImpls will not use the GlobalInterceptorRegistry. This way Services (the ServiceInterceptorFactories and there requested Services) loaded by the GlobalInterceptorRegistry itself are not intercepted (except if defined in a Service-Extension), which is important for circularity. After this the GlobalInterceptorRegister is ready to be used by the ServiceExtesionPointImpls and all Service loaded are wrapped if they match. Finally there are also two Tests which you can see from the diff. -- Using M2, Opera's revolutionary e-mail client:
[net] Re: UnixFTPEntryParser - small fix (?)
Hi, I'm posting this message here on demand from Daniel who is very busy for the moment From: Matthieu Recouly [EMAIL PROTECTED] To : dfs [EMAIL PROTECTED] Date: Tue, 26 Aug 2003 10:12:44 +0200 Subject : Re: UnixFTPEntryParser - small fix (?) Hi :) First many thanks for having taken my message in consideration ;). You are right by saying that I require 2 spaces to be present between user and size (or date, or whatever the next field is). In fact my solution is really for users without group, here is the directory listing I get if I call ls -la command on the FTP server I deal with: ftp ls -la 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 122310 drwxr-xr-x 2 0other512 Oct 15 2002 . dr-xr-xr-x 3 0other512 Oct 24 2002 .. -rw-r- 13 XML fullxml 32378426 Aug 25 23:00 nxmlfeed.xml -rw-r--r-- 2 0other 8 Apr 25 2002 text.txt -rw-r- 4 XML fullxml 27669955 Oct 14 2002 xmlfeed.xml -rw-r- 4 XML fullxml 2506213 Oct 14 2002 xmlincremental.xml 226 Transfer complete. You will notice that there are actually two spaces between user and size, this because I think group is really omitted or inexistent, and not appended to user as an error. Anyway your solution does work and will indeed handle cases where group is also happened to user, so thank you for having thought about it :). Another thing I would like to discuss is on the same server I often have my transfers stuck when sending completion command when transfer is over. With small investigation, I arrived to conclusion that method __getReply() in class FTP will sometimes block on instruction String line = _controlInput.readLine(); (cannot give the source code line, sorry). One important think is I'm using jdk1.3.1, so maybe the BufferedReader used as _controlInput has a problem but I really doubt of that. What I did is changing from readLine() to read() within a loop in order to see what was exactly received by the client. I used this opportunity to add a time out when buffered reader has not been marked ready for more than 20 sec. It happens that what is received by client is exactly what is expected: a string terminated with a character of which code is 10: the '\n ' char. So I really don't understand with readLine() is sometimes stuck with this... any idea ? :/ (note: with my small loop + time out my transfers never block, maybe an internal timeout check should be added in this method ?) Thank you for your time. Matthieu. -- initial message --- From : Daniel F. Savarese [EMAIL PROTECTED] To : [EMAIL PROTECTED] Copies : [EMAIL PROTECTED] Date : Mon, 25 Aug 2003 18:29:53 -0400 Subject : Re: UnixFTPEntryParser - small fix (?) In message [EMAIL PROTECTED], =?iso-8859-1 ?Q?Matthieu_Recouly?= writes: Your parser does not allow to retrieve files list on a ftp server that uses weird Unix listing style as described on http://www.javaworld.com/javaworld/jw-04-2003/jw-0404-ftp-p2.html This is when user has no group, your parser will put the size value inside group's one, a null user value, and 0 in the size field. I think what happens is that the FTP server ends up omitting a space between the user and group in the listing, although it's certainly possible some FTP servers out there forgo listing the group altogether. Regardless, it's the same effect: one less space-separated field. To correct that I changed line 85 of UnixFTPEntryParser.java, from version 1.0.1-dev, changing the section of regexp used to parse entries that concerns file's group: changed + (\\S+)\\s+ to + (\\S+)?\\s+ (added question mark) I think there's a problem with the change as proposed because when combined with the previous expression that matches the user, you wind up mandating at least two spaces before the date instead of one. Alternatives are to change the user expression to (\\S+)\\s* and the group to what you suggest, but for the sake of clarity I recommend using the following for the group pattern (?:(\\S+)\\s+)?. Also, I believe EnterpriseUnixFTPEntryParser handles the listing format just fine. In any case, I applied the change using my variation of the pattern and added test cases to UnixFTPEntryParser.java and EnterpriseUnixFTPEntryParser.java for that listing format. Many thanks for the suggestion! daniel Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] retiring old release directory
i've now completed this work. - robert On Monday, September 1, 2003, at 10:19 PM, robert burrell donkin wrote: http://jakarta.apache.org/builds/jakarta-commons/release is the old, unmirrored directory. most (all?) new releases have been created in the mirrored directories (good work!) but there are still many older releases there and some components do not have mirrored releases available. now that infrastructure have completed the move to minotaur, it's time that we think about implementing the official ASF distribution policy. (all committers should have read received this posted to their apache account.) this is important since the ASF have only a limited amount of bandwidth to supply both the website and downloads. i'll volunteer to execute the necessary changes. my plan is: 1. ensure the latest release for every component is available from the mirrors 2. copy all older releases to the archives 3. redirect all requests under the directory structure to a new page explaining that you should use the mirrors and giving links to the jakarta download pages 4. delete the old directory structure this decision will be taken by lazy consensus so unless anyone objects (or finds some flaws in my plan ;), i'll start executing this plan some time after 12 noon GMT wednesday. - robert - 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/net/xdocs changes.xml
dfs 2003/09/04 13:32:43
Modified:net/src/java/org/apache/commons/net/nntp NNTP.java
NNTPClient.java NNTPCommand.java NNTPReply.java
net/xdocs changes.xml
Added: net/src/java/examples ExtendedNNTPOps.java
Log:
Applied patch (albeit slightly altered) from
Rory Winston [EMAIL PROTECTED] that adds
extended NNTP XOVER, LIST ACTIVE, and AUTHINFO commands.
Revision ChangesPath
1.1 jakarta-commons/net/src/java/examples/ExtendedNNTPOps.java
Index: ExtendedNNTPOps.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution,
*if any, must include the following acknowledgment:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself,
*if and wherever such third-party acknowledgments normally appear.
*
* 4. The names Apache and Apache Software Foundation and
*Apache Commons must not be used to endorse or promote products
*derived from this software without prior written permission. For
*written permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache,
*nor may Apache appear in their name, without
*prior written permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package examples;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.Reader;
import java.io.PrintWriter;
import java.util.ArrayList;
import java.util.StringTokenizer;
import org.apache.commons.net.io.DotTerminatedMessageReader;
import org.apache.commons.net.nntp.NNTPClient;
import org.apache.commons.net.nntp.NewsgroupInfo;
public class ExtendedNNTPOps {
// simple class that encapsulates some basic info about an NNTP article
class Article {
private int articleNumber;
private String subject;
private String date;
private String articleId;
private String from;
private StringBuffer header;
public Article()
{
header = new StringBuffer();
}
public void addHeaderField(String name, String val) {
header.append(name);
header.append(: );
header.append(val);
header.append('\n');
}
public String getArticleId() {
return articleId;
}
public int getArticleNumber() {
return articleNumber;
}
public String getDate() {
return date;
}
public String getFrom() {
return from;
}
public String getSubject() {
return subject;
}
public void
[net] Re: NNTP Patches
In message [EMAIL PROTECTED], R ory Winston writes: Sorry to send this to you directly - I just wanted to find out if you had any problems applying the NNTP patch that I sent to you? I'm behind on many Jakarta obligations. Thanks for the resend. I was able to apply it today (sending it as an attachment indeeded prevented your mailer from inserting newlines to wrap lines) and just committed the addition. Many thanks for taking the time to add those extended NNTP commands. The only alterations I made to the patch were to auto-indent the code more or less how it looks like Maven's been doing it and I changed the ExtendedNNTPOps.java example program to take server, user, and password arguments from the command line. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-83) ExpressionTableModel now extends DefaultTableModel
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:01 PM Changes: Component changed to taglib.swing Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-83page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-83 Here is an overview of the issue: - Key: JELLY-83 Summary: ExpressionTableModel now extends DefaultTableModel Type: Improvement Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: 1 hour Project: jelly Components: taglib.swing Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 1:03 PM Updated: Thu, 4 Sep 2003 4:01 PM Environment: Windows XP Java 1.4.2 Description: Updated ExpressionTableModel to extend DefaultTableModel to reduce the amount of code necessary to describe the table model. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-82) Add UseVector tag
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:02 PM Changes: Component changed to taglib.core Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-82page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-82 Here is an overview of the issue: - Key: JELLY-82 Summary: Add UseVector tag Type: New Feature Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 30 minutes Project: jelly Components: taglib.core Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 12:59 PM Updated: Thu, 4 Sep 2003 4:02 PM Environment: Windows XP Java 1.4.2 Description: In support of the updated ExpressionTableModel class, adding a Vector tag since DefaultTableModel uses Vectors instead of Lists for the rows. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-24) Release Issue 2 - Jelly public API
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:08 PM Changes: Component changed to documentation - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-24page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-24 Here is an overview of the issue: - Key: JELLY-24 Summary: Release Issue 2 - Jelly public API Type: Task Status: Assigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: documentation Fix Fors: 1.0 Assignee: Morgan Delagrange Reporter: Morgan Delagrange Created: Thu, 23 Jan 2003 12:32 PM Updated: Thu, 4 Sep 2003 4:08 PM Description: We started a discussion on what constitutes our public-facing API, but so far we haven't nailed it down: http://marc.theaimsgroup.com/?t=10415308592r=1w=2 - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-54) enhance documentation (gettingstarted.html) and fix errors.
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:09 PM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to documentation - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-54page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-54 Here is an overview of the issue: - Key: JELLY-54 Summary: enhance documentation (gettingstarted.html) and fix errors. Type: Bug Status: Assigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: documentation Assignee: peter royal Reporter: Ralf Hauser Created: Wed, 21 May 2003 10:46 AM Updated: Thu, 4 Sep 2003 4:09 PM Description: I was using the following versions: maven-1.0-beta-9\plugins\maven-jellydoc-plugin-1.0\plugin-resources\ (doesn't really fit with the version available in the form.) 1) The directory project.xml is in is: maven-1.0-beta-9\plugins\maven-jellydoc-plugin-1.0 why not mentioning this on the html page? 2) I had to go one directory higher for maven test to be able to run it: Otherwise, I got: java.io.FileNotFoundException: c:\data\MyProj\maven-1.0-beta-9\plugins\maven-jellydoc-plugin-1.0\..\project.xml (The system cannot find the file specified) 3) Then maven test downloaded everything, subsquently it had the following problems: ... Attempting to download velocity-dvsl-0.45.jar. . Attempting to download clover-1.0.jar. . [mkdir] Created dir: C:\data\MyDocRalf\bin\Java\jars\maven-1.0-beta-9\plugin s\maven-jellydoc-plugin-1.0\plugin-resources\target\classes [echo] No java source files to compile. [mkdir] Created dir: C:\data\MyDocRalf\bin\Java\jars\maven-1.0-beta-9\plugin s\maven-jellydoc-plugin-1.0\plugin-resources\target\test-classes [mkdir] Created dir: C:\data\MyDocRalf\bin\Java\jars\maven-1.0-beta-9\plugin s\maven-jellydoc-plugin-1.0\plugin-resources\target\test-reports [echo] No test source files to compile. [echo] No tests to run. BUILD SUCCESSFUL Total time: 4 minutes 36 seconds 4) Then the above referenced pages says run all the example Jelly scripts, compile all the code and build and run all the unit test cases which ones? - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-11) The Tag Reference should understand tags like JellySwing
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:12 PM Changes: environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to documentation Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-11page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-11 Here is an overview of the issue: - Key: JELLY-11 Summary: The Tag Reference should understand tags like JellySwing Type: Improvement Status: Assigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: documentation Assignee: james strachan Reporter: james strachan Created: Wed, 30 Oct 2002 6:00 AM Updated: Thu, 4 Sep 2003 4:12 PM Description: Right now only statically defined Tag implementations are detected with the doclet that makes the Tag Reference for Jelly... http://jakarta.apache.org/commons/sandbox/jelly/tags.html It would rock if we could instantiate each tag library and somehow introspect it to find its attributes for the reference. e.g. the JellySwing tags typicaly map to a Swing component like JFrame, JTable and so on. Then each tag supports each property on the underlying bean. if we could represent this in the Tag Reference it would make them much easier to use! - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-25) Release Issue 3 - Exception handling
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:10 PM Changes: environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to core / taglib.core - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-25page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-25 Here is an overview of the issue: - Key: JELLY-25 Summary: Release Issue 3 - Exception handling Type: Task Status: Assigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: core / taglib.core Assignee: peter royal Reporter: Morgan Delagrange Created: Thu, 23 Jan 2003 5:22 PM Updated: Thu, 4 Sep 2003 4:10 PM Description: See email thread: http://marc.theaimsgroup.com/?t=10433551327r=1w=2 I think Jelly exception handling needs to be more methodical. I volunteer. :) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-66) tag body as unescaped xml
The following issue has been updated:
Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED])
Date: Thu, 4 Sep 2003 4:11 PM
Changes:
Component changed from tags
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-66page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-66
Here is an overview of the issue:
-
Key: JELLY-66
Summary: tag body as unescaped xml
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
core / taglib.core
Assignee:
Reporter: Knut Wannheden
Created: Mon, 28 Jul 2003 2:32 AM
Updated: Thu, 4 Sep 2003 4:11 PM
Description:
(I've reported this problem to commons-user before. See thread [jelly] body as
unescaped xml.)
The following snippet exposes the problem:
j:set var=foo
foo/
/j:set
${foo}
I expected the output to be foo/foo (or foo/) but it is actually
lt;foogt;lt;/foogt;.
The problem is that there is no way to control this behaviour. The reason is that the
factory methods of XMLOutput by default return an instance which escapes body text
with XML entities (as in the example). In many applications this makes sense, but ss
Jelly is primarily a tool to manipulate XML, I think the default should be _not_ to
escape XML. (Also read the discussion in http://www.mail-archive.com/[EMAIL
PROTECTED]/msg02750.html.)
In the example the variable foo actually gets assigned the String value
foo/foo, which is escaped when it's dereferenced using ${foo}. The question
is whether the value should really be a String. Shouldn't it really be XML?
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-80) GbcTag doesn't compile
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:13 PM Changes: Component changed to taglib.swing Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-80page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-80 Here is an overview of the issue: - Key: JELLY-80 Summary: GbcTag doesn't compile Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 1 minute Project: jelly Components: taglib.swing Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 12:16 PM Updated: Thu, 4 Sep 2003 4:13 PM Environment: Windows XP Java 1.4.2 Description: GbcTag doesn't compile because it doesn't include imports for Tag and Insets. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-28) Bad entity processing
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:12 PM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to core / taglib.core Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-28page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-28 Here is an overview of the issue: - Key: JELLY-28 Summary: Bad entity processing Type: Bug Status: Assigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: core / taglib.core Assignee: james strachan Reporter: Incze Lajos Created: Thu, 30 Jan 2003 7:44 PM Updated: Thu, 4 Sep 2003 4:12 PM Environment: No special environment. Description: Have a file, name it a.xml with this content: - ?xml version=1.0? !DOCTYPE a [ !ENTITY x y ] ax;/a - Run the below simple (maven) jelly script: - project default=java:jar xmlns:j=jelly:core xmlns:x=jelly:xml goal name=emnl:test x:parse var=doc xml=a.xml/ echox:copyOf select=$doc//echo /goal /project - The result will be this: - emnl:test: [echo] ?xml version=1.0 encoding=UTF-8? ax;y/a BUILD SUCCESSFUL - I'm aware of the fact that the bug originally comes from dom4j. The below dom4j program fragment - SAXReader xmlReader = new SAXReader(); Document doc = xmlReader.read(a.xml); XMLWriter writer = new XMLWriter(System.out); writer.write(doc); writer.flush(); - will output this result: - ?xml version=1.0 encoding=UTF-8? !DOCTYPE aax;/a - which is bad (not even well-formed). I've filed this issue at the dom4j bugtracker (http://sourceforge.net/tracker/?group_id=16035atid=116035) under the number 676427, with some notes one the possible resolution. But as we can see, the jelly xml tag adds a twist to the dom4j bug, it inserts both the entity and the entity value into the tag. Thanks, incze - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JELLY-39) [JFace taglib] PreferenceDialogTag parent patch
Message:
The following issue has been reopened.
Reopener: Morgan Delagrange
Date: Thu, 4 Sep 2003 4:15 PM
moving to jface category
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-39
Here is an overview of the issue:
-
Key: JELLY-39
Summary: [JFace taglib] PreferenceDialogTag parent patch
Type: New Feature
Status: Reopened
Priority: Minor
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
taglib.jface
Fix Fors:
1.0
Assignee: james strachan
Reporter: Christiaan ten Klooster
Created: Thu, 27 Feb 2003 5:31 AM
Updated: Thu, 4 Sep 2003 4:15 PM
Description:
allow preferenceDialog parent=${applicationWindow.Shell}
You need this if the preferencesDialog is in a separate file.
It would perhaps be better if 'findAncestorWithClass(ApplicationWindowTag.class)'
would return the ApplicationWindowTag. Then you can use
preferenceDialog parent=${applicationWindow}
James, could you also add a taglib.jface and taglib.swt component in JIRA ?
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-1) break variable storage away from the JellyContext
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:14 PM Changes: environment changed to Component changed to core / taglib.core - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-1page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-1 Here is an overview of the issue: - Key: JELLY-1 Summary: break variable storage away from the JellyContext Type: New Feature Status: Assigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: core / taglib.core Assignee: james strachan Reporter: bob mcwhirter Created: Thu, 18 Jul 2002 1:47 PM Updated: Thu, 4 Sep 2003 4:14 PM Description: Implement a simpler Scope interface to be used by JellyContext for variable storage and retrieval, to allow for arbitrary integrations for storage. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-39) [JFace taglib] PreferenceDialogTag parent patch
The following issue has been updated:
Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED])
Date: Thu, 4 Sep 2003 4:15 PM
Changes:
Component changed to taglib.jface
Component changed from tags
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-39page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-39
Here is an overview of the issue:
-
Key: JELLY-39
Summary: [JFace taglib] PreferenceDialogTag parent patch
Type: New Feature
Status: Reopened
Priority: Minor
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
taglib.jface
Fix Fors:
1.0
Assignee: james strachan
Reporter: Christiaan ten Klooster
Created: Thu, 27 Feb 2003 5:31 AM
Updated: Thu, 4 Sep 2003 4:15 PM
Description:
allow preferenceDialog parent=${applicationWindow.Shell}
You need this if the preferencesDialog is in a separate file.
It would perhaps be better if 'findAncestorWithClass(ApplicationWindowTag.class)'
would return the ApplicationWindowTag. Then you can use
preferenceDialog parent=${applicationWindow}
James, could you also add a taglib.jface and taglib.swt component in JIRA ?
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-39) [JFace taglib] PreferenceDialogTag parent patch
Message:
The following issue has been closed.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-39
Here is an overview of the issue:
-
Key: JELLY-39
Summary: [JFace taglib] PreferenceDialogTag parent patch
Type: New Feature
Status: Closed
Priority: Minor
Resolution: FIXED
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
taglib.jface
Fix Fors:
1.0
Assignee: james strachan
Reporter: Christiaan ten Klooster
Created: Thu, 27 Feb 2003 5:31 AM
Updated: Thu, 4 Sep 2003 4:15 PM
Description:
allow preferenceDialog parent=${applicationWindow.Shell}
You need this if the preferencesDialog is in a separate file.
It would perhaps be better if 'findAncestorWithClass(ApplicationWindowTag.class)'
would return the ApplicationWindowTag. Then you can use
preferenceDialog parent=${applicationWindow}
James, could you also add a taglib.jface and taglib.swt component in JIRA ?
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-45) resource lookup in compiled scripts does not work properly
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:15 PM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to core / taglib.core - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-45page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-45 Here is an overview of the issue: - Key: JELLY-45 Summary: resource lookup in compiled scripts does not work properly Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: core / taglib.core Assignee: Reporter: Vincenz Braun Created: Thu, 20 Mar 2003 1:49 PM Updated: Thu, 4 Sep 2003 4:15 PM Description: Take the following code snippet: JellyContext context = new JellyContext(); URL url = ImportTestcase.class.getResource(/resources/import.jelly); XMLOutput out = XMLOutput.createXMLOutput(System.out); // this works because of the created child context that has knowledge // of the URL context.runScript(url, out); // This does not work because context has no currentURL set // This results in a NullPointerException when resolving the // stylesheet Script script = context.compileScript(url); script.run(context, out); out.flush() A compiled script should manage the lookup of referenced resources by its own regardless of the context set. If you cache scripts and use different contexts you do not always know where the script is from. That's why context.setCurrentURL(...) is no solution. // import.jelly ?xml version=1.0 encoding=ISO-8859-1? j:jelly xmlns:j=jelly:core xmlns:x=jelly:xml x:transform xslt=import.xsl x:param name=language value=DE/ root/ /x:transform /j:jelly - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-8) jexl parse error
The following issue has been updated:
Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED])
Date: Thu, 4 Sep 2003 4:17 PM
Changes:
timeoriginalestimate changed from 0
timeestimate changed from 0 minutes
Component changed to core / taglib.core
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-8page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-8
Here is an overview of the issue:
-
Key: JELLY-8
Summary: jexl parse error
Type: Bug
Status: Assigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
core / taglib.core
Assignee: james strachan
Reporter: Jason Horman
Created: Sat, 28 Sep 2002 3:10 AM
Updated: Thu, 4 Sep 2003 4:17 PM
Environment: java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)
Description:
The following jelly script:
jelly xmlns=jelly:core xmlns:log=jelly:log xmlns:bsh=jelly:beanshell
set var=testStr value=hello/
log:info${testStr.charAt(-2)}/log:info
/jelly
Throws the exception below. Changing the number to positive fixes the error. I realize
this would cause an OOB but it is just to demonstrate that something seems to be wrong
with the parsing of the expression.
org.apache.commons.jexl.parser.ParseException: Encountered ( - at line 1, column 15.
Was expecting one of:
|| ...
or ...
...
and ...
| ...
^ ...
...
== ...
eq ...
!= ...
ne ...
...
lt ...
...
gt ...
= ...
le ...
= ...
ge ...
+ ...
- ...
* ...
/ ...
div ...
% ...
mod ...
; ...
[ ...
( INTEGER_LITERAL ...
( FLOAT_LITERAL ...
( true ...
( false ...
( STRING_LITERAL ...
( null ...
( IDENTIFIER ...
( ( ...
( empty ...
( size ...
( ~ ...
( ! ...
( not ...
( ) ...
. ...
= ...
at
org.apache.commons.jexl.parser.Parser.generateParseException(Parser.java:3193)
at org.apache.commons.jexl.parser.Parser.jj_consume_token(Parser.java:3077)
at org.apache.commons.jexl.parser.Parser.ExpressionExpression(Parser.java:1519)
at org.apache.commons.jexl.parser.Parser.Statement(Parser.java:1492)
at org.apache.commons.jexl.parser.Parser.JexlScript(Parser.java:58)
at org.apache.commons.jexl.parser.Parser.parse(Parser.java:18)
at
org.apache.commons.jexl.ExpressionFactory.createNewExpression(ExpressionFactory.java:124)
at
org.apache.commons.jexl.ExpressionFactory.createExpression(ExpressionFactory.java:88)
at
org.apache.commons.jelly.expression.jexl.JexlExpressionFactory.createExpression(JexlExpressionFactory.java:102)
at
org.apache.commons.jelly.expression.CompositeExpression.parse(CompositeExpression.java:128)
at org.apache.commons.jelly.parser.XMLParser.addTextScript(XMLParser.java:1069)
at org.apache.commons.jelly.parser.XMLParser.endElement(XMLParser.java:681)
at
org.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:579)
at
org.apache.xerces.impl.XMLNamespaceBinder.handleEndElement(XMLNamespaceBinder.java:897)
at
org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBinder.java:643)
at
org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:1972)
at
org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:878)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.handleEndElement(XMLDocumentFragmentScannerImpl.java:1144)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:987)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1445)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333)
at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524)
at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1169)
at org.apache.commons.jelly.parser.XMLParser.parse(XMLParser.java:296)
at org.apache.commons.jelly.Jelly.compileScript(Jelly.java:165)
at org.apache.commons.jelly.Jelly.main(Jelly.java:122)
at
[jira] Updated: (JELLY-55) support escapeText attribute in body tag from http taglib
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:19 PM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to taglib.http - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-55page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-55 Here is an overview of the issue: - Key: JELLY-55 Summary: support escapeText attribute in body tag from http taglib Type: Improvement Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.http Assignee: Reporter: Scott Walters Created: Thu, 29 May 2003 10:43 AM Updated: Thu, 4 Sep 2003 4:19 PM Description: - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JELLY-67) core RemoveTag
Message: The following issue has been reopened. Reopener: Morgan Delagrange Date: Thu, 4 Sep 2003 4:21 PM moving category - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-67 Here is an overview of the issue: - Key: JELLY-67 Summary: core RemoveTag Type: Improvement Status: Reopened Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: core / taglib.core Fix Fors: 1.0 Assignee: Reporter: Robert McIntosh Created: Fri, 1 Aug 2003 12:38 AM Updated: Thu, 4 Sep 2003 4:21 PM Description: Added the ability to supply and expression to the org.apache.commons.jelly.tags.core.RemoveTag 'var' attribute. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-67) core RemoveTag
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:21 PM Changes: Component changed to core / taglib.core Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-67page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-67 Here is an overview of the issue: - Key: JELLY-67 Summary: core RemoveTag Type: Improvement Status: Reopened Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: core / taglib.core Fix Fors: 1.0 Assignee: Reporter: Robert McIntosh Created: Fri, 1 Aug 2003 12:38 AM Updated: Thu, 4 Sep 2003 4:21 PM Description: Added the ability to supply and expression to the org.apache.commons.jelly.tags.core.RemoveTag 'var' attribute. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JELLY-18) XMLOutput with OutputFormat.setExpandEmptyElements(false) still expands empty elements
Message: The following issue has been reopened. Reopener: Morgan Delagrange Date: Thu, 4 Sep 2003 4:23 PM moving category - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-18 Here is an overview of the issue: - Key: JELLY-18 Summary: XMLOutput with OutputFormat.setExpandEmptyElements(false) still expands empty elements Type: Bug Status: Reopened Priority: Minor Time Spent: Unknown Remaining: 0 minutes Project: jelly Components: core / taglib.core Assignee: peter royal Reporter: Brian Leonard Created: Wed, 11 Dec 2002 5:32 PM Updated: Thu, 4 Sep 2003 4:23 PM Environment: Solaris/sparc with jdk 1.4.1 Description: // here we're creating an XMLOutput that doesn't // expand element/ to element/element OutputStream out = new FileOutputStream(outFile); OutputFormat format = OutputFormat.createPrettyPrint(); format.setExpandEmptyElements(false); XMLWriter xmlWriter = new XMLWriter(out, format); XMLOutput xmlOutput = new XMLOutput(xmlWriter); context.runScript(templateFile, xmlOutput); xmlOutput.flush(); out.close(); The above code expands empty elements when it shouldn't. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-34) [SWT JFace] start of JFace taglib
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-34 Here is an overview of the issue: - Key: JELLY-34 Summary: [SWT JFace] start of JFace taglib Type: New Feature Status: Closed Priority: Minor Resolution: FIXED Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.jface Assignee: james strachan Reporter: Christiaan ten Klooster Created: Thu, 20 Feb 2003 11:39 AM Updated: Thu, 4 Sep 2003 4:22 PM Description: This is a first attempt to start adding JFace support to SWT. This taglib extends the SWT taglib - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-18) XMLOutput with OutputFormat.setExpandEmptyElements(false) still expands empty elements
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:23 PM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to core / taglib.core - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-18page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-18 Here is an overview of the issue: - Key: JELLY-18 Summary: XMLOutput with OutputFormat.setExpandEmptyElements(false) still expands empty elements Type: Bug Status: Reopened Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: core / taglib.core Assignee: peter royal Reporter: Brian Leonard Created: Wed, 11 Dec 2002 5:32 PM Updated: Thu, 4 Sep 2003 4:23 PM Environment: Solaris/sparc with jdk 1.4.1 Description: // here we're creating an XMLOutput that doesn't // expand element/ to element/element OutputStream out = new FileOutputStream(outFile); OutputFormat format = OutputFormat.createPrettyPrint(); format.setExpandEmptyElements(false); XMLWriter xmlWriter = new XMLWriter(out, format); XMLOutput xmlOutput = new XMLOutput(xmlWriter); context.runScript(templateFile, xmlOutput); xmlOutput.flush(); out.close(); The above code expands empty elements when it shouldn't. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-18) XMLOutput with OutputFormat.setExpandEmptyElements(false) still expands empty elements
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-18 Here is an overview of the issue: - Key: JELLY-18 Summary: XMLOutput with OutputFormat.setExpandEmptyElements(false) still expands empty elements Type: Bug Status: Closed Priority: Minor Resolution: FIXED Time Spent: Unknown Remaining: Unknown Project: jelly Components: core / taglib.core Assignee: peter royal Reporter: Brian Leonard Created: Wed, 11 Dec 2002 5:32 PM Updated: Thu, 4 Sep 2003 4:23 PM Environment: Solaris/sparc with jdk 1.4.1 Description: // here we're creating an XMLOutput that doesn't // expand element/ to element/element OutputStream out = new FileOutputStream(outFile); OutputFormat format = OutputFormat.createPrettyPrint(); format.setExpandEmptyElements(false); XMLWriter xmlWriter = new XMLWriter(out, format); XMLOutput xmlOutput = new XMLOutput(xmlWriter); context.runScript(templateFile, xmlOutput); xmlOutput.flush(); out.close(); The above code expands empty elements when it shouldn't. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JELLY-70) fmt:message tag does not accept param subtag when key is specified as an attribute
Message: The following issue has been reopened. Reopener: Morgan Delagrange Date: Thu, 4 Sep 2003 4:25 PM moving category - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-70 Here is an overview of the issue: - Key: JELLY-70 Summary: fmt:message tag does not accept param subtag when key is specified as an attribute Type: Bug Status: Reopened Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.fmt Assignee: Reporter: Willie Vu Created: Thu, 14 Aug 2003 3:00 AM Updated: Thu, 4 Sep 2003 4:25 PM Description: The cause is that body is not processed when key is specified as an attribute. The reason that specifying the key as body works is that the body is processed in order to get the key. Doing so processes the param subtags. Resolution: call invokeBody() - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-70) fmt:message tag does not accept param subtag when key is specified as an attribute
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:26 PM Changes: Component changed to taglib.fmt Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-70page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-70 Here is an overview of the issue: - Key: JELLY-70 Summary: fmt:message tag does not accept param subtag when key is specified as an attribute Type: Bug Status: Reopened Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.fmt Assignee: Reporter: Willie Vu Created: Thu, 14 Aug 2003 3:00 AM Updated: Thu, 4 Sep 2003 4:26 PM Description: The cause is that body is not processed when key is specified as an attribute. The reason that specifying the key as body works is that the body is processed in order to get the key. Doing so processes the param subtags. Resolution: call invokeBody() - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-70) fmt:message tag does not accept param subtag when key is specified as an attribute
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-70 Here is an overview of the issue: - Key: JELLY-70 Summary: fmt:message tag does not accept param subtag when key is specified as an attribute Type: Bug Status: Closed Priority: Major Resolution: FIXED Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.fmt Assignee: Reporter: Willie Vu Created: Thu, 14 Aug 2003 3:00 AM Updated: Thu, 4 Sep 2003 4:26 PM Description: The cause is that body is not processed when key is specified as an attribute. The reason that specifying the key as body works is that the body is processed in order to get the key. Doing so processes the param subtags. Resolution: call invokeBody() - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-26) xml:file produces very bad output
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:26 PM Changes: Component changed to taglib.xml Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-26page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-26 Here is an overview of the issue: - Key: JELLY-26 Summary: xml:file produces very bad output Type: Bug Status: Resolved Priority: Critical Resolution: FIXED Time Spent: Unknown Remaining: 1 day Project: jelly Components: taglib.xml Assignee: peter royal Reporter: Paul Libbrecht Created: Tue, 28 Jan 2003 6:51 PM Updated: Thu, 4 Sep 2003 4:26 PM Environment: Running the XML tag-library using org.apache.commons.jelly.Jelly command with XML content of any kind. Outputting in XML or HTML format. Description: xml:file elements has the following two majors bugs: - namespace declarations, at least at the end of an element declaration, have an opening quote but no closing one ! - when choosing the prettyPrint = yes... the words get cut in the middle! The work-around for the first is currently to run: sed 's/xmlns\([^=]*\)=\([^]*\)/xmlns\1=\2/g' bad ok Is it a dom4j bug ?? Not sure ! PS: don't trust my time estimate... I have not gone inside dom4j to know it. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JELLY-29) SWT image tag
Message: The following issue has been reopened. Reopener: Morgan Delagrange Date: Thu, 4 Sep 2003 4:26 PM moving category - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-29 Here is an overview of the issue: - Key: JELLY-29 Summary: SWT image tag Type: New Feature Status: Reopened Priority: Minor Time Spent: Unknown Remaining: 0 minutes Project: jelly Components: taglib.swt Assignee: james strachan Reporter: Christiaan ten Klooster Created: Fri, 7 Feb 2003 7:25 AM Updated: Thu, 4 Sep 2003 4:26 PM Description: - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-29) SWT image tag
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:26 PM Changes: description changed to environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to taglib.swt Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-29page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-29 Here is an overview of the issue: - Key: JELLY-29 Summary: SWT image tag Type: New Feature Status: Reopened Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.swt Assignee: james strachan Reporter: Christiaan ten Klooster Created: Fri, 7 Feb 2003 7:25 AM Updated: Thu, 4 Sep 2003 4:26 PM Description: - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-29) SWT image tag
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-29 Here is an overview of the issue: - Key: JELLY-29 Summary: SWT image tag Type: New Feature Status: Closed Priority: Minor Resolution: FIXED Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.swt Assignee: james strachan Reporter: Christiaan ten Klooster Created: Fri, 7 Feb 2003 7:25 AM Updated: Thu, 4 Sep 2003 4:27 PM Description: - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JELLY-32) [SWt taglib] set colors of widgets
Message: The following issue has been reopened. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-32 Here is an overview of the issue: - Key: JELLY-32 Summary: [SWt taglib] set colors of widgets Type: New Feature Status: Reopened Priority: Minor Time Spent: Unknown Remaining: 0 minutes Project: jelly Components: taglib.swt Assignee: james strachan Reporter: Christiaan ten Klooster Created: Wed, 19 Feb 2003 8:08 AM Updated: Thu, 4 Sep 2003 4:27 PM Description: set background and foreground colors of swt widgets - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-32) [SWt taglib] set colors of widgets
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:27 PM Changes: environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to taglib.swt Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-32page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-32 Here is an overview of the issue: - Key: JELLY-32 Summary: [SWt taglib] set colors of widgets Type: New Feature Status: Reopened Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.swt Assignee: james strachan Reporter: Christiaan ten Klooster Created: Wed, 19 Feb 2003 8:08 AM Updated: Thu, 4 Sep 2003 4:27 PM Description: set background and foreground colors of swt widgets - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-20) Create new taglib that mimics JSTL fmt for i18n Formatting
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:28 PM Changes: description changed to environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to taglib.fmt Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-20page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-20 Here is an overview of the issue: - Key: JELLY-20 Summary: Create new taglib that mimics JSTL fmt for i18n Formatting Type: New Feature Status: Reopened Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.fmt Assignee: james strachan Reporter: Willie Vu Created: Wed, 15 Jan 2003 11:00 AM Updated: Thu, 4 Sep 2003 4:28 PM Description: - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JELLY-20) Create new taglib that mimics JSTL fmt for i18n Formatting
Message: The following issue has been reopened. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-20 Here is an overview of the issue: - Key: JELLY-20 Summary: Create new taglib that mimics JSTL fmt for i18n Formatting Type: New Feature Status: Reopened Priority: Major Time Spent: Unknown Remaining: 0 minutes Project: jelly Components: taglib.fmt Assignee: james strachan Reporter: Willie Vu Created: Wed, 15 Jan 2003 11:00 AM Updated: Thu, 4 Sep 2003 4:28 PM Description: - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-63) email tag attributes do not accept Expression.
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:31 PM Changes: Component changed to taglib.email Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-63page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-63 Here is an overview of the issue: - Key: JELLY-63 Summary: email tag attributes do not accept Expression. Type: Bug Status: Reopened Priority: Major Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.email Assignee: Reporter: Willie Vu Created: Tue, 22 Jul 2003 9:10 PM Updated: Thu, 4 Sep 2003 4:31 PM Description: All attributes should accept expression. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-63) email tag attributes do not accept Expression.
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-63 Here is an overview of the issue: - Key: JELLY-63 Summary: email tag attributes do not accept Expression. Type: Bug Status: Closed Priority: Major Resolution: FIXED Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.email Assignee: Reporter: Willie Vu Created: Tue, 22 Jul 2003 9:10 PM Updated: Thu, 4 Sep 2003 4:31 PM Description: All attributes should accept expression. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-79) HttpTagSupport defaults setFollowRedirects to true
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-79 Here is an overview of the issue: - Key: JELLY-79 Summary: HttpTagSupport defaults setFollowRedirects to true Type: Bug Status: Closed Priority: Major Resolution: FIXED Time Spent: Unknown Remaining: 1 minute Project: jelly Components: taglib.http Assignee: Reporter: Sean Ferguson Created: Tue, 26 Aug 2003 6:38 PM Updated: Thu, 4 Sep 2003 4:32 PM Environment: JVM 1.4.2 Windows XP Description: In the lastest version of commons-httpclient calling setFollowRedirects on the HttpMethod class throws an exception if the parameter is true. By default, the HttpTagSupport class has _followRedirects default to true. It should default to false. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-30) SWT size attribute
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:32 PM Changes: environment changed to Component changed to taglib.swt Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-30page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-30 Here is an overview of the issue: - Key: JELLY-30 Summary: SWT size attribute Type: New Feature Status: Reopened Priority: Minor Time Spent: Unknown Remaining: 5 minutes Project: jelly Components: taglib.swt Assignee: james strachan Reporter: Christiaan ten Klooster Created: Tue, 11 Feb 2003 7:45 AM Updated: Thu, 4 Sep 2003 4:32 PM Description: patch for widget size attribute - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-33) [SWT libtag] Imagetag add image for decorations
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-33 Here is an overview of the issue: - Key: JELLY-33 Summary: [SWT libtag] Imagetag add image for decorations Type: New Feature Status: Closed Priority: Minor Resolution: FIXED Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.swt Assignee: james strachan Reporter: Christiaan ten Klooster Created: Wed, 19 Feb 2003 12:54 PM Updated: Thu, 4 Sep 2003 4:33 PM Description: - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JELLY-30) SWT size attribute
Message: The following issue has been reopened. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-30 Here is an overview of the issue: - Key: JELLY-30 Summary: SWT size attribute Type: New Feature Status: Reopened Priority: Minor Time Spent: Unknown Remaining: 5 minutes Project: jelly Components: taglib.swt Assignee: james strachan Reporter: Christiaan ten Klooster Created: Tue, 11 Feb 2003 7:45 AM Updated: Thu, 4 Sep 2003 4:32 PM Description: patch for widget size attribute - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-36) [JFace taglib] JFace preferences support
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-36 Here is an overview of the issue: - Key: JELLY-36 Summary: [JFace taglib] JFace preferences support Type: New Feature Status: Closed Priority: Minor Resolution: FIXED Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.jface Assignee: james strachan Reporter: Christiaan ten Klooster Created: Tue, 25 Feb 2003 12:09 PM Updated: Thu, 4 Sep 2003 4:33 PM Description: Basically provides a gui for a java.util.Properties object, see http://www.eclipse.org/documentation/html/plugins/org.eclipse.platform.doc.isv/doc/reference/api/index.html and http://www.eclipse.org/articles/Article-Field-Editors/field_editors.html - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-36) [JFace taglib] JFace preferences support
The following issue has been updated: Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED]) Date: Thu, 4 Sep 2003 4:33 PM Changes: description changed from Basically provides a gui for a java.util.Properties object, see http://www.eclipse.org/documentation/html/plugins/org.eclipse.platform.doc.isv/doc/reference/api/index.html and http://www.eclipse.org/articles/Article-Field-Editors/field_editors.html environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Component changed to taglib.jface Component changed from tags - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-36page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-36 Here is an overview of the issue: - Key: JELLY-36 Summary: [JFace taglib] JFace preferences support Type: New Feature Status: Reopened Priority: Minor Time Spent: Unknown Remaining: Unknown Project: jelly Components: taglib.jface Assignee: james strachan Reporter: Christiaan ten Klooster Created: Tue, 25 Feb 2003 12:09 PM Updated: Thu, 4 Sep 2003 4:33 PM Description: Basically provides a gui for a java.util.Properties object, see http://www.eclipse.org/documentation/html/plugins/org.eclipse.platform.doc.isv/doc/reference/api/index.html and http://www.eclipse.org/articles/Article-Field-Editors/field_editors.html - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JELLY-3) Can no longer run two define:tag scripts consecutively
Message:
The following issue has been reopened.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-3
Here is an overview of the issue:
-
Key: JELLY-3
Summary: Can no longer run two define:tag scripts consecutively
Type: Bug
Status: Reopened
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
taglib.define
Assignee: james strachan
Reporter: Jason van Zyl
Created: Tue, 13 Aug 2002 12:59 PM
Updated: Thu, 4 Sep 2003 4:34 PM
Description:
I have a maven.xml file that has the following:
goal name=forehead prereqs=init-texen-tag
texen:generate
controlTemplate=forehead.vm
outputDirectory=${run}
templatePath=${basedir}/templates
outputFile=forehead.conf
mavenProject=${pom}
/
/goal
goal name=script prereqs=init-texen-tag
texen:generate
controlTemplate=plexus.vm
outputDirectory=${run}
templatePath=${basedir}/templates
outputFile=plexus.sh
mavenProject=${pom}
/
chmod file=${run}/plexus.sh perm=+x/
/goal
I used to be able to run these goals consecutively but now only the first one will run
the second comes out like this:
texen:texen controlTemplate=plexus.vm mavenProject=plexus
templatePath=/home/jvanzyl/js/plexus/templates outputFile=plexus.sh
outputDirectory=/home/jvanzyl/js/plexus/run/texen:texen
Basically just spitting out the XML.
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-3) Can no longer run two define:tag scripts consecutively
The following issue has been updated:
Updater: Morgan Delagrange (mailto:[EMAIL PROTECTED])
Date: Thu, 4 Sep 2003 4:34 PM
Changes:
description changed from I have a maven.xml file that has the following:
goal name=forehead prereqs=init-texen-tag
texen:generate
controlTemplate=forehead.vm
outputDirectory=${run}
templatePath=${basedir}/templates
outputFile=forehead.conf
mavenProject=${pom}
/
/goal
goal name=script prereqs=init-texen-tag
texen:generate
controlTemplate=plexus.vm
outputDirectory=${run}
templatePath=${basedir}/templates
outputFile=plexus.sh
mavenProject=${pom}
/
chmod file=${run}/plexus.sh perm=+x/
/goal
I used to be able to run these goals consecutively but now only the first one will run
the second comes out like this:
texen:texen controlTemplate=plexus.vm mavenProject=plexus
templatePath=/home/jvanzyl/js/plexus/templates outputFile=plexus.sh
outputDirectory=/home/jvanzyl/js/plexus/run/texen:texen
Basically just spitting out the XML.
environment changed to
Component changed to taglib.define
Component changed from tags
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-3page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-3
Here is an overview of the issue:
-
Key: JELLY-3
Summary: Can no longer run two define:tag scripts consecutively
Type: Bug
Status: Reopened
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
taglib.define
Assignee: james strachan
Reporter: Jason van Zyl
Created: Tue, 13 Aug 2002 12:59 PM
Updated: Thu, 4 Sep 2003 4:34 PM
Description:
I have a maven.xml file that has the following:
goal name=forehead prereqs=init-texen-tag
texen:generate
controlTemplate=forehead.vm
outputDirectory=${run}
templatePath=${basedir}/templates
outputFile=forehead.conf
mavenProject=${pom}
/
/goal
goal name=script prereqs=init-texen-tag
texen:generate
controlTemplate=plexus.vm
outputDirectory=${run}
templatePath=${basedir}/templates
outputFile=plexus.sh
mavenProject=${pom}
/
chmod file=${run}/plexus.sh perm=+x/
/goal
I used to be able to run these goals consecutively but now only the first one will run
the second comes out like this:
texen:texen controlTemplate=plexus.vm mavenProject=plexus
templatePath=/home/jvanzyl/js/plexus/templates outputFile=plexus.sh
outputDirectory=/home/jvanzyl/js/plexus/run/texen:texen
Basically just spitting out the XML.
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-3) Can no longer run two define:tag scripts consecutively
Message:
The following issue has been closed.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-3
Here is an overview of the issue:
-
Key: JELLY-3
Summary: Can no longer run two define:tag scripts consecutively
Type: Bug
Status: Closed
Priority: Major
Resolution: FIXED
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
taglib.define
Assignee: james strachan
Reporter: Jason van Zyl
Created: Tue, 13 Aug 2002 12:59 PM
Updated: Thu, 4 Sep 2003 4:34 PM
Description:
I have a maven.xml file that has the following:
goal name=forehead prereqs=init-texen-tag
texen:generate
controlTemplate=forehead.vm
outputDirectory=${run}
templatePath=${basedir}/templates
outputFile=forehead.conf
mavenProject=${pom}
/
/goal
goal name=script prereqs=init-texen-tag
texen:generate
controlTemplate=plexus.vm
outputDirectory=${run}
templatePath=${basedir}/templates
outputFile=plexus.sh
mavenProject=${pom}
/
chmod file=${run}/plexus.sh perm=+x/
/goal
I used to be able to run these goals consecutively but now only the first one will run
the second comes out like this:
texen:texen controlTemplate=plexus.vm mavenProject=plexus
templatePath=/home/jvanzyl/js/plexus/templates outputFile=plexus.sh
outputDirectory=/home/jvanzyl/js/plexus/run/texen:texen
Basically just spitting out the XML.
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/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]
