[jira] Commented: (EMAIL-56) [Email] Parsing MIME content.
[ https://issues.apache.org/jira/browse/EMAIL-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475245 ] dion gillard commented on EMAIL-56: --- I'm with Ben on this one. I think javamail is the appropriate tool for this sort of activity and it falls outside of what we're trying to do (keep it as simple as it needs to be) with commons email. I'm happy to hear alternative views on it, though... > [Email] Parsing MIME content. > - > > Key: EMAIL-56 > URL: https://issues.apache.org/jira/browse/EMAIL-56 > Project: Commons Email > Issue Type: Improvement > Environment: Operating System: Windows XP > Platform: Other >Reporter: Jose M. Ordax >Priority: Minor > Fix For: 1.1 > > > This is not a bug, it is a Feature Request. > It should be nice if the framework implements a way to create a > MultiPartMessage > from an InputStream or a String with all the content of a real message got > from > a POP3 or NNTP server. > Currently it seems you have to create it manually adding headers and parts via > methods. And I think in this way is not really useful. > Thanks, >Chemi. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (EMAIL-1) [email] setCharset() in Email does not set the charset for the message content
[ https://issues.apache.org/jira/browse/EMAIL-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dion gillard resolved EMAIL-1. -- Resolution: Fixed Applied. > [email] setCharset() in Email does not set the charset for the message content > -- > > Key: EMAIL-1 > URL: https://issues.apache.org/jira/browse/EMAIL-1 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.0 > Environment: Operating System: other > Platform: Other >Reporter: James Mc Millan > Fix For: 1.1 > > Attachments: email-1.patch > > > Hello > More accurately, the charset is not used in buildMimeMessage() as it is not > part > of the contentType used when calling message.setContent(). Since > setContentType() updates the charset, I think it makes for setCharset() to > update the contentType? > James -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (EMAIL-25) [email] Address char-set can not be individually set
[ https://issues.apache.org/jira/browse/EMAIL-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dion gillard resolved EMAIL-25. --- Resolution: Fixed Fixed by EMAIL-54 > [email] Address char-set can not be individually set > > > Key: EMAIL-25 > URL: https://issues.apache.org/jira/browse/EMAIL-25 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.0 > Environment: Operating System: other > Platform: Other >Reporter: James Huang >Priority: Critical > Fix For: 1.1 > > > The commons-email-1.0 release API has a critical flaw: you can't specify char- > set for individual addresses. This is the case with some Japanese mail > systems. > Currently, org.apache.commons.mail.Email class only has methods like >add(String email, String name); > but no such methods: >addXXX(String email, String name, String charset); > In addition, I believe the API should allow >addXXX(javax.mail.internt.InternetAddress); > If you want to hide InternetAddress, I don't mind to even have a > addXXX(Object). > Thanks, > -James Huang -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (EMAIL-14) [email] not support content charset gb2312
[
https://issues.apache.org/jira/browse/EMAIL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dion gillard resolved EMAIL-14.
---
Resolution: Fixed
Fixed by EMAIL-54 patch
> [email] not support content charset gb2312
> ---
>
> Key: EMAIL-14
> URL: https://issues.apache.org/jira/browse/EMAIL-14
> Project: Commons Email
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Operating System: other
> Platform: Other
>Reporter: locka
> Fix For: 1.1
>
> Attachments: commons-email-utf8.patch.txt, patch.java
>
>
> when i try the example :
> Email email=new SimpleEmail();
> email.setHostName("129.1.1.129");
> email.setAuthentication("admin","1");
> email.addTo("[EMAIL PROTECTED]", "wjq");
> email.setFrom("[EMAIL PROTECTED]", "Me");
> email.setCharset("gb2312");
> email.setSubject("²âÊÔ¼òµ¥Óʼþ");
> email.setMsg("ÕâÊDzâÊÔ¼òµ¥Óʼþ");
> email.send();
> the received mail content like "" ,when change Email.TEXT_PLAIN
> = "text/plain" to TEXT_PLAIN = "text/plain;charset=gb2312" , all are right
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (EMAIL-54) [email] Add new class Charset
[ https://issues.apache.org/jira/browse/EMAIL-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dion gillard resolved EMAIL-54. --- Resolution: Fixed Applied the charset-support patch. Looks fine. > [email] Add new class Charset > - > > Key: EMAIL-54 > URL: https://issues.apache.org/jira/browse/EMAIL-54 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 1.0 > Environment: Operating System: other > Platform: Other >Reporter: Piero Ottuzzi >Priority: Minor > Fix For: 1.1 > > Attachments: charset-support.patch, Charset.java, Email.java.patch > > > Add new class Charset the let the whole thing extensible and less error prone -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (EMAIL-28) [email] Problems with HTML emails with attachments and embedded images
[
https://issues.apache.org/jira/browse/EMAIL-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dion gillard resolved EMAIL-28.
---
Resolution: Fixed
Fixed in EMAIL-50. Go Ben!
> [email] Problems with HTML emails with attachments and embedded images
> --
>
> Key: EMAIL-28
> URL: https://issues.apache.org/jira/browse/EMAIL-28
> Project: Commons Email
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Operating System: Windows XP
> Platform: PC
>Reporter: Phil Bretherton
> Fix For: 1.1
>
>
> I have three problems that are probably related. The results are using Mozilla
> Thunderbird.
> 1. When I send an HtmlEmail with attachments, embedded images, an HTML body
> and
> an alternative text body both the alternative text and the HTML are displayed.
> 2. When I send an HtmlEmail with embedded images, no attachments, an HTML body
> and I do not provide an alternative text body, the HTML body is not displayed.
> 3. When I send an HtmlEmail with attachments, embedded images, an HTML body
> and
> I do not provide an alternative text, everything works almost fine. The only
> problem is that when the SMTP server is sending emails outside its domain it
> adds a disclaimer. The addition of this disclaimer means that only the
> disclaimer is displayed. This does not happend when using Javamail.
> Below is the class that I used for my tests.
> import java.net.MalformedURLException;
> import java.net.URL;
> import org.apache.commons.mail.EmailAttachment;
> import org.apache.commons.mail.EmailException;
> import org.apache.commons.mail.HtmlEmail;
> public class CommonsEmailTest {
> /**
>* @param args
>*/
> public static void main(String[] args) {
> try {
> testHtmlEmailWithAttachmentsAndEmbeddedImages();
> testHtmlEmailWithoutAttachmentsOrText();
> testHtmlEmailWithAttachmentsAndEmbeddedImagesNoText();
> } catch (MalformedURLException e) {
> e.printStackTrace();
> } catch (EmailException e) {
> e.printStackTrace();
> }
> }
>
> /**
>* This method sends an HTML email with attachments, embedded images,
>* an HTML body and an alternative text body. The result is that both
>* the HTML and the text are displayed.
>*
>* @throws EmailException
>* @throws MalformedURLException
>*/
> public static void testHtmlEmailWithAttachmentsAndEmbeddedImages()
> throws
> EmailException, MalformedURLException {
>
> // Create the email message
> HtmlEmail email = new HtmlEmail();
> email.setHostName("smtp.capgemini.fr");
> email.addTo("[EMAIL PROTECTED]", "You");
> email.setFrom("[EMAIL PROTECTED]", "Me");
> email.setSubject("Test email with inline image and attachment");
>
> // Create the attachment
> EmailAttachment attachment = new EmailAttachment();
> attachment.setPath("D:/temp/mypic.jpg");
> attachment.setDisposition(EmailAttachment.ATTACHMENT);
> attachment.setDescription("A picture");
> attachment.setName("Thingy");
>
> email.attach(attachment);
> // embed the image and get the content id
> URL url = new
> URL("http://www.apache.org/images/asf_logo_wide.gif";);
> String cid = email.embed(url, "Apache logo");
> // set the html message
> email.setHtmlMsg("The apache logo - src=\"cid:"+cid+"\">");
> // set the alternative message
> email.setTextMsg("Your email client does not support HTML
> messages");
> // send the email
> email.send();
> }
> /**
>* This method sends an HTML email with embedded images,
>* an HTML body and no alternative text body. The result is that both
>* the HTML is not displayed.
>*
>* @throws EmailException
>* @throws MalformedURLException
>*/
> public static void testHtmlEmailWithoutAttachmentsOrText() throws
> EmailException, MalformedURLException {
>
> // Create the email message
> HtmlEmail email = new HtmlEmail();
> email.setHostName("smtp.capgemini.fr");
> email.addTo("[EMAIL PROTECTED]", "You");
> email.setFrom("[EMAIL PROTECTED]", "Me");
> email.setSubject("Test email with inline image and no
> alternative text");
>
> // embed the image and get the conten
[jira] Resolved: (EMAIL-52) [email] Identical Inline images should share same BodyPart
[ https://issues.apache.org/jira/browse/EMAIL-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dion gillard resolved EMAIL-52. --- Resolution: Fixed Fixed in EMAIL-50 > [email] Identical Inline images should share same BodyPart > -- > > Key: EMAIL-52 > URL: https://issues.apache.org/jira/browse/EMAIL-52 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 1.0 > Environment: Operating System: other > Platform: Other >Reporter: Andrew Liles >Priority: Minor > Fix For: 1.1 > > > If you have an HTML email with "spacer.gif" repeated several times, then you > get > that image included several times in the payload of the email. An > optimization > would be to "share" the sid across the several references. > I have adapted HTMLEmail for my own purposes, and one of the "fixes" I have > added is just such an optimization. > Please could a Committer register their interest in this, and I will make a > patch and submit for your consideration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (EMAIL-50) [email] HTML Emails with images don't display in Outlook 2000
[ https://issues.apache.org/jira/browse/EMAIL-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dion gillard resolved EMAIL-50. --- Resolution: Fixed Ben's patch works well. Applied. > [email] HTML Emails with images don't display in Outlook 2000 > - > > Key: EMAIL-50 > URL: https://issues.apache.org/jira/browse/EMAIL-50 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 1.0 > Environment: Operating System: other > Platform: Other >Reporter: Andrew Liles >Priority: Minor > Fix For: 1.1 > > Attachments: html-embed-images.patch, HtmlEmail.java.patch, > HtmlEmail2.java > > > I was having a problem sending HTML Emails with inline image attachments > against > the client Microsoft Outlook 2000 SP-3. I am using commons-email-1.0.jar. > This bug report proposes a solution include code. > Suppose with an HtmlEmail I am embedding 2 images, adding an HTML part and > Text > part. > The resultant Body structure is: > EntityContent-TypeEncoding > 1 text/plain 7bit > 2 multipart/related > 2.1 text/html 7bit > 2.2 image/jpeg base64 > 2.3 image/jpeg base64 > Outlook, by default, shows the text part with the HTML email as an attachment > (correctly showing the images). My "problem" is that I think the HTML should > be > shown by default. > I am guessing that it is an issue with this particular email client and the > Body > Structure format ? (see here, for example: COM-1526) > --- > I have fixed this for my own purposes and am recording the details here for > the > benefit of others. I don't know whether this should be categorised as a bug > in > commons-email-1.0.jar or a bug in Outlook. I suspect the latter, but since > back > versions of Outlook will never get fixed, the pragmatic solution is to alter > commons-email, particularly in cases if you are targeting a known finite set > of > email clients. > I am fully expecting a committer to categorize this as WONTFIX, but at least > the > attachment I will add may allow others to use my code. > My code has been tested to work on: > Microsoft Outlook Express 6.00 > Microsoft Outlook 2000 SP-3 > Microsoft Outlook 2002 > Microsoft Outlook 2003 > Qualcomm Eudora 6.0.3.0 > SquirrelMail 1.5.1 (webmail client) > Hotmail (as of November 2005) > Gmail (as of November 2005) > These clients are all happy to receive and display HTML emails in the expected > way using this Body Structure: > EntityContent-TypeEncoding > 1 multipart/alternative > 1.1 text/plain 7bit > 1.2 text/html 7bit > 2 image/jpeg base64 > 3 image/jpeg base64 > I have not tested with attachments that do not relate to the HTML and may not > support this scenario; however this is not normal usage scenario (well, for me > anyway). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (EMAIL-62) [email] Build patches to enforce source 1.4 and target 1.4 when compiling
[ https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dion gillard resolved EMAIL-62. --- Resolution: Fixed Patches applied - thanks guys! > [email] Build patches to enforce source 1.4 and target 1.4 when compiling > - > > Key: EMAIL-62 > URL: https://issues.apache.org/jira/browse/EMAIL-62 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Ben Speakmon > Fix For: 1.1 > > Attachments: build.xml.patch, project.properties, > project.properties.patch > > > Maven and Ant patches. Ant patch suppresses spurious 1.5 type safety warnings > when building commons-email on JDK >= 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-62) [email] Build patches to enforce source 1.4 and target 1.4 when compiling
[ https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472986 ] dion gillard commented on EMAIL-62: --- Does anyone know why we're patching a Maven-generated build.xml file instead of just regenerating it? Doesn't the maven ant plugin generate a build file with the correct javac task attributes? > [email] Build patches to enforce source 1.4 and target 1.4 when compiling > - > > Key: EMAIL-62 > URL: https://issues.apache.org/jira/browse/EMAIL-62 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Ben Speakmon > Fix For: 1.1 > > Attachments: build.xml.patch, project.properties, > project.properties.patch > > > Maven and Ant patches. Ant patch suppresses spurious 1.5 type safety warnings > when building commons-email on JDK >= 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-64) Use wiser instead of dumbster for test cases
[ https://issues.apache.org/jira/browse/EMAIL-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472978 ] dion gillard commented on EMAIL-64: --- I'm with Ben. > Use wiser instead of dumbster for test cases > > > Key: EMAIL-64 > URL: https://issues.apache.org/jira/browse/EMAIL-64 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Ben Speakmon > Fix For: 1.1 > > > Since the test cases depend on a snapshot of the dead project dumbster, the > tests should be changed to use the wiser test email server instead. Marking > as 1.1 fix since this should get done before 1.1 goes out the door. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-64) Use wiser instead of dumbster for test cases
[ https://issues.apache.org/jira/browse/EMAIL-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472492 ] dion gillard commented on EMAIL-64: --- I'm happy to move to wiser, just wanted to make sure we're not going from dead project to dead project. > Use wiser instead of dumbster for test cases > > > Key: EMAIL-64 > URL: https://issues.apache.org/jira/browse/EMAIL-64 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Ben Speakmon > Fix For: 1.1 > > > Since the test cases depend on a snapshot of the dead project dumbster, the > tests should be changed to use the wiser test email server instead. Marking > as 1.1 fix since this should get done before 1.1 goes out the door. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-64) Use wiser instead of dumbster for test cases
[ https://issues.apache.org/jira/browse/EMAIL-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472429 ] dion gillard commented on EMAIL-64: --- How 'live' is wiser? > Use wiser instead of dumbster for test cases > > > Key: EMAIL-64 > URL: https://issues.apache.org/jira/browse/EMAIL-64 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Ben Speakmon > Fix For: 1.1 > > > Since the test cases depend on a snapshot of the dead project dumbster, the > tests should be changed to use the wiser test email server instead. Marking > as 1.1 fix since this should get done before 1.1 goes out the door. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-62) [email] Build patches to enforce source 1.4 and target 1.4 when compiling
[ https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472428 ] dion gillard commented on EMAIL-62: --- So this means that commons-email is now JDK 1.4+. Has anyone surveyed the users and seen if we still have any on 1.3 that can't stay on email 1.0? > [email] Build patches to enforce source 1.4 and target 1.4 when compiling > - > > Key: EMAIL-62 > URL: https://issues.apache.org/jira/browse/EMAIL-62 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Ben Speakmon > Fix For: 1.1 > > Attachments: build.xml.patch, project.properties, > project.properties.patch > > > Maven and Ant patches. Ant patch suppresses spurious 1.5 type safety warnings > when building commons-email on JDK >= 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (EMAIL-22) [email] New embed method for HtmlEmail
[
https://issues.apache.org/jira/browse/EMAIL-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dion gillard closed EMAIL-22.
-
Resolution: Duplicate
Email-35 looks like a better patch as well.
> [email] New embed method for HtmlEmail
> --
>
> Key: EMAIL-22
> URL: https://issues.apache.org/jira/browse/EMAIL-22
> Project: Commons Email
> Issue Type: Bug
> Environment: Operating System: other
> Platform: Other
>Reporter: zarkon
>
> Hi!
> I've written a new "embed" method (simply but neccesary) for the HtmlEmail
> class:
> public String embed(DataSource ds, String name) throws EmailException{
>
> // verify that the DataSource is valid
> try
> {
> if (ds == null || ds.getInputStream() == null)
> {
> throw new EmailException("Invalid Datasource");
> }
> }
> catch (IOException e)
> {
> throw new EmailException("Invalid Datasource");
> }
> MimeBodyPart mbp = new MimeBodyPart();
> try
> {
> mbp.setDataHandler(new DataHandler(ds));
> mbp.setFileName(name);
> mbp.setDisposition("inline");
> String cid = randomAlphabetic(HtmlEmail.CID_LENGTH).toLowerCase();
> mbp.addHeader("Content-ID", "<" + cid + ">");
> this.inlineImages.add(mbp);
> return cid;
> }
> catch (MessagingException me)
> {
> throw new EmailException(me);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (EMAIL-59) SSL Support
[ https://issues.apache.org/jira/browse/EMAIL-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dion gillard resolved EMAIL-59. --- Resolution: Fixed applied clean patch > SSL Support > --- > > Key: EMAIL-59 > URL: https://issues.apache.org/jira/browse/EMAIL-59 > Project: Commons Email > Issue Type: New Feature >Reporter: Mitch McCuiston > Attachments: enable-ssl-cleaned.patch, enable-ssl.patch > > > Adding convenience methods for enabling SSL in Email.java abstract class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JEXL-31) Make it possible to run the jar target without running the test target
[ http://issues.apache.org/jira/browse/JEXL-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461716 ] dion gillard commented on JEXL-31: -- It is possible to build the jar without running the tests by using maven.test.skip=true, see http://maven.apache.org/maven-1.x/plugins/test/properties.html > Make it possible to run the jar target without running the test target > -- > > Key: JEXL-31 > URL: http://issues.apache.org/jira/browse/JEXL-31 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 2.0, 1.1.1, 1.1, 1.0, 1.0 Beta 1 > Environment: Gentoo Linux >Reporter: Petteri Räty >Priority: Minor > Attachments: test-target.patch > > > Now it is not possible to run the jar target without running the tests. For > Gentoo ebuilds it must be possible to just create the jar and optionally run > the tests if the user wants to run them so I created a patch to only run the > test target under the dist target instead of the jar target. This is also the > way this is most commonly done in java projects. Attached patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-273) Reference to "%JAVA_HOME%"\bin\java in jelly.bat should be "%JAVA_HOME%\bin\java"
[ http://issues.apache.org/jira/browse/JELLY-273?page=comments#action_12461455 ] dion gillard commented on JELLY-273: Yep, the quoting of JAVA_HOME is definitely wrong > Reference to "%JAVA_HOME%"\bin\java in jelly.bat should be > "%JAVA_HOME%\bin\java" > - > > Key: JELLY-273 > URL: http://issues.apache.org/jira/browse/JELLY-273 > Project: Commons Jelly > Issue Type: Bug > Components: core / taglib.core > Environment: Windows XP >Reporter: David M. Karr >Priority: Minor > > On Windows XP, when the released "jelly.bat" is executed, it complains very > obtusely: > Exception in thread "main" java.lang.NoClassDefFoundError: \bin\java > With some experimentation, I realized that all that is required is to change: > "%JAVA_HOME%"\bin\java -classpath > "%CLASSPATH%;%JELLY_HOME%\lib\forehead-1.0-beta-5.jar" > "-Dforehead.conf.file=%FOREHEAD_CONF%" "-Djelly.home=%JELLY_HOME%" > "-Dtools.jar=%JAVA_HOME%\lib\tools.jar" %JELLY_OPTS% > com.werken.forehead.Forehead %* > to: > "%JAVA_HOME%\bin\java" -classpath > "%CLASSPATH%;%JELLY_HOME%\lib\forehead-1.0-beta-5.jar" > "-Dforehead.conf.file=%FOREHEAD_CONF%" "-Djelly.home=%JELLY_HOME%" > "-Dtools.jar=%JAVA_HOME%\lib\tools.jar" %JELLY_OPTS% > com.werken.forehead.Forehead %* > The only change is moving the double-quote from before "/bin/java" to after > it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-31) [beanutils] The version in the manifest for version 1.7 is wrong it says 1.6
[ http://issues.apache.org/jira/browse/BEANUTILS-31?page=comments#action_12452127 ] dion gillard commented on BEANUTILS-31: --- Can't we at least fix the jar and re-deploy it? > [beanutils] The version in the manifest for version 1.7 is wrong it says 1.6 > > > Key: BEANUTILS-31 > URL: http://issues.apache.org/jira/browse/BEANUTILS-31 > Project: Commons BeanUtils > Issue Type: Bug >Affects Versions: 1.6 > Environment: Operating System: other > Platform: Other >Reporter: Rohan Lenard >Priority: Minor > > Manifest-Version: 1.0 > Ant-Version: Apache Ant 1.5.3 > Created-By: 1.4.1_01-b01 (Sun Microsystems Inc.) > Extension-Name: org.apache.commons.beanutils > Specification-Title: Jakarta Commons Beanutils > Specification-Vendor: Apache Software Foundation > Specification-Version: 1.6 > Implementation-Title: org.apache.commons.beanutils > Implementation-Vendor: Apache Software Foundation > Implementation-Version: 1.6 > I'd have thought the Implementation-Version should be 1.7 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BEANUTILS-264) Manifest.MF distributed via maven repositories has 1.6 as the implementation version and specification version
Manifest.MF distributed via maven repositories has 1.6 as the implementation version and specification version -- Key: BEANUTILS-264 URL: http://issues.apache.org/jira/browse/BEANUTILS-264 Project: Commons BeanUtils Issue Type: Bug Affects Versions: 1.7.0 Reporter: dion gillard See http://people.apache.org/repo/m1-ibiblio-rsync-repository/commons-beanutils/jars/commons-beanutils-1.7.0.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JEXL-30) ASTAddNode does not add BigDecimal objects correctly
[
http://issues.apache.org/jira/browse/JEXL-30?page=comments#action_12451144 ]
dion gillard commented on JEXL-30:
--
I agree the current case is wrong, but I'd much rather see a special case where
if left/right is a BigDecimal then the other side is coerced into a BigDecimal
and BigDecimal.add called.
WDYT?
> ASTAddNode does not add BigDecimal objects correctly
>
>
> Key: JEXL-30
> URL: http://issues.apache.org/jira/browse/JEXL-30
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: All
>Reporter: Curtis Stanford
>
> The ASTAddNode only checks for Float or Double objects when adding floating
> point numbers. If the objects are not Float or Double, they are added as
> Long's. As a result, adding BigDecimal objects loses any existing decimal
> points.
> Untested patch:
> Index: ASTAddNode.java
> ===
> --- ASTAddNode.java (revision 476204)
> +++ ASTAddNode.java (working copy)
> @@ -16,6 +16,8 @@
>
> package org.apache.commons.jexl.parser;
>
> +import java.math.BigDecimal;
> +
> import org.apache.commons.jexl.JexlContext;
> import org.apache.commons.jexl.util.Coercion;
>
> @@ -71,8 +73,8 @@
> * if anything is float, double or string with ( "." | "E" | "e")
> * coerce all to doubles and do it
> */
> -if (left instanceof Float || left instanceof Double
> -|| right instanceof Float || right instanceof Double
> +if (left instanceof Float || left instanceof Double || left
> instanceof BigDecimal
> +|| right instanceof Float || right instanceof Double || right
> instanceof BigDecimal
> || (left instanceof String
>&& (((String) left).indexOf(".") != -1
>|| ((String) left).indexOf("e") != -1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JEXL-25) Call method with varargs
[ http://issues.apache.org/jira/browse/JEXL-25?page=all ]
dion gillard updated JEXL-25:
-
Issue Type: New Feature (was: Bug)
> Call method with varargs
>
>
> Key: JEXL-25
> URL: http://issues.apache.org/jira/browse/JEXL-25
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 1.1
> Environment: All
>Reporter: Marek Lewczuk
>Priority: Critical
>
> Jexl doesn't allow for using method with varargs - method cannot be found and
> because of that expression returns null. Try following code:
> class TestClass {
> public String testVarArgs (Integer... args) {
> return "Test";
> }
> }
> String jexlExp = "test.testVarArgs(1,2,3,4,5)";
> Expression e = ExpressionFactory.createExpression(jexlExp);
> JexlContext jc = JexlHelper.createContext();
> jc.getVars().put("test", new TestClass());
> Object o = e.evaluate(jc);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JEXL-22) Allow unicode literals to be used
[ http://issues.apache.org/jira/browse/JEXL-22?page=all ] dion gillard resolved JEXL-22. -- Resolution: Fixed Code regenerated, test added. Committed to svn on 2006-09-26 > Allow unicode literals to be used > - > > Key: JEXL-22 > URL: http://issues.apache.org/jira/browse/JEXL-22 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: dion gillard >Priority: Minor > Fix For: 1.1.1 > > > How can I use international characters in JEXL expressions? > For example: myvar == 'U?ytkownik' (string constant contains Polish 'z' > with dot) > I get the following exception: > org.apache.commons.jexl.parser.TokenMgrError: Lexical error at line 1, > column 17. Encountered: "\u0139" (313), after : "\'U" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JEXL-23) Fix jdk1.3 only code that has crept into Jexl tests
Fix jdk1.3 only code that has crept into Jexl tests
---
Key: JEXL-23
URL: http://issues.apache.org/jira/browse/JEXL-23
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 1.1
Reporter: dion gillard
Priority: Minor
Fix For: 1.1.1
Download jdk1.2 from http://java.sun.com/products/jdk/1.2/download.html and
install.
Build JEXL with maven:
maven -Dmaven.compile.fork=yes
-Dmaven.compile.executable=c:\jdk1.2.2\bin\javac.exe -Dbuild.compiler=classic
clean test
Errors:
test:compile:
[javac] Compiling 13 source files to
C:\source\jakarta\jakarta-commons\jexl\target\test-classes
[javac]
C:\source\jakarta\jakarta-commons\jexl\src\test\org\apache\commons\jexl\JexlTest.java:331:
Method singletonMap(java.lang.String, java.lang.String) not found in class
java.util.Collections.
[javac] jc.getVars().put("map", Collections.singletonMap( "size",
"cheese"));
[javac] ^
[javac]
C:\source\jakarta\jakarta-commons\jexl\src\test\org\apache\commons\jexl\JexlTest.java:754:
Method singletonMap(java.lang.String, java.util.List) not found in class
java.util.Collections.
[javac] Map m = Collections.singletonMap("aList",
Collections.EMPTY_LIST);
[javac] ^
[javac] 2 errors
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JEXL-24) Support Long for integer literal instead of Integers
[ http://issues.apache.org/jira/browse/JEXL-24?page=all ] dion gillard updated JEXL-24: - Attachment: JEXL-24.patch.txt Patch attached. Before applying, this change should be discussed. > Support Long for integer literal instead of Integers > > > Key: JEXL-24 > URL: http://issues.apache.org/jira/browse/JEXL-24 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: dion gillard >Priority: Minor > Fix For: 1.1.1 > > Attachments: JEXL-24.patch.txt > > > Manisha Athavale reports: > Hello, > We use the jexl 1.1 jar for simple expression evaluation. The parser > throws number format exception when gave expression like "3988514195 - SP". > What is the limit for constants used in expression? Actually, there should > not be any limit for constants in the expression, is it correct? > Integer literals (such as the one above) are bound by Integer.MAX_VALUE. You > may have better luck changing the value to 3988514195.0 > Consider this a request for integer literals to be stored as Longs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JEXL-22) Allow unicode literals to be used
[ http://issues.apache.org/jira/browse/JEXL-22?page=comments#action_12437808 ] dion gillard commented on JEXL-22: -- I've used the original report to add a test to JexlTest, have regenerated the code and tested it. I'm doing the tedious merge/restyle of the generated code so it matches SVN and generates smaller commit messages. > Allow unicode literals to be used > - > > Key: JEXL-22 > URL: http://issues.apache.org/jira/browse/JEXL-22 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: dion gillard >Priority: Minor > Fix For: 1.1.1 > > > How can I use international characters in JEXL expressions? > For example: myvar == 'U?ytkownik' (string constant contains Polish 'z' > with dot) > I get the following exception: > org.apache.commons.jexl.parser.TokenMgrError: Lexical error at line 1, > column 17. Encountered: "\u0139" (313), after : "\'U" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JEXL-22) Allow unicode literals to be used
[ http://issues.apache.org/jira/browse/JEXL-22?page=comments#action_12437803 ] dion gillard commented on JEXL-22: -- javacc 4 generates jdk1.4 compatible source code by default. If you need 1.3 or 1.2 compatible input use JDK_VERSION:1.2 The generated code still seems to have a few 1.4 specific pieces in it, such as use of RuntimeException(Throwable). If you want to compile Jexl against 1.2/1.3 using maven, you'll need the following command line invocation (all on one line): maven -Dmaven.compile.fork=yes -Dmaven.compile.executable=c:\jdk1.3.1_16\bin\javac.exe -Dbuild.compiler=modern clean test Obviously the javac executable will probably be different on your machine. > Allow unicode literals to be used > - > > Key: JEXL-22 > URL: http://issues.apache.org/jira/browse/JEXL-22 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: dion gillard >Priority: Minor > Fix For: 1.1.1 > > > How can I use international characters in JEXL expressions? > For example: myvar == 'U?ytkownik' (string constant contains Polish 'z' > with dot) > I get the following exception: > org.apache.commons.jexl.parser.TokenMgrError: Lexical error at line 1, > column 17. Encountered: "\u0139" (313), after : "\'U" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JEXL-24) Support Long for integer literal instead of Integers
Support Long for integer literal instead of Integers Key: JEXL-24 URL: http://issues.apache.org/jira/browse/JEXL-24 Project: Commons JEXL Issue Type: Improvement Affects Versions: 1.1 Reporter: dion gillard Priority: Minor Fix For: 1.1.1 Manisha Athavale reports: Hello, We use the jexl 1.1 jar for simple expression evaluation. The parser throws number format exception when gave expression like "3988514195 - SP". What is the limit for constants used in expression? Actually, there should not be any limit for constants in the expression, is it correct? Integer literals (such as the one above) are bound by Integer.MAX_VALUE. You may have better luck changing the value to 3988514195.0 Consider this a request for integer literals to be stored as Longs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JEXL-23) Fix jdk1.3 only code that has crept into Jexl tests
[ http://issues.apache.org/jira/browse/JEXL-23?page=all ]
dion gillard resolved JEXL-23.
--
Resolution: Fixed
Code committed in http://svn.apache.org/viewvc?view=rev&revision=450035
> Fix jdk1.3 only code that has crept into Jexl tests
> ---
>
> Key: JEXL-23
> URL: http://issues.apache.org/jira/browse/JEXL-23
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: dion gillard
>Priority: Minor
> Fix For: 1.1.1
>
>
> Download jdk1.2 from http://java.sun.com/products/jdk/1.2/download.html and
> install.
> Build JEXL with maven:
> maven -Dmaven.compile.fork=yes
> -Dmaven.compile.executable=c:\jdk1.2.2\bin\javac.exe -Dbuild.compiler=classic
> clean test
> Errors:
> test:compile:
> [javac] Compiling 13 source files to
> C:\source\jakarta\jakarta-commons\jexl\target\test-classes
> [javac]
> C:\source\jakarta\jakarta-commons\jexl\src\test\org\apache\commons\jexl\JexlTest.java:331:
> Method singletonMap(java.lang.String, java.lang.String) not found in class
> java.util.Collections.
> [javac] jc.getVars().put("map", Collections.singletonMap( "size",
> "cheese"));
> [javac] ^
> [javac]
> C:\source\jakarta\jakarta-commons\jexl\src\test\org\apache\commons\jexl\JexlTest.java:754:
> Method singletonMap(java.lang.String, java.util.List) not found in class
> java.util.Collections.
> [javac] Map m = Collections.singletonMap("aList",
> Collections.EMPTY_LIST);
> [javac] ^
> [javac] 2 errors
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JEXL-22) Allow unicode literals to be used
[ http://issues.apache.org/jira/browse/JEXL-22?page=comments#action_12437802 ] dion gillard commented on JEXL-22: -- >From Randy H: I had similar issue with the latest jexl 1.1 release. Seems the option for unicode support is not enabled when using the parser was generated. Here is what I did to get it work with non-ASCII code: 1. Download and unzip jexl 1.1 source from: http://www.axint.net/apache/jakarta/commons/jexl/source/commons-jexl-1.1-src.zip 2. Download and unzip JavaCC 4.0 from: https://javacc.dev.java.net/files/documents/17/26777/javacc-4.0.zip 3. Run javacc-4.0\bin\javacc -UNICODE_INPUT commons-jexl-1.1-src\src\java\org\apache\commons\jexl\parser\Parser.jj 4. Copy *.java to commons-jexl-1.1-src\src\java\org\apache\commons\jexl\parser 5. Run ant -f commons-jexl-1.1-src\build.xml 6. Use the new jar commons-jexl-1.1-src\target\commons-jexl-1.1.jar 7. Profilt! :) > Allow unicode literals to be used > - > > Key: JEXL-22 > URL: http://issues.apache.org/jira/browse/JEXL-22 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: dion gillard >Priority: Minor > Fix For: 1.1.1 > > > How can I use international characters in JEXL expressions? > For example: myvar == 'U?ytkownik' (string constant contains Polish 'z' > with dot) > I get the following exception: > org.apache.commons.jexl.parser.TokenMgrError: Lexical error at line 1, > column 17. Encountered: "\u0139" (313), after : "\'U" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JEXL-22) Allow unicode literals to be used
Allow unicode literals to be used - Key: JEXL-22 URL: http://issues.apache.org/jira/browse/JEXL-22 Project: Commons JEXL Issue Type: Improvement Affects Versions: 1.1 Reporter: dion gillard Priority: Minor Fix For: 1.1.1 How can I use international characters in JEXL expressions? For example: myvar == 'Użytkownik' (string constant contains Polish 'z' with dot) I get the following exception: org.apache.commons.jexl.parser.TokenMgrError: Lexical error at line 1, column 17. Encountered: "\u0139" (313), after : "\'U" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JEXL-19) Ternary conditional not supported
[ http://issues.apache.org/jira/browse/JEXL-19?page=comments#action_12433018 ] dion gillard commented on JEXL-19: -- Back when JEXL was first developed it may have been an EL superset, but EL has had at least one release since then, and includes functions and other stuff JEXL doesn't do. This would be a welcome addition. > Ternary conditional not supported > - > > Key: JEXL-19 > URL: http://issues.apache.org/jira/browse/JEXL-19 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 1.1 > Environment: Linux, JDK 5 >Reporter: Jesse Glick > > Although the JEXL docs seem to imply that it is a superset of EL, it does not > appear to support the ternary conditional, i.e. > name != null ? name : 'default' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-236) Whitespace normalization in Jelly is wrong
[ http://issues.apache.org/jira/browse/JELLY-236?page=comments#action_12426439 ] dion gillard commented on JELLY-236: No, I mean o.a.c.j.TagSupport#setTrim(boolean) which almost all Tags extend at some point. > Whitespace normalization in Jelly is wrong > -- > > Key: JELLY-236 > URL: http://issues.apache.org/jira/browse/JELLY-236 > Project: Commons Jelly > Issue Type: Bug >Reporter: Kohsuke Kawaguchi > > In XML, the convention is to only remove "ignorable whitespaces". Ignorable > whitespaces are defined as a text block that entirely consist of whitespaces, > surrounded by tags. So the following text are ignorable whitespaces: > // text between two start tags > // text between start and end tag > (Technically speaking, they are ignorable only when DTD says so, but those > are nevertheless people usually consider them pseudo-ignorable even if > there's no DTD.) > But the following text are never ignorable whitespaces: >x >y > Jelly agressively trims off whitespaces, even if they are not ignorable. So > in the above cases, it becomes: > x > y > Such mode of whitespace normalization is not seen anywhere else, and IMHO it > is confusing. > It is sometimes even harmful, for example because the following text: >some text here > ... becomes: > some texthere > and you end up losing the significant space character between 'text' and > 'here'. As an example of proper whitespace stripping, consult XSLT > (http://www.w3.org/TR/1999/REC-xslt-19991116#strip) > I do realize that one can control the whitespace stripping behavior by using > TagSupport.setEscapeText(boolean), but nevertheless I thought I would file a > bug to see if the development team is willing to consider this change. I also > do realize that this has some non-trivial compatibility implications. > If you are willing to fix this, I have already patched Jelly locally, so I'm > happy to contribute a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-236) Whitespace normalization in Jelly is wrong
[ http://issues.apache.org/jira/browse/JELLY-236?page=comments#action_12426391 ] dion gillard commented on JELLY-236: How does this affect trim()? > Whitespace normalization in Jelly is wrong > -- > > Key: JELLY-236 > URL: http://issues.apache.org/jira/browse/JELLY-236 > Project: Commons Jelly > Issue Type: Bug >Reporter: Kohsuke Kawaguchi > > In XML, the convention is to only remove "ignorable whitespaces". Ignorable > whitespaces are defined as a text block that entirely consist of whitespaces, > surrounded by tags. So the following text are ignorable whitespaces: > // text between two start tags > // text between start and end tag > (Technically speaking, they are ignorable only when DTD says so, but those > are nevertheless people usually consider them pseudo-ignorable even if > there's no DTD.) > But the following text are never ignorable whitespaces: >x >y > Jelly agressively trims off whitespaces, even if they are not ignorable. So > in the above cases, it becomes: > x > y > Such mode of whitespace normalization is not seen anywhere else, and IMHO it > is confusing. > It is sometimes even harmful, for example because the following text: >some text here > ... becomes: > some texthere > and you end up losing the significant space character between 'text' and > 'here'. As an example of proper whitespace stripping, consult XSLT > (http://www.w3.org/TR/1999/REC-xslt-19991116#strip) > I do realize that one can control the whitespace stripping behavior by using > TagSupport.setEscapeText(boolean), but nevertheless I thought I would file a > bug to see if the development team is willing to consider this change. I also > do realize that this has some non-trivial compatibility implications. > If you are willing to fix this, I have already patched Jelly locally, so I'm > happy to contribute a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (JELLY-236) Whitespace normalization in Jelly is wrong
[ http://issues.apache.org/jira/browse/JELLY-236?page=all ] dion gillard moved JEXL-18 to JELLY-236: Project: Commons Jelly (was: Commons JEXL) Key: JELLY-236 (was: JEXL-18) > Whitespace normalization in Jelly is wrong > -- > > Key: JELLY-236 > URL: http://issues.apache.org/jira/browse/JELLY-236 > Project: Commons Jelly > Issue Type: Bug >Reporter: Kohsuke Kawaguchi > > In XML, the convention is to only remove "ignorable whitespaces". Ignorable > whitespaces are defined as a text block that entirely consist of whitespaces, > surrounded by tags. So the following text are ignorable whitespaces: > // text between two start tags > // text between start and end tag > (Technically speaking, they are ignorable only when DTD says so, but those > are nevertheless people usually consider them pseudo-ignorable even if > there's no DTD.) > But the following text are never ignorable whitespaces: >x >y > Jelly agressively trims off whitespaces, even if they are not ignorable. So > in the above cases, it becomes: > x > y > Such mode of whitespace normalization is not seen anywhere else, and IMHO it > is confusing. > It is sometimes even harmful, for example because the following text: >some text here > ... becomes: > some texthere > and you end up losing the significant space character between 'text' and > 'here'. As an example of proper whitespace stripping, consult XSLT > (http://www.w3.org/TR/1999/REC-xslt-19991116#strip) > I do realize that one can control the whitespace stripping behavior by using > TagSupport.setEscapeText(boolean), but nevertheless I thought I would file a > bug to see if the development team is willing to consider this change. I also > do realize that this has some non-trivial compatibility implications. > If you are willing to fix this, I have already patched Jelly locally, so I'm > happy to contribute a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-233) JellyException.getMessage() shouldn't show pointless "null:-1:-1:" in the error message
[ http://issues.apache.org/jira/browse/JELLY-233?page=all ]
dion gillard resolved JELLY-233.
Resolution: Fixed
Committed - good idea.
> JellyException.getMessage() shouldn't show pointless "null:-1:-1:" in
> the error message
> -
>
> Key: JELLY-233
> URL: http://issues.apache.org/jira/browse/JELLY-233
> Project: Commons Jelly
> Issue Type: Improvement
> Components: core / taglib.core
>Affects Versions: 1.1
>Reporter: Kohsuke Kawaguchi
>
> JellyExceptions are often created without supplying location information. A
> little change to the JellyException.getMessage() can improve the readability
> of the error message, as follows:
> public String getMessage() {
> if(fileName==null && lineNumber==-1 && columnNumber==-1 &&
> elementName==null)
> return getReason();
> else
> return fileName + ":" + lineNumber + ":" + columnNumber + ": <" +
> elementName + "> " + getReason();
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-9) [email] Issue with host settings in a shared Server environment
[
http://issues.apache.org/jira/browse/EMAIL-9?page=comments#action_12420511 ]
dion gillard commented on EMAIL-9:
--
That definitely looks suspicious.
> [email] Issue with host settings in a shared Server environment
> ---
>
> Key: EMAIL-9
> URL: http://issues.apache.org/jira/browse/EMAIL-9
> Project: Commons Email
> Type: Bug
> Environment: Operating System: other
> Platform: All
> Reporter: Paul J DeCoursey
>
> So the quick and dirty is I'm setting up an HTMLEmail and the server is in a
> shared environment, there is another site on the server using commons-email,
> and
> I have no control over that site. I set the hostname and the authentication
> but
> after that it's taking the settings from the System.properies. Below is a snip
> from my code.
> org.apache.commons.mail.HtmlEmail email = new
> org.apache.commons.mail.HtmlEmail();
> email.setHostName(server);
> email.setAuthentication(username, password);
> After that point I can get the session:
> Session sess = email.getMailSession();
> sess.getProperty("mail.smtp.host");
> and the result of the getProperty("mail.smtp.host") does not equal the
> setting
> from the above server variable. It is now set to the value from
> System.propeties, again, not my setting.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-187) Wrong composite expression evaluation
[
http://issues.apache.org/jira/browse/JELLY-187?page=comments#action_12414535 ]
dion gillard commented on JELLY-187:
Looks good. Go for it! Luke - you're a committer on Jelly, right?
> Wrong composite expression evaluation
> -
>
> Key: JELLY-187
> URL: http://issues.apache.org/jira/browse/JELLY-187
> Project: Commons Jelly
> Type: Bug
> Components: core / taglib.core
> Versions: 1.0-RC1, 1.0, 1.0-RC2
> Reporter: dion gillard
> Fix For: 1.0.1
> Attachments: JELLY-187.patch, JELLY-187.patch
>
> I have tried to add the following test consdtion in method testExpresssions()
> from org.apache.commons.jelly.expression.TestExpressions.java:
> assertExpression("$type${topping}", "$typecheese");
> but it fails saying that it should be:
> assertExpression("$type${topping}", "typecheese");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-226) Upgrade dom4j and jaxen
[ http://issues.apache.org/jira/browse/JELLY-226?page=comments#action_12379161 ] dion gillard commented on JELLY-226: Looks good! > Upgrade dom4j and jaxen > --- > > Key: JELLY-226 > URL: http://issues.apache.org/jira/browse/JELLY-226 > Project: Jelly > Type: Wish > Components: core / taglib.core, taglib.jsl, taglib.xml > Reporter: Lukas Theussl > > I am struggling with upgrading dom4j and jaxen for our upcoming maven-1.1 > release (see http://jira.codehaus.org/browse/MAVEN-1345 and > http://jira.codehaus.org/browse/JAXEN-67 for some chunks of discussion). Part > of the problem seems to be some kind of binary incompatibility in project > dependencies of jelly. I tried to rebuild jelly with the latest dom4j-1.6.1 > and jaxen-1.1-beta-8 but failed due to several broken test cases, in > particular in the jsl tag library. It would be nice if we had a jelly release > with unified dependencies, even though I am not sure it will solve our > problem of dropped CDATA sections that I described in JAXEN-67. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-177) In JellyServlet, the procedure used to determine the script's location is too simplistic
[ http://issues.apache.org/jira/browse/JELLY-177?page=all ]
dion gillard updated JELLY-177:
---
Fix Version: 1.0.1
(was: 1.0-RC2)
Description:
In JellyServlet, the procedure used to determine the script's location is too
simplistic; it misses simple cases like the a *.jelly servlet-mapping.
I suggest replacing the getScript method with something like (taken in part
from the Freemarker servlet):
protected URL getScript(HttpServletRequest req)
throws MalformedURLException {
String scriptUrl = null;
String includedPath = (String)
req.getAttribute("javax.servlet.include.servlet_path");
if (includedPath != null) { //This is the result of a
RequestDispatcher include...
String includedPathInfo = (String)
req.getAttribute("javax.servlet.include.path_info");
if (includedPathInfo != null) {
scriptUrl = includedPathInfo;
} else {
scriptUrl = includedPath;
}
} else {
scriptUrl = req.getParameter("script");
if (scriptUrl == null) {
scriptUrl = req.getPathInfo();
}
if (scriptUrl == null) {
scriptUrl = req.getServletPath();
}
}
URL url = getServletContext().getResource(scriptUrl);
if (url == null) {
throw new IllegalArgumentException("Invalid script url:"
+ scriptUrl);
}
return url;
}
was:
In JellyServlet, the procedure used to determine the script's location is too
simplistic; it misses simple cases like the a *.jelly servlet-mapping.
I suggest replacing the getScript method with something like (taken in part
from the Freemarker servlet):
protected URL getScript(HttpServletRequest req)
throws MalformedURLException {
String scriptUrl = null;
String includedPath = (String)
req.getAttribute("javax.servlet.include.servlet_path");
if (includedPath != null) { //This is the result of a
RequestDispatcher include...
String includedPathInfo = (String)
req.getAttribute("javax.servlet.include.path_info");
if (includedPathInfo != null) {
scriptUrl = includedPathInfo;
} else {
scriptUrl = includedPath;
}
} else {
scriptUrl = req.getParameter("script");
if (scriptUrl == null) {
scriptUrl = req.getPathInfo();
}
if (scriptUrl == null) {
scriptUrl = req.getServletPath();
}
}
URL url = getServletContext().getResource(scriptUrl);
if (url == null) {
throw new IllegalArgumentException("Invalid script url:"
+ scriptUrl);
}
return url;
}
> In JellyServlet, the procedure used to determine the script's location is too
> simplistic
>
>
> Key: JELLY-177
> URL: http://issues.apache.org/jira/browse/JELLY-177
> Project: jelly
> Type: Bug
> Components: core / taglib.core
> Versions: 1.0-beta-5, 1.0-RC1
> Environment: Servlet, 1.0RC1
> Reporter: Denis Robert
> Priority: Minor
> Fix For: 1.0.1
>
> In JellyServlet, the procedure used to determine the script's location is too
> simplistic; it misses simple cases like the a *.jelly servlet-mapping.
> I suggest replacing the getScript method with something like (taken in part
> from the Freemarker servlet):
> protected URL getScript(HttpServletRequest req)
> throws MalformedURLException {
> String scriptUrl = null;
>
> String includedPath = (String)
> req.getAttribute("javax.servlet.include.servlet_path");
> if (includedPath != null) { //This is the result of a
> RequestDispatcher include...
> String includedPathInfo = (String)
> req.getAttribute("javax.servlet.include.path_info");
> if (includedPathInfo != null) {
> scriptUrl = includedPathInfo;
> } else {
> scriptUr
[jira] Updated: (JELLY-187) Wrong composite expression evaluation
[ http://issues.apache.org/jira/browse/JELLY-187?page=all ]
dion gillard updated JELLY-187:
---
Fix Version: 1.0.1
(was: 1.0-RC2)
Description:
I have tried to add the following test consdtion in method testExpresssions()
from org.apache.commons.jelly.expression.TestExpressions.java:
assertExpression("$type${topping}", "$typecheese");
but it fails saying that it should be:
assertExpression("$type${topping}", "typecheese");
was:
I have tried to add the following test consdtion in method testExpresssions()
from org.apache.commons.jelly.expression.TestExpressions.java:
assertExpression("$type${topping}", "$typecheese");
but it fails saying that it should be:
assertExpression("$type${topping}", "typecheese");
Version: 1.0-RC1
1.0-RC2
1.0
Environment:
> Wrong composite expression evaluation
> -
>
> Key: JELLY-187
> URL: http://issues.apache.org/jira/browse/JELLY-187
> Project: jelly
> Type: Bug
> Components: core / taglib.core
> Versions: 1.0-RC1, 1.0, 1.0-RC2
> Reporter: dion gillard
> Fix For: 1.0.1
>
> I have tried to add the following test consdtion in method testExpresssions()
> from org.apache.commons.jelly.expression.TestExpressions.java:
> assertExpression("$type${topping}", "$typecheese");
> but it fails saying that it should be:
> assertExpression("$type${topping}", "typecheese");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-209) Ant tags do not redirect stderr ou stdout to Ant tag
[ http://issues.apache.org/jira/browse/JELLY-209?page=all ]
dion gillard closed JELLY-209:
--
Resolution: Fixed
Fix Version: 1.0-RC2
Tested and applied
> Ant tags do not redirect stderr ou stdout to Ant tag
>
>
> Key: JELLY-209
> URL: http://issues.apache.org/jira/browse/JELLY-209
> Project: jelly
> Type: Bug
> Components: taglib.ant
> Versions: 1.0
> Environment: Sun JDK 1.4.2_07, commons-jelly-1.0-RC1.jar,
> commons-jelly-tags-ant-1.0.jar
> Reporter: Cyrille Le Clerc
> Fix For: 1.0-RC2
> Attachments: AntTag.java.diff,
> a-path-for-JELLY-209-commons-jelly-tags-ant-1.0.jar
>
> Ant tag (org.apache.commons.jelly.tags.ant.AntTag) does not redirect
> System.out and System.err to the target Ant tag (through the Ant Project).
> Due to this, System.out and System.err are not handled by Ant tasks (e.g.
> JunitTask should output in TEST-xxx.xml stdout and stderr).
> Sample of code to redirect stdout and stderr in
> org.apache.tools.ant.Main#runBuild(ClassLoader), version 1.6.2 :
> System.setOut(new PrintStream(new DemuxOutputStream(project, false)));
> System.setErr(new PrintStream(new DemuxOutputStream(project, true)));
> Patch :
> To patch this problem, I modified org.apache.commons.jelly.tags.ant.AntTag to
> redirect stdout and stderr before calling "task.perform()" and, after the
> task execution, reset stdout an stderr to their initial values.
> Diff of org.apache.commons.jelly.tags.ant.AntTag
> (It does not seem to be possible to attach files in Jira)
> Index: AntTag.java
> ===
> RCS file:
> /home/cvspublic/jakarta-commons/jelly/jelly-tags/ant/src/java/org/apache/commons/jelly/tags/ant/AntTag.java,v
> retrieving revision 1.34
> diff -r1.34 AntTag.java
> 18a19
> > import java.io.PrintStream;
> 36a38
> > import org.apache.tools.ant.DemuxOutputStream;
> 185c187,199
> < task.perform();
> ---
> > // according to org.apache.tools.ant.Main, redirect stdout
> > and stderr
> > PrintStream initialOut = System.out;
> > PrintStream initialErr = System.err;
> > PrintStream newOut = new PrintStream(new
> > DemuxOutputStream(project, false));
> > PrintStream newErr = new PrintStream(new
> > DemuxOutputStream(project, true));
> > try{
> > System.setOut(newOut);
> > System.setErr(newErr);
> > task.perform();
> > } finally {
> > System.setOut(initialOut);
> > System.setErr(initialErr);
> > }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-211) Use of commons-beanutils 1.6 classes in COMMONS_JELLY-1_0_RC1
[ http://issues.apache.org/jira/browse/JELLY-211?page=comments#action_63936 ] dion gillard commented on JELLY-211: BeanUtils 1.7 has two jars now. The core and the collections. Jelly needs the collections for the above code. > Use of commons-beanutils 1.6 classes in COMMONS_JELLY-1_0_RC1 > - > > Key: JELLY-211 > URL: http://issues.apache.org/jira/browse/JELLY-211 > Project: jelly > Type: Bug > Components: taglib.util > Versions: 1.0-RC1 > Environment: I believe any environment would reproduce this. It happened on > a Linux system installed with JPackage Java RPMs > Reporter: Fernando Nasser > > The release notes for COMMONS_JELLY-1_0_RC1 claim that jelly moved to > beanutils 1.7 but beanutils 1.7 does not have the class below. > [javac] > /usr/src/build/559923-noarch/BUILD/commons-jelly-1.0-RC1/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/SortTag.java:23: > cannot resolve symbol > [javac] symbol : class BeanComparator > [javac] location: package beanutils > [javac] import org.apache.commons.beanutils.BeanComparator; > [javac] ^ > [javac] > /usr/src/build/559923-noarch/BUILD/commons-jelly-1.0-RC1/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/SortTag.java:56: > cannot resolve symbol -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-207) http:get causes a null pointer exception
[ http://issues.apache.org/jira/browse/JELLY-207?page=comments#action_61880 ] dion gillard commented on JELLY-207: I'm not sure this is the right solution. All the get tags would then share the same session regardless of their nesting. > http:get causes a null pointer exception > > > Key: JELLY-207 > URL: http://issues.apache.org/jira/browse/JELLY-207 > Project: jelly > Type: Bug > Components: taglib.http > Environment: define:taglib > Reporter: Frank Cornelis > Attachments: SessionTag-static-httpclient.patch > > http:get causes a null pointer exception when used within define:tag with a > surrounding http:session > When a http:get that lives inside define:tag find a parent http:session, > which was defined inside define:taglib, then http:get creates a new > SessionTag object, which an unset httpclient, and tries to use it. This cause > a null pointer exception. Making the _httpClient static inside the SessionTag > solves to problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_58217 ] dion gillard commented on JELLY-85: --- This bug report is now redundant and should be closed, right Hans and Paul? > TagScript doesn't clear its cached tags after run() > --- > > Key: JELLY-85 > URL: http://issues.apache.org/jira/browse/JELLY-85 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Scott Howlett > Attachments: StaticTagScript_patch.txt, TagScript_patch.txt, > includeAndDefineExample.zip > > TagScript caches the tags it generates in a ThreadLocal. At the beginning of > run() it checks to see if the context wants to cache tags - if not, it clears > the cache and regenerates it. > But there is no corresponding check and cache clearing at the end of run(). > So if a tag holds onto some significant resource, that resource will hang > around until the thread goes away or until the tag is run again. > I am using Jelly Swing extensively, and various tags end up attached to the > AWT Event thread for the lifetime of my application. > As a quick fix, I have a patch that simply repeats the check-and-clear-cache > behavior at the end of TagScript.run(). I also have a patch that adds this > behavior to StaticTagScript, whose run() never seems to clear cached tags. > I am probably just unclear, but it seems to me that there is a deeper issue > as well - the context is being asked whether it wants to cache tags, but the > result of this question affects the TagScript, which is really independent of > the context. It seems like if context wants to cache tags, perhaps the > ThreadLocal used for their storage ought to belong to the context somehow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-171) Nested scripts should be compiled and cached
[ http://issues.apache.org/jira/browse/JELLY-171?page=history ] dion gillard closed JELLY-171: -- Resolution: Duplicate Dupe of JELLY-170 > Nested scripts should be compiled and cached > > > Key: JELLY-171 > URL: http://issues.apache.org/jira/browse/JELLY-171 > Project: jelly > Type: Improvement > Components: core / taglib.core > Versions: 1.0 > Environment: tomcat 5.0, Jelly 1.0 RC1 > Reporter: Arnaud Masson > > In the current version of jelly "import" tag, imported scripts are always > parsed and recompiled each time the containing script runs, even if this > script has already been compiled. > It isn't optimized if the compiled version of the main script must be cached > for multiple read, for instance a web page. > In a JSP context, all included pages are compiled when the main jsp is > compiled, so there is no performance penalty. That would be nice to have the > same thing in jelly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-161) jellySwing demo fail
[ http://issues.apache.org/jira/browse/JELLY-161?page=history ]
dion gillard resolved JELLY-161:
Resolution: Fixed
Fix Version: 1.0-RC2
I believe this has been fixed.
I successfully ran maven demo:swing from jelly-tags/swing.
> jellySwing demo fail
>
>
> Key: JELLY-161
> URL: http://issues.apache.org/jira/browse/JELLY-161
> Project: jelly
> Type: Bug
> Environment: I run this on Linux fedora 2, but problem does not seems to be
> arch dependent
> Reporter: Andre Legendre
> Fix For: 1.0-RC2
> Attachments: swing-demo-fix.txt
>
> when running
> maven demo:swing
> we finnaly get
> demo:swing:
> [java] Oct 18, 2004 2:50:22 PM org.apache.commons.jelly.tags.log.InfoTag
> doTag
> [java] INFO: Just evaluated the foo action!
> [java] Oct 18, 2004 2:50:22 PM
> org.apache.commons.jelly.tags.swing.FontTag createFont
> [java] INFO: Creating font from properties: {family=helvetica, size=20,
> name=helvetica}
> [java] Oct 18, 2004 2:50:24 PM
> org.apache.commons.jelly.tags.swing.FontTag createFont
> [java] INFO: Created font:
> java.awt.Font[family=Dialog,name=Dialog,style=plain,size=12]
> [java] Oct 18, 2004 2:50:25 PM
> org.apache.commons.jelly.tags.swing.FontTag createFont
> [java] INFO: Creating font from properties: {family=helvetica, size=14}
> [java] Oct 18, 2004 2:50:25 PM
> org.apache.commons.jelly.tags.swing.FontTag createFont
> [java] INFO: Created font:
> java.awt.Font[family=Dialog,name=Dialog,style=plain,size=12]
> [java] Oct 18, 2004 2:50:25 PM org.apache.commons.jelly.tags.log.InfoTag
> doTag
> [java] INFO: clicked on the New menu item!
> [java] Oct 18, 2004 2:50:25 PM org.apache.commons.jelly.tags.log.InfoTag
> doTag
> [java] INFO: Popup a file dialog!
> [java] Oct 18, 2004 2:50:26 PM org.apache.commons.jelly.tags.log.InfoTag
> doTag
> [java] INFO: about to run the GridBagLayout demo...
> [java] org.apache.commons.jelly.JellyTagException:
> file:/home/rcs/Master/extern/java/jakarta/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/example.jelly:56:51:
> could not include jelly script: gridBagDemo.jelly. Reason:
> org.apache.commons.jelly.JellyTagException:
> file:/home/rcs/Master/extern/java/jakarta/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/gridBagDemo.jelly:43:94:
> No bean property found: idpadx
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-196) SwitchTag can not be reused if default encountered
[ http://issues.apache.org/jira/browse/JELLY-196?page=history ] dion gillard resolved JELLY-196: Resolution: Fixed Added test in patch to TestSwitchTag. Added jelly file to SVN. All tests pass. > SwitchTag can not be reused if default encountered > -- > > Key: JELLY-196 > URL: http://issues.apache.org/jira/browse/JELLY-196 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0 > Environment: 1.0-RC2-SNAPSHOT > Reporter: Marc DeXeT > Fix For: 1.0-RC2 > Attachments: patch_2005.01.18_switchTag.test.txt, > patch_2005.01.18_switchTag.txt > > Script as > > > > > > > > > > > > > > > throws " should be the last tag within a " because of > SwitchTag boolean property defaultEncountered is not reset. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-168) jelly-tags/swing can not build
[ http://issues.apache.org/jira/browse/JELLY-168?page=history ]
dion gillard closed JELLY-168:
--
Resolution: Fixed
Fix Version: 1.0-RC2
I believe this is fixed.
> jelly-tags/swing can not build
> --
>
> Key: JELLY-168
> URL: http://issues.apache.org/jira/browse/JELLY-168
> Project: jelly
> Type: Bug
> Components: taglib.swing
> Versions: 1.0-beta-4
> Environment: Linux 2.6.8-1.521
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
> Reporter: carsten madsen
> Priority: Minor
> Fix For: 1.0-RC2
>
> When trying to build jelly-tags/swing I get the following error. Seems like
> the jelly test stuff is not in the jar file?
> [EMAIL PROTECTED] swing]$ maven
> __ __
> | \/ |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
> |_| |_\__,_|\_/\___|_||_| v. 1.0.1
> Attempting to download commons-jelly-SNAPSHOT.jar.
> build:start:
> java:prepare-filesystem:
> java:compile:
> [echo] Compiling to
> /opt/jakarta-commons/jelly/jelly-tags/swing/target/classes
> java:jar-resources:
> test:prepare-filesystem:
> test:test-resources:
> test:compile:
> [javac] Compiling 5 source files to
> /opt/jakarta-commons/jelly/jelly-tags/swing/target/test-classes
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:39:
> package org.apache.commons.jelly.test does not exist
> import org.apache.commons.jelly.test.BaseJellyTest;
> ^
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:45:
> cannot find symbol
> symbol: class BaseJellyTest
> public class TestSwingTags extends BaseJellyTest {
>^
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:65:
> cannot find symbol
> symbol : method getJellyContext()
> location: class org.apache.commons.jelly.swing.TestSwingTags
> JellyContext context = getJellyContext();
>^
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:67:
> cannot find symbol
> symbol : method assertEquals(java.awt.Dimension,java.awt.Dimension)
> location: class org.apache.commons.jelly.swing.TestSwingTags
> assertEquals(new Dimension(100,100), frame.getSize());
> ^
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:68:
> cannot find symbol
> symbol : method assertEquals(java.awt.Point,java.awt.Point)
> location: class org.apache.commons.jelly.swing.TestSwingTags
> assertEquals(new Point(200,200), frame.getLocation());
> ^
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:71:
> cannot find symbol
> symbol : method assertNotNull(javax.swing.JButton)
> location: class org.apache.commons.jelly.swing.TestSwingTags
> assertNotNull(button);
> ^
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:72:
> cannot find symbol
> symbol : method assertEquals(java.awt.Color,java.awt.Color)
> location: class org.apache.commons.jelly.swing.TestSwingTags
> assertEquals(new Color(0x11,0x22,0x33), button.getBackground());
> ^
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:73:
> cannot find symbol
> symbol : method assertEquals(java.awt.Color,java.awt.Color)
> location: class org.apache.commons.jelly.swing.TestSwingTags
> assertEquals(new Color(0x44,0x55,0x66), button.getForeground());
> ^
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:74:
> cannot find symbol
> symbol : method assertEquals(int,int)
> location: class org.apache.commons.jelly.swing.TestSwingTags
> assertEquals(DebugGraphics.FLASH_OPTION|DebugGraphics.LOG_OPTION,
> panel.getDebugGraphicsOptions());
> ^
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:75:
> cannot find symbol
> symbol : method assertEquals(int,int)
> location: class org.apache.commons.jelly.swing.TestSwingTags
> assertEquals(DebugGraphics.BUFFERED_OPTION,
> button.getDebugGraphicsOptions());
> ^
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:85:
> cannot find symbol
> symbol : method getJellyContext()
> location: class org.apache.commons.jelly.swing.TestSwingTags
> JellyContext context = getJellyContext();
>^
> /opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:93:
> cannot find symbol
> symbol : method assertE
[jira] Commented: (JELLY-187) Wrong composite expression evaluation
[
http://issues.apache.org/jira/browse/JELLY-187?page=comments#action_58204 ]
dion gillard commented on JELLY-187:
I think fixing this would be good for RC2
> Wrong composite expression evaluation
> -
>
> Key: JELLY-187
> URL: http://issues.apache.org/jira/browse/JELLY-187
> Project: jelly
> Type: Bug
> Components: core / taglib.core
> Reporter: dion gillard
>
> I have tried to add the following test consdtion in method testExpresssions()
> from org.apache.commons.jelly.expression.TestExpressions.java:
> assertExpression("$type${topping}", "$typecheese");
> but it fails saying that it should be:
> assertExpression("$type${topping}", "typecheese");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-199) Leak in IncludeTag or JellyContext.runScript
[ http://issues.apache.org/jira/browse/JELLY-199?page=history ] dion gillard resolved JELLY-199: Resolution: Fixed Fix Version: 1.0-RC2 Hans fixed this > Leak in IncludeTag or JellyContext.runScript > > > Key: JELLY-199 > URL: http://issues.apache.org/jira/browse/JELLY-199 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0-RC1 > Reporter: Hans Gilde > Priority: Critical > Fix For: 1.0-RC2 > > Now that the new tag caching has solved some problems, we have a leak in the > IncludeTag. This leak probably comes from some interaction between > JellyContext.runScript an the tag cache. > I marked this one critical because it's (hopefully) the last leak affecting > Maven. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-187) Wrong composite expression evaluation
[ http://issues.apache.org/jira/browse/JELLY-187?page=history ]
dion gillard updated JELLY-187:
---
Fix Version: 1.0-RC2
> Wrong composite expression evaluation
> -
>
> Key: JELLY-187
> URL: http://issues.apache.org/jira/browse/JELLY-187
> Project: jelly
> Type: Bug
> Components: core / taglib.core
> Reporter: dion gillard
> Fix For: 1.0-RC2
>
> I have tried to add the following test consdtion in method testExpresssions()
> from org.apache.commons.jelly.expression.TestExpressions.java:
> assertExpression("$type${topping}", "$typecheese");
> but it fails saying that it should be:
> assertExpression("$type${topping}", "typecheese");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-196) SwitchTag can not be reused if default encountered
[ http://issues.apache.org/jira/browse/JELLY-196?page=history ] dion gillard updated JELLY-196: --- Fix Version: 1.0-RC2 > SwitchTag can not be reused if default encountered > -- > > Key: JELLY-196 > URL: http://issues.apache.org/jira/browse/JELLY-196 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0 > Environment: 1.0-RC2-SNAPSHOT > Reporter: Marc DeXeT > Fix For: 1.0-RC2 > Attachments: patch_2005.01.18_switchTag.test.txt, > patch_2005.01.18_switchTag.txt > > Script as > > > > > > > > > > > > > > > throws " should be the last tag within a " because of > SwitchTag boolean property defaultEncountered is not reset. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-166) Intermittent error with weak reference wrapper
[ http://issues.apache.org/jira/browse/JELLY-166?page=history ] dion gillard resolved JELLY-166: Resolution: Fixed Fix Version: 1.0-RC2 (was: 1.0) Fixed in SVN trunk > Intermittent error with weak reference wrapper > -- > > Key: JELLY-166 > URL: http://issues.apache.org/jira/browse/JELLY-166 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0 > Reporter: dion gillard > Fix For: 1.0-RC2 > Attachments: includeAndDefineExample.zip > > The following happens sometimes when running tests: > [junit] Testcase: > testChoose(org.apache.commons.jelly.tags.junit.CaseTag$1):Caused an > ERROR > [junit] null:-1:-1: Attempt to use a script that has been garbage > collected. > [junit] org.apache.commons.jelly.JellyTagException: null:-1:-1: > Attempt to use a script that has been garbage collected. > [junit] at > org.apache.commons.jelly.impl.WeakReferenceWrapperScript.script(WeakReferenceWrapperScript.java:62) > [junit] at > org.apache.commons.jelly.impl.WeakReferenceWrapperScript.run(WeakReferenceWrapperScript.java:74) > [junit] at > org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-191) FileTag must allow to append to flat file
[ http://issues.apache.org/jira/browse/JELLY-191?page=history ] dion gillard resolved JELLY-191: Resolution: Fixed Fix Version: 1.0-RC2 Paul has fixed this I believe. > FileTag must allow to append to flat file > - > > Key: JELLY-191 > URL: http://issues.apache.org/jira/browse/JELLY-191 > Project: jelly > Type: Improvement > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Marc DeXeT > Priority: Minor > Fix For: 1.0-RC2 > > Core FileTag allows to write only XML or HTML content to file. > But there's a need to write flat content unix-like or in pseudo-xml (element > collection without document root). > So FileTag must allow to write flat content to file. > Proposition to add a boolean "flat" property. > There also a need to add "append" property to.. append to existing file :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-198) more accurate test/xml test non existent tag
[ http://issues.apache.org/jira/browse/JELLY-198?page=history ] dion gillard resolved JELLY-198: Resolution: Fixed Fix Version: 1.0-RC2 Used a clearly non-existent jelly class > more accurate test/xml test non existent tag > > > Key: JELLY-198 > URL: http://issues.apache.org/jira/browse/JELLY-198 > Project: jelly > Type: Improvement > Versions: 1.0-RC2 > Reporter: Marc DeXeT > Assignee: dion gillard > Priority: Trivial > Fix For: 1.0-RC2 > Attachments: patch_2005.01.22_nonexistentTag.txt > > src/test/org/apache/commons/jelly/test/xml/TestNonexistentTags.java is based > upon taglib xml in not in path : it could be false for people working with it > in classpath. > Proposition : replace xml taglib binding by fake library binding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-191) FileTag must allow to append to flat file
[ http://issues.apache.org/jira/browse/JELLY-191?page=comments#action_58084 ] dion gillard commented on JELLY-191: AFAICT append is only checked when working with the name attribute set. I propose fixing it for the case of 'var' as well. > FileTag must allow to append to flat file > - > > Key: JELLY-191 > URL: http://issues.apache.org/jira/browse/JELLY-191 > Project: jelly > Type: Improvement > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Marc DeXeT > Priority: Minor > Fix For: 1.0-RC2 > > Core FileTag allows to write only XML or HTML content to file. > But there's a need to write flat content unix-like or in pseudo-xml (element > collection without document root). > So FileTag must allow to write flat content to file. > Proposition to add a boolean "flat" property. > There also a need to add "append" property to.. append to existing file :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (JELLY-198) more accurate test/xml test non existent tag
[ http://issues.apache.org/jira/browse/JELLY-198?page=history ] dion gillard reassigned JELLY-198: -- Assign To: dion gillard > more accurate test/xml test non existent tag > > > Key: JELLY-198 > URL: http://issues.apache.org/jira/browse/JELLY-198 > Project: jelly > Type: Improvement > Versions: 1.0-RC2 > Reporter: Marc DeXeT > Assignee: dion gillard > Priority: Trivial > Fix For: 1.0-RC2 > Attachments: patch_2005.01.22_nonexistentTag.txt > > src/test/org/apache/commons/jelly/test/xml/TestNonexistentTags.java is based > upon taglib xml in not in path : it could be false for people working with it > in classpath. > Proposition : replace xml taglib binding by fake library binding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-198) more accurate test/xml test non existent tag
[ http://issues.apache.org/jira/browse/JELLY-198?page=comments#action_57948 ] dion gillard commented on JELLY-198: If you're using Maven to do the build it controls the classpath, and unless you've dumped the xml tags into maven_home/lib, it wont be there. But I like and agree with your comments. > more accurate test/xml test non existent tag > > > Key: JELLY-198 > URL: http://issues.apache.org/jira/browse/JELLY-198 > Project: jelly > Type: Improvement > Versions: 1.0-RC2 > Reporter: Marc DeXeT > Priority: Trivial > Attachments: patch_2005.01.22_nonexistentTag.txt > > src/test/org/apache/commons/jelly/test/xml/TestNonexistentTags.java is based > upon taglib xml in not in path : it could be false for people working with it > in classpath. > Proposition : replace xml taglib binding by fake library binding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-197) groundless unit tests suite.
[ http://issues.apache.org/jira/browse/JELLY-197?page=history ] dion gillard resolved JELLY-197: Resolution: Fixed Fix Version: 1.0-RC2 Fixed and tested > groundless unit tests suite. > > > Key: JELLY-197 > URL: http://issues.apache.org/jira/browse/JELLY-197 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0-RC2 > Reporter: Marc DeXeT > Assignee: dion gillard > Priority: Blocker > Fix For: 1.0-RC2 > Attachments: patch.jelly-tag.bean.suite.jelly.txt, patch.suite.jelly.txt > > Core unit test suite src/test/org/apache/commons/jelly/suite.jelly is > groundless. > She' using "assertTrue" tag WHICH DOESN'T EXIST ! > So tag is consiered as a StaticTag and test are not done :unit test always > successful on exam although > they can be wrong. > Output (see later) is meaningful. > There's same problem on > jelly-tags/bean/src/test/org/apache/commons/jelly/tags/bean/suite.jelly > -- output -- > this should always workthis should always workthis should always > work.this should always work. > Created a new bean: [EMAIL PROTECTED];city=London] > > . > Created a new bean: [EMAIL PROTECTED];city=London] > > . > > Created a new bean: [EMAIL PROTECTED];city=Atlanta] > > . test="true"> test="true">. test="true">. test="true">. test="true">. > Time: 0,203 > OK (17 tests) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-197) groundless unit tests suite.
[ http://issues.apache.org/jira/browse/JELLY-197?page=comments#action_57885 ] dion gillard commented on JELLY-197: Looks good. Testing now. > groundless unit tests suite. > > > Key: JELLY-197 > URL: http://issues.apache.org/jira/browse/JELLY-197 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0-RC2 > Reporter: Marc DeXeT > Assignee: dion gillard > Priority: Blocker > Attachments: patch.jelly-tag.bean.suite.jelly.txt, patch.suite.jelly.txt > > Core unit test suite src/test/org/apache/commons/jelly/suite.jelly is > groundless. > She' using "assertTrue" tag WHICH DOESN'T EXIST ! > So tag is consiered as a StaticTag and test are not done :unit test always > successful on exam although > they can be wrong. > Output (see later) is meaningful. > There's same problem on > jelly-tags/bean/src/test/org/apache/commons/jelly/tags/bean/suite.jelly > -- output -- > this should always workthis should always workthis should always > work.this should always work. > Created a new bean: [EMAIL PROTECTED];city=London] > > . > Created a new bean: [EMAIL PROTECTED];city=London] > > . > > Created a new bean: [EMAIL PROTECTED];city=Atlanta] > > . test="true"> test="true">. test="true">. test="true">. test="true">. > Time: 0,203 > OK (17 tests) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (JELLY-197) groundless unit tests suite.
[ http://issues.apache.org/jira/browse/JELLY-197?page=history ] dion gillard reassigned JELLY-197: -- Assign To: dion gillard > groundless unit tests suite. > > > Key: JELLY-197 > URL: http://issues.apache.org/jira/browse/JELLY-197 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0-RC2 > Reporter: Marc DeXeT > Assignee: dion gillard > Priority: Blocker > Attachments: patch.jelly-tag.bean.suite.jelly.txt, patch.suite.jelly.txt > > Core unit test suite src/test/org/apache/commons/jelly/suite.jelly is > groundless. > She' using "assertTrue" tag WHICH DOESN'T EXIST ! > So tag is consiered as a StaticTag and test are not done :unit test always > successful on exam although > they can be wrong. > Output (see later) is meaningful. > There's same problem on > jelly-tags/bean/src/test/org/apache/commons/jelly/tags/bean/suite.jelly > -- output -- > this should always workthis should always workthis should always > work.this should always work. > Created a new bean: [EMAIL PROTECTED];city=London] > > . > Created a new bean: [EMAIL PROTECTED];city=London] > > . > > Created a new bean: [EMAIL PROTECTED];city=Atlanta] > > . test="true"> test="true">. test="true">. test="true">. test="true">. > Time: 0,203 > OK (17 tests) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-177) In JellyServlet, the procedure used to determine the script's location is too simplistic
[ http://issues.apache.org/jira/browse/JELLY-177?page=history ]
dion gillard updated JELLY-177:
---
Version: 1.0-beta-5
1.0-RC1
(was: 1.0)
Fix Version: 1.0-RC2
> In JellyServlet, the procedure used to determine the script's location is too
> simplistic
>
>
> Key: JELLY-177
> URL: http://issues.apache.org/jira/browse/JELLY-177
> Project: jelly
> Type: Bug
> Components: core / taglib.core
> Versions: 1.0-beta-5, 1.0-RC1
> Environment: Servlet, 1.0RC1
> Reporter: Denis Robert
> Priority: Minor
> Fix For: 1.0-RC2
>
> In JellyServlet, the procedure used to determine the script's location is too
> simplistic; it misses simple cases like the a *.jelly servlet-mapping.
> I suggest replacing the getScript method with something like (taken in part
> from the Freemarker servlet):
> protected URL getScript(HttpServletRequest req)
> throws MalformedURLException {
> String scriptUrl = null;
>
> String includedPath = (String)
> req.getAttribute("javax.servlet.include.servlet_path");
> if (includedPath != null) { //This is the result of a
> RequestDispatcher include...
> String includedPathInfo = (String)
> req.getAttribute("javax.servlet.include.path_info");
> if (includedPathInfo != null) {
> scriptUrl = includedPathInfo;
> } else {
> scriptUrl = includedPath;
> }
> } else {
> scriptUrl = req.getParameter("script");
> if (scriptUrl == null) {
> scriptUrl = req.getPathInfo();
> }
> if (scriptUrl == null) {
> scriptUrl = req.getServletPath();
> }
> }
>
> URL url = getServletContext().getResource(scriptUrl);
> if (url == null) {
> throw new IllegalArgumentException("Invalid script url:"
> + scriptUrl);
> }
> return url;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_57804 ] dion gillard commented on JELLY-85: --- Hans, looks ok to me. Will run some tests tonight > TagScript doesn't clear its cached tags after run() > --- > > Key: JELLY-85 > URL: http://issues.apache.org/jira/browse/JELLY-85 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Scott Howlett > Attachments: StaticTagScript_patch.txt, TagScript_patch.txt, > includeAndDefineExample.zip > > TagScript caches the tags it generates in a ThreadLocal. At the beginning of > run() it checks to see if the context wants to cache tags - if not, it clears > the cache and regenerates it. > But there is no corresponding check and cache clearing at the end of run(). > So if a tag holds onto some significant resource, that resource will hang > around until the thread goes away or until the tag is run again. > I am using Jelly Swing extensively, and various tags end up attached to the > AWT Event thread for the lifetime of my application. > As a quick fix, I have a patch that simply repeats the check-and-clear-cache > behavior at the end of TagScript.run(). I also have a patch that adds this > behavior to StaticTagScript, whose run() never seems to clear cached tags. > I am probably just unclear, but it seems to me that there is a deeper issue > as well - the context is being asked whether it wants to cache tags, but the > result of this question affects the TagScript, which is really independent of > the context. It seems like if context wants to cache tags, perhaps the > ThreadLocal used for their storage ought to belong to the context somehow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-175) patch for jelly-tags-interaction
[ http://issues.apache.org/jira/browse/JELLY-175?page=comments#action_57623 ] dion gillard commented on JELLY-175: I'm still unsure if we can *use* LGPL binaries in ASF code. Note: we wont be distributing it. > patch for jelly-tags-interaction > > > Key: JELLY-175 > URL: http://issues.apache.org/jira/browse/JELLY-175 > Project: jelly > Type: Improvement > Environment: I've tested this in windows with and without cygwin. > Reporter: Ryan Christanson > Priority: Minor > Attachments: patch.txt > > I've attached a patch to the commons-jelly-tags-interaction jar. This > patch makes it so the interaction task will try to use jline: > http://jline.sourceforge.net/ > Jline makes it so a java console will have tab completion, and > history, and other goodies. > This is great, because the maven-console plugin uses the > commons-jelly-tags-interaction jar. So if you update the > commons-jelly-tags-interaction jar, and then tell the maven console > plugin to use the new jar, then your maven console will have history, > and tab completion. > I've set it up to remember all of the commands typed in any console, > further it uses that history as the tab completion source - so you can > tab complete past commands. > I've tested this in windows and it works great, but in windows with > cygwin, it doesn't do the fancy completion, but still works. > By the way, in windows, jline's lib doesn't support arrows for > history, so use CONTROL+P and CONTROL+N. > Its possible that there might be a better way to integrate jline into > this lib, i've just done what looked like the quickest way to get it > working so my maven console would have history and tab completion. > Maybe this feature could be enabled with a tag attribute? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-145) jelly -version should answer
[ http://issues.apache.org/jira/browse/JELLY-145?page=history ] dion gillard updated JELLY-145: --- Comment: was deleted > jelly -version should answer > > > Key: JELLY-145 > URL: http://issues.apache.org/jira/browse/JELLY-145 > Project: jelly > Type: Improvement > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Paul Libbrecht > Priority: Critical > > Currently "jelly -version" responds an exception whereas every normal > software would like to have a current version given. > This could be assorted to the version of each taglib (e.g. jelly > --tagLibVersion=swing). > My best wish would be to output this automagically out of the project.xml... > I am pretty sure maven users have requested, made, or even standardized this > already... > thanks > paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-145) jelly -version should answer
[ http://issues.apache.org/jira/browse/JELLY-145?page=history ] dion gillard updated JELLY-145: --- Comment: was deleted > jelly -version should answer > > > Key: JELLY-145 > URL: http://issues.apache.org/jira/browse/JELLY-145 > Project: jelly > Type: Improvement > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Paul Libbrecht > Priority: Critical > > Currently "jelly -version" responds an exception whereas every normal > software would like to have a current version given. > This could be assorted to the version of each taglib (e.g. jelly > --tagLibVersion=swing). > My best wish would be to output this automagically out of the project.xml... > I am pretty sure maven users have requested, made, or even standardized this > already... > thanks > paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-145) jelly -version should answer
[ http://issues.apache.org/jira/browse/JELLY-145?page=history ] dion gillard updated JELLY-145: --- Attachment: a.txt testing > jelly -version should answer > > > Key: JELLY-145 > URL: http://issues.apache.org/jira/browse/JELLY-145 > Project: jelly > Type: Improvement > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Paul Libbrecht > Priority: Critical > Attachments: a.txt > > Currently "jelly -version" responds an exception whereas every normal > software would like to have a current version given. > This could be assorted to the version of each taglib (e.g. jelly > --tagLibVersion=swing). > My best wish would be to output this automagically out of the project.xml... > I am pretty sure maven users have requested, made, or even standardized this > already... > thanks > paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-145) jelly -version should answer
[ http://issues.apache.org/jira/browse/JELLY-145?page=comments#action_57609 ] dion gillard commented on JELLY-145: a test > jelly -version should answer > > > Key: JELLY-145 > URL: http://issues.apache.org/jira/browse/JELLY-145 > Project: jelly > Type: Improvement > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Paul Libbrecht > Priority: Critical > Attachments: a.txt > > Currently "jelly -version" responds an exception whereas every normal > software would like to have a current version given. > This could be assorted to the version of each taglib (e.g. jelly > --tagLibVersion=swing). > My best wish would be to output this automagically out of the project.xml... > I am pretty sure maven users have requested, made, or even standardized this > already... > thanks > paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-194) New tag that copy text files replacing Jelly properties
[
http://issues.apache.org/jira/browse/JELLY-194?page=comments#action_57447 ]
dion gillard commented on JELLY-194:
Can this be done with core:file and core:import?
> New tag that copy text files replacing Jelly properties
> ---
>
> Key: JELLY-194
> URL: http://issues.apache.org/jira/browse/JELLY-194
> Project: jelly
> Type: New Feature
> Components: taglib.util
> Versions: 1.0
> Reporter: Felipe Leme
>
> Hi,
> It would be nice if there was a Jelly tag similar to that would
> copy text files replacing the Jelly properties.
> For instance, I need to copy a datasource XML definition to JBoss before
> running Cactus (on maven), but each developer in my project has its own
> database schema. So, I could have a XML file like this:
>
>
> ${ds.username}
> ${ds.password}
>
> And then something like this on maven.xml:
>
> toFile="${env.JBOSS_HOME}/server/default/deploy"/>
>
> If you think such tag is useful (and hence would be incorporated on Jelly), I
> could write the tag and test cases and then submit a patch (I'm just not sure
> what's the best name for it).
> -- Felipe
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-192) Graphical jelly script viewer
[ http://issues.apache.org/jira/browse/JELLY-192?page=comments#action_57404 ] dion gillard commented on JELLY-192: Have you seen the Jelly editor in the mevenide eclipse plugin? That does syntax highlighting, code assist etc. > Graphical jelly script viewer > - > > Key: JELLY-192 > URL: http://issues.apache.org/jira/browse/JELLY-192 > Project: jelly > Type: New Feature > Reporter: Marc DeXeT > Priority: Minor > > Jelly script can be very hard to read if there several instructions. > I think it would be interesting for users as developers to get a graphical > user-friendly viewer. > Each jelly script is an XML well formed document, and each tag is associated > to library. > They are designed to get parsed and associated to any alternativ > representation. > It's just an idea now. > But what about creating an functional representation of each tag : > We have already library associated to namespace. > Usually 'var' attribute value is an object reference. > With instropection tools we can get setters and object type. > So we have almost everything to establish control graph, reference usage and > type maps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-191) FileTag must allow to append to flat file
[ http://issues.apache.org/jira/browse/JELLY-191?page=comments#action_57378 ] dion gillard commented on JELLY-191: Huh? the file tag can write non-xml data. Just use the omitXmlDeclaration="true". What about that doesn't work? > FileTag must allow to append to flat file > - > > Key: JELLY-191 > URL: http://issues.apache.org/jira/browse/JELLY-191 > Project: jelly > Type: Improvement > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Marc DeXeT > Priority: Minor > > Core FileTag allows to write only XML or HTML content to file. > But there's a need to write flat content unix-like or in pseudo-xml (element > collection without document root). > So FileTag must allow to write flat content to file. > Proposition to add a boolean "flat" property. > There also a need to add "append" property to.. append to existing file :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-190) CLONE -New Tag for parallel iteration
[ http://issues.apache.org/jira/browse/JELLY-190?page=history ] dion gillard updated JELLY-190: --- Component: taglib.util (was: core / taglib.core) > CLONE -New Tag for parallel iteration > - > > Key: JELLY-190 > URL: http://issues.apache.org/jira/browse/JELLY-190 > Project: jelly > Type: New Feature > Components: taglib.util > Versions: 1.0-beta-5 > Environment: JDK 1.4_02 Windows XP > Reporter: Marc DeXeT > Priority: Minor > > IterateTag is like org.apache.commons.jelly.tags.core.ForEachTag but can > iterate over several collections. Where > org.apache.commons.jelly.tags.core.ForEachTag iterate over one collection and > set Value in one variable like : > > > > > IterateTag is like : > items="Collection_1;Collection_2;;Collection_P"> > > > > Each Collection points at next element at the same time. > Over the n iteration, for j = 1 to P : var_j = Collection_j.get(n); > IterateTag stop on the first ended collection, so n = Min( > Collection_1.size(), ..., Collection_P.size()); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-189) null pointer exception when executing a script that exist only in memory
[ http://issues.apache.org/jira/browse/JELLY-189?page=history ]
dion gillard resolved JELLY-189:
Resolution: Fixed
Fix Version: 1.0
JellyContext bug fixed.
> null pointer exception when executing a script that exist only in memory
>
>
> Key: JELLY-189
> URL: http://issues.apache.org/jira/browse/JELLY-189
> Project: jelly
> Type: Bug
> Components: core / taglib.core
> Versions: 1.0
> Environment: ibm websphere
> Reporter: Jeff Gregory
> Fix For: 1.0
>
> When executing a script that exist only in memory, Jelly throws a
> NullPointerException at
> org.apache.commons.jelly.JellyContext.getJellyContextURL(JellyContext.java:947)
> This code will fail even if the StringBuffer passed in is a valid jelly
> script.
> public void exectute(StringBuffer message) {
>OutputStream output = new ByteArrayOutputStream();
> try {
> XMLOutput xmlOutput =XMLOutput.createXMLOutput(output);
> InputSource script = new InputSource( new
> StringReader(message.toString()) );
> JellyContext context = new JellyContext();
> context.runScript( script, xmlOutput);
> xmlOutput.flush();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-189) null pointer exception when executing a script that exist only in memory
[
http://issues.apache.org/jira/browse/JELLY-189?page=comments#action_57340 ]
dion gillard commented on JELLY-189:
Found the bug, have added your test to TestEmbedded and have a fix.
Will keep testing and hopefully get it committed today.
> null pointer exception when executing a script that exist only in memory
>
>
> Key: JELLY-189
> URL: http://issues.apache.org/jira/browse/JELLY-189
> Project: jelly
> Type: Bug
> Components: core / taglib.core
> Versions: 1.0
> Environment: ibm websphere
> Reporter: Jeff Gregory
>
> When executing a script that exist only in memory, Jelly throws a
> NullPointerException at
> org.apache.commons.jelly.JellyContext.getJellyContextURL(JellyContext.java:947)
> This code will fail even if the StringBuffer passed in is a valid jelly
> script.
> public void exectute(StringBuffer message) {
>OutputStream output = new ByteArrayOutputStream();
> try {
> XMLOutput xmlOutput =XMLOutput.createXMLOutput(output);
> InputSource script = new InputSource( new
> StringReader(message.toString()) );
> JellyContext context = new JellyContext();
> context.runScript( script, xmlOutput);
> xmlOutput.flush();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-184) Using namespace-prefixes breaks Jelly
Using namespace-prefixes breaks Jelly
-
Key: JELLY-184
URL: http://issues.apache.org/jira/browse/JELLY-184
Project: jelly
Type: Bug
Components: core / taglib.core
Reporter: dion gillard
Using feature "http://xml.org/sax/features/namespace-prefixes"; breaks Jelly.
SAXParserFactory pf = SAXParserFactory.newInstance();
pf.setValidating (false);
pf.setNamespaceAware (true);
pf.setFeature ("http://xml.org/sax/features/namespace-prefixes";, true);
XMLReader reader = null;
SAXParser parser = pf.newSAXParser();
reader = parser.getXMLReader();
InputSource inSrc = new InputSource
(new FileReader(new File ("util/test.jelly")));
Jelly jelly = new Jelly();
JellyContext context = new JellyContext ();
ExtXMLParser jellyParser = new ExtXMLParser ();
jellyParser.setContext(context);
jellyParser.configure ();
reader.setContentHandler(jellyParser);
reader.parse (inSrc);
Script script = jellyParser.getScript ();
script.compile ();
script.run (context, XMLOutput.createXMLOutput(System.out));
results in:
[junit] org.apache.commons.jelly.JellyTagException: null:-1:-1:
null:2:88: This tag does not understand the '' attribute
[junit] at
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:600)
[junit] at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:239)
[junit] at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89)
The offending line is "pf.setFeature
("http://xml.org/sax/features/namespace-prefixes";, true)"
While setting this feature is, of course, not necessary for Jelly, the Jelly
script I want to use in the real application is embedded within a larger XML
file. This file is parsed into a SAX event buffer with the feature set (because
in general, namespace-prefixes are needed). The SAX events belonging to the
Jelly script are then "extracted" and fed to Jelly. Of course, I can filter out
the namespace prefix attributes (and I will, as a workaround). But Jelly should,
of course, not break because of these attributes being reported.
- Michael
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-183) jelly-ant-tags TaskContainer Support
[ http://issues.apache.org/jira/browse/JELLY-183?page=history ]
dion gillard updated JELLY-183:
---
Attachment: taskcontainer.patch
> jelly-ant-tags TaskContainer Support
>
>
> Key: JELLY-183
> URL: http://issues.apache.org/jira/browse/JELLY-183
> Project: jelly
> Type: New Feature
> Components: taglib.ant
> Reporter: dion gillard
> Attachments: taskcontainer.patch
>
> -- Moved from Bugzilla 28812 --
> I have added support for child-anttasks as described in
> http://ant.apache.org/manual/develop.html#writingowntask when using a
> TaskContainer-implementation. These are used in webtest-project by Canoo for
> example.
> diff follows:
> Index: AntTag.java
> ===
> RCS file:
> /home/cvspublic/jakarta-commons/jelly/jelly-tags/ant/src/java/org/apache/commons/jelly/tags/ant/AntTag.java,v
> retrieving revision 1.27
> diff -u -r1.27 AntTag.java
> --- AntTag.java 25 Feb 2004 01:23:59 - 1.27
> +++ AntTag.java 6 May 2004 15:35:56 -
> @@ -181,6 +181,10 @@
> // now lets set all the attributes of the child elements
> // : to do!
>
> + if (parentTask instanceof TaskContainer) {
> + ((TaskContainer)parentTask).addTask(task);
> + }
> +
> // now we're ready to invoke the task
> // XXX: should we call execute() or perform()?
> task.perform();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-183) jelly-ant-tags TaskContainer Support
jelly-ant-tags TaskContainer Support
Key: JELLY-183
URL: http://issues.apache.org/jira/browse/JELLY-183
Project: jelly
Type: New Feature
Components: taglib.ant
Reporter: dion gillard
Attachments: taskcontainer.patch
-- Moved from Bugzilla 28812 --
I have added support for child-anttasks as described in
http://ant.apache.org/manual/develop.html#writingowntask when using a
TaskContainer-implementation. These are used in webtest-project by Canoo for
example.
diff follows:
Index: AntTag.java
===
RCS file:
/home/cvspublic/jakarta-commons/jelly/jelly-tags/ant/src/java/org/apache/commons/jelly/tags/ant/AntTag.java,v
retrieving revision 1.27
diff -u -r1.27 AntTag.java
--- AntTag.java 25 Feb 2004 01:23:59 - 1.27
+++ AntTag.java 6 May 2004 15:35:56 -
@@ -181,6 +181,10 @@
// now lets set all the attributes of the child elements
// : to do!
+ if (parentTask instanceof TaskContainer) {
+ ((TaskContainer)parentTask).addTask(task);
+ }
+
// now we're ready to invoke the task
// XXX: should we call execute() or perform()?
task.perform();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-186) JellySWT doesn't support the FormLayout
[ http://issues.apache.org/jira/browse/JELLY-186?page=history ] dion gillard updated JELLY-186: --- Attachment: SWTTagLibrary-2.java SWTTagLibrary.java > JellySWT doesn't support the FormLayout > --- > > Key: JELLY-186 > URL: http://issues.apache.org/jira/browse/JELLY-186 > Project: jelly > Type: Bug > Components: taglib.swt > Reporter: dion gillard > Attachments: LayoutDataTag-2.java, LayoutDataTag-3.java, LayoutDataTag.java, > LayoutTagSupport-2.java, LayoutTagSupport.java, SWTTagLibrary-2.java, > SWTTagLibrary.java > > -- Moved from Bugzilla 30403 -- > With the attached files, it now does. Here's an example: > > > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-185) type attribute for any layout other than FillLayout doesn't work in the SWT tag library.
type attribute for any layout other than FillLayout doesn't work in the SWT tag
library.
Key: JELLY-185
URL: http://issues.apache.org/jira/browse/JELLY-185
Project: jelly
Type: Bug
Components: taglib.swt
Reporter: dion gillard
-- Moved from Bugzilla 30402 --
When trying to set the type of the rowLayout tag to "horizontal", it wouldn't
take. Looking at the source, the convertvalue() method in LayoutTag.java is
too restrictive in the if clause. Instead of:
if( bean instanceof FillLayout
it should read:
if( bean instanceof Layout
Here's the full corrected method:
protected Object convertValue(Object bean, String name, Object value)
throws JellyTagException {
if (bean instanceof Layout
&& name.equals("type")
&& value instanceof String) {
int style = SwtHelper.parseStyle(SWT.class, (String) value);
return new Integer(style);
}
return super.convertValue(bean, name, value);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-186) JellySWT doesn't support the FormLayout
[ http://issues.apache.org/jira/browse/JELLY-186?page=history ] dion gillard updated JELLY-186: --- Attachment: LayoutTagSupport-2.java LayoutTagSupport.java > JellySWT doesn't support the FormLayout > --- > > Key: JELLY-186 > URL: http://issues.apache.org/jira/browse/JELLY-186 > Project: jelly > Type: Bug > Components: taglib.swt > Reporter: dion gillard > Attachments: LayoutDataTag-2.java, LayoutDataTag-3.java, LayoutDataTag.java, > LayoutTagSupport-2.java, LayoutTagSupport.java, SWTTagLibrary-2.java, > SWTTagLibrary.java > > -- Moved from Bugzilla 30403 -- > With the attached files, it now does. Here's an example: > > > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-187) Wrong composite expression evaluation
Wrong composite expression evaluation
-
Key: JELLY-187
URL: http://issues.apache.org/jira/browse/JELLY-187
Project: jelly
Type: Bug
Components: core / taglib.core
Reporter: dion gillard
I have tried to add the following test consdtion in method testExpresssions()
from org.apache.commons.jelly.expression.TestExpressions.java:
assertExpression("$type${topping}", "$typecheese");
but it fails saying that it should be:
assertExpression("$type${topping}", "typecheese");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-188) tag library xml does not correctly parse body
[
http://issues.apache.org/jira/browse/JELLY-188?page=comments#action_57249 ]
dion gillard commented on JELLY-188:
For the xmlunit taglibrary:
If I invoke some Jelly script within an xml tag this "body" will not be parsed
correctly. As far as I understand the code the sequence
handler.startDocument();
invokeBody( newOutput);
handler.endDocument();
will always create an empty document since no tag will ever be reported and thus
all writes will be ignored.
The whole code in the body of the parseBody method in XMLUnitTagSupport.java
should be replaced by
protected Document parseBody(XMLOutput output) throws JellyTagException {
return parseText(getBodyText(false));
}
> tag library xml does not correctly parse body
> -
>
> Key: JELLY-188
> URL: http://issues.apache.org/jira/browse/JELLY-188
> Project: jelly
> Type: Bug
> Components: taglib.xml
> Reporter: dion gillard
>
> If I invoke some Jelly script within an xml tag this "body" will not be parsed
> correctly. As far as I understand the code the sequence
> handler.startDocument();
> invokeBody( newOutput);
> handler.endDocument();
> will always create an empty document since no tag will ever be reported and
> thus
> all writes will be ignored.
> The whole code in the body of the parseBody method in ParseTagSupport.java
> should be replaced by
> protected Document parseBody(XMLOutput output) throws JellyTagException {
> return parseText(getBodyText(false));
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-188) tag library xml does not correctly parse body
tag library xml does not correctly parse body
-
Key: JELLY-188
URL: http://issues.apache.org/jira/browse/JELLY-188
Project: jelly
Type: Bug
Components: taglib.xml
Reporter: dion gillard
If I invoke some Jelly script within an xml tag this "body" will not be parsed
correctly. As far as I understand the code the sequence
handler.startDocument();
invokeBody( newOutput);
handler.endDocument();
will always create an empty document since no tag will ever be reported and thus
all writes will be ignored.
The whole code in the body of the parseBody method in ParseTagSupport.java
should be replaced by
protected Document parseBody(XMLOutput output) throws JellyTagException {
return parseText(getBodyText(false));
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-186) JellySWT doesn't support the FormLayout
[ http://issues.apache.org/jira/browse/JELLY-186?page=history ] dion gillard updated JELLY-186: --- Attachment: LayoutDataTag.java LayoutDataTag-2.java LayoutDataTag-3.java In date/time order > JellySWT doesn't support the FormLayout > --- > > Key: JELLY-186 > URL: http://issues.apache.org/jira/browse/JELLY-186 > Project: jelly > Type: Bug > Components: taglib.swt > Reporter: dion gillard > Attachments: LayoutDataTag-2.java, LayoutDataTag-3.java, LayoutDataTag.java, > LayoutTagSupport-2.java, LayoutTagSupport.java, SWTTagLibrary-2.java, > SWTTagLibrary.java > > -- Moved from Bugzilla 30403 -- > With the attached files, it now does. Here's an example: > > > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-186) JellySWT doesn't support the FormLayout
JellySWT doesn't support the FormLayout --- Key: JELLY-186 URL: http://issues.apache.org/jira/browse/JELLY-186 Project: jelly Type: Bug Components: taglib.swt Reporter: dion gillard Attachments: LayoutDataTag-2.java, LayoutDataTag-3.java, LayoutDataTag.java, LayoutTagSupport-2.java, LayoutTagSupport.java, SWTTagLibrary-2.java, SWTTagLibrary.java -- Moved from Bugzilla 30403 -- With the attached files, it now does. Here's an example: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-182) Add parameter contentType to the EmailTag
Add parameter contentType to the EmailTag - Key: JELLY-182 URL: http://issues.apache.org/jira/browse/JELLY-182 Project: jelly Type: New Feature Components: taglib.email Reporter: dion gillard -- Moved from Bugzilla 26630 -- It would be nice if it were possible to specify the content type for the email message. text/plain can be the default, but in some cases text/html, etc. is useful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-181) SWT wallpaper support
[ http://issues.apache.org/jira/browse/JELLY-181?page=history ] dion gillard updated JELLY-181: --- Attachment: wallpaper.patch > SWT wallpaper support > - > > Key: JELLY-181 > URL: http://issues.apache.org/jira/browse/JELLY-181 > Project: jelly > Type: New Feature > Components: taglib.swt > Reporter: dion gillard > Attachments: wallpaper.patch > > -- Moved from Bugzilla 24466 -- > Attached is a patch that adds support for a 'wallpaper' attribute on Controls, > which one can use to set a wallpaper image (similar to a web page). > eg: > > ... > > Was useful for me, maybe it's useful for others. > Cheers, > Marcus -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-181) SWT wallpaper support
SWT wallpaper support - Key: JELLY-181 URL: http://issues.apache.org/jira/browse/JELLY-181 Project: jelly Type: New Feature Components: taglib.swt Reporter: dion gillard -- Moved from Bugzilla 24466 -- Attached is a patch that adds support for a 'wallpaper' attribute on Controls, which one can use to set a wallpaper image (similar to a web page). eg: ... Was useful for me, maybe it's useful for others. Cheers, Marcus -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-180) ClassLoader Problems with XMLParser and XMLParser reuse
ClassLoader Problems with XMLParser and XMLParser reuse --- Key: JELLY-180 URL: http://issues.apache.org/jira/browse/JELLY-180 Project: jelly Type: Bug Components: core / taglib.core Reporter: dion gillard -- Moved from bugzilla issue 17619 -- Hello, i had problems integrating jelly because of the ClassLoader set to the JellyContext is not promoted to the XMLParser. That leads to ClassNotFoundExceptions in resolving custom TagLibs. This should be added in JellyContext compileScript methods. The use of XMLParser in JellyContext needs a little more documentation not only because of a new XMLParser is always instantiated in compileScript(String uri) and compileScript(URL url) uses the per thread instance. Is it ok that the ImportTag therefore indirectly uses the same thread instance parser? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-177) In JellyServlet, the procedure used to determine the script's location is too simplistic
[
http://nagoya.apache.org/jira/browse/JELLY-177?page=comments#action_57045 ]
dion gillard commented on JELLY-177:
Seems like a good addition to the jelly servlet.
I'm happy to include this.
> In JellyServlet, the procedure used to determine the script's location is too
> simplistic
>
>
> Key: JELLY-177
> URL: http://nagoya.apache.org/jira/browse/JELLY-177
> Project: jelly
> Type: Bug
> Components: core / taglib.core
> Versions: 1.0
> Environment: Servlet, 1.0RC1
> Reporter: Denis Robert
> Priority: Minor
>
> In JellyServlet, the procedure used to determine the script's location is too
> simplistic; it misses simple cases like the a *.jelly servlet-mapping.
> I suggest replacing the getScript method with something like (taken in part
> from the Freemarker servlet):
> protected URL getScript(HttpServletRequest req)
> throws MalformedURLException {
> String scriptUrl = null;
>
> String includedPath = (String)
> req.getAttribute("javax.servlet.include.servlet_path");
> if (includedPath != null) { //This is the result of a
> RequestDispatcher include...
> String includedPathInfo = (String)
> req.getAttribute("javax.servlet.include.path_info");
> if (includedPathInfo != null) {
> scriptUrl = includedPathInfo;
> } else {
> scriptUrl = includedPath;
> }
> } else {
> scriptUrl = req.getParameter("script");
> if (scriptUrl == null) {
> scriptUrl = req.getPathInfo();
> }
> if (scriptUrl == null) {
> scriptUrl = req.getServletPath();
> }
> }
>
> URL url = getServletContext().getResource(scriptUrl);
> if (url == null) {
> throw new IllegalArgumentException("Invalid script url:"
> + scriptUrl);
> }
> return url;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://nagoya.apache.org/jira/browse/JELLY-85?page=comments#action_56756 ] dion gillard commented on JELLY-85: --- Hans and Paul, 'The attached pair of scripts seems to constantly raise the exception "Attempt to use a script that has been garbage collected.".' Can we put the attachment and work against JELLY-166, that's where the error above is first reported. I don't think it has much to do with JELLY-85 > TagScript doesn't clear its cached tags after run() > --- > > Key: JELLY-85 > URL: http://nagoya.apache.org/jira/browse/JELLY-85 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Scott Howlett > Attachments: StaticTagScript_patch.txt, TagScript_patch.txt, > includeAndDefineExample.zip > > TagScript caches the tags it generates in a ThreadLocal. At the beginning of > run() it checks to see if the context wants to cache tags - if not, it clears > the cache and regenerates it. > But there is no corresponding check and cache clearing at the end of run(). > So if a tag holds onto some significant resource, that resource will hang > around until the thread goes away or until the tag is run again. > I am using Jelly Swing extensively, and various tags end up attached to the > AWT Event thread for the lifetime of my application. > As a quick fix, I have a patch that simply repeats the check-and-clear-cache > behavior at the end of TagScript.run(). I also have a patch that adds this > behavior to StaticTagScript, whose run() never seems to clear cached tags. > I am probably just unclear, but it seems to me that there is a deeper issue > as well - the context is being asked whether it wants to cache tags, but the > result of this question affects the TagScript, which is really independent of > the context. It seems like if context wants to cache tags, perhaps the > ThreadLocal used for their storage ought to belong to the context somehow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-166) Intermittent error with weak reference wrapper
[ http://nagoya.apache.org/jira/browse/JELLY-166?page=history ] dion gillard updated JELLY-166: --- Fix Version: 1.0 > Intermittent error with weak reference wrapper > -- > > Key: JELLY-166 > URL: http://nagoya.apache.org/jira/browse/JELLY-166 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0 > Reporter: dion gillard > Fix For: 1.0 > > The following happens sometimes when running tests: > [junit] Testcase: > testChoose(org.apache.commons.jelly.tags.junit.CaseTag$1):Caused an > ERROR > [junit] null:-1:-1: Attempt to use a script that has been garbage > collected. > [junit] org.apache.commons.jelly.JellyTagException: null:-1:-1: > Attempt to use a script that has been garbage collected. > [junit] at > org.apache.commons.jelly.impl.WeakReferenceWrapperScript.script(WeakReferenceWrapperScript.java:62) > [junit] at > org.apache.commons.jelly.impl.WeakReferenceWrapperScript.run(WeakReferenceWrapperScript.java:74) > [junit] at > org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-172) util:properties locks the file forever
[ http://nagoya.apache.org/jira/browse/JELLY-172?page=history ] dion gillard resolved JELLY-172: Resolution: Fixed Fix Version: 1.0 Committed > util:properties locks the file forever > -- > > Key: JELLY-172 > URL: http://nagoya.apache.org/jira/browse/JELLY-172 > Project: jelly > Type: Bug > Components: taglib.util > Environment: windows, util-taglib version that comes with maven 1.0.2 > Reporter: Matthias Kerkhoff > Fix For: 1.0 > Attachments: PropertiesTag.java, suite.jelly > > The following code (taken from a maven script) will always fail: > > > > From looking tinto the source, I would guess that the problem is an > InputStream which is opened, but never closed. > The problem definitly appears on windows, can't test on other platforms. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-169) Testing fails in JDK 1.5
[ http://nagoya.apache.org/jira/browse/JELLY-169?page=comments#action_55998 ] dion gillard commented on JELLY-169: Which version of Maven are you using. This sounds awfully like a bug I reported which has only surfaced on Maven 1.1-SNAPSHOT so far. > Testing fails in JDK 1.5 > > > Key: JELLY-169 > URL: http://nagoya.apache.org/jira/browse/JELLY-169 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Paul Libbrecht > Fix For: 1.0 > > Currently, running maven jar fails in both jelly and jelly-swing with JDK > 1.5. The TestXXXtags fail. > paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-169) Testing fails in JDK 1.5
[ http://nagoya.apache.org/jira/browse/JELLY-169?page=history ] dion gillard resolved JELLY-169: Resolution: Duplicate Fix Version: 1.0 Dupe of JELLY-166 > Testing fails in JDK 1.5 > > > Key: JELLY-169 > URL: http://nagoya.apache.org/jira/browse/JELLY-169 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Paul Libbrecht > Fix For: 1.0 > > Currently, running maven jar fails in both jelly and jelly-swing with JDK > 1.5. The TestXXXtags fail. > paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-166) Intermittent error with weak reference wrapper
Intermittent error with weak reference wrapper -- Key: JELLY-166 URL: http://nagoya.apache.org/jira/browse/JELLY-166 Project: jelly Type: Bug Components: core / taglib.core Versions: 1.0 Reporter: dion gillard The following happens sometimes when running tests: [junit] Testcase: testChoose(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] null:-1:-1: Attempt to use a script that has been garbage collected. [junit] org.apache.commons.jelly.JellyTagException: null:-1:-1: Attempt to use a script that has been garbage collected. [junit] at org.apache.commons.jelly.impl.WeakReferenceWrapperScript.script(WeakReferenceWrapperScript.java:62) [junit] at org.apache.commons.jelly.impl.WeakReferenceWrapperScript.run(WeakReferenceWrapperScript.java:74) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-164) New Tag for parallel iteration
[ http://nagoya.apache.org/jira/browse/JELLY-164?page=comments#action_55643 ] dion gillard commented on JELLY-164: I'm not sure this should be in the core package > New Tag for parallel iteration > -- > > Key: JELLY-164 > URL: http://nagoya.apache.org/jira/browse/JELLY-164 > Project: jelly > Type: New Feature > Components: core / taglib.core > Versions: 1.0-beta-5 > Environment: JDK 1.4_02 Windows XP > Reporter: Marc DeXeT > Priority: Minor > Attachments: IterateTag.java, TestIterateTag.java, patchIterateTag.txt, > testIterateTag.jelly > > IterateTag is like org.apache.commons.jelly.tags.core.ForEachTag but can > iterate over several collections. Where > org.apache.commons.jelly.tags.core.ForEachTag iterate over one collection and > set Value in one variable like : > > > > > IterateTag is like : > items="Collection_1;Collection_2;;Collection_P"> > > > > Each Collection points at next element at the same time. > Over the n iteration, for j = 1 to P : var_j = Collection_j.get(n); > IterateTag stop on the first ended collection, so n = Min( > Collection_1.size(), ..., Collection_P.size()); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-162) Proposed change/improvement to jelly-tags-email
[ http://nagoya.apache.org/jira/browse/JELLY-162?page=comments#action_55479 ] dion gillard commented on JELLY-162: Once commons-email goes 1.0, we should do this. > Proposed change/improvement to jelly-tags-email > --- > > Key: JELLY-162 > URL: http://nagoya.apache.org/jira/browse/JELLY-162 > Project: jelly > Type: Improvement > Components: taglib.email > Versions: 1.0-beta-4 > Reporter: Corey Scott > Attachments: conversion_to_commons_email.txt > > Attached is a proposed change to the jelly-tags:email component that converts > it to leverage of the (soon to be upgraded and released, hopefully) > commons-email. In particular the the HtmlEmail class. The commons-email > component is quite stable and is hopefull to be getting a 1.0 release in the > very near future. > This proposed change is a first version and as such offers no major > improvements, other than the fact that the base component is thoroughly > tested and has good input/bound checking. > If this change is accepted, I would like propose that this component be > further extended, particularly to leverage off some of the extra > functionality provided in commons-email. E.g. Bcc, separate HTML, Text, > MimeMultipart messages bodies, and mulitple attachments. > Thanks, > Corey Scott > Commons-Email contributer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-24) Release Issue 2 - Jelly public API
[ http://issues.apache.org/jira/browse/JELLY-24?page=history ] dion gillard updated JELLY-24: -- Environment: Fix Version: 1.1-beta-1 (was: 1.0) Moving this to 1.1 as we've decided to keep the API as is for 1.0 and do the change/reorg in 1.1 > Release Issue 2 - Jelly public API > -- > > Key: JELLY-24 > URL: http://issues.apache.org/jira/browse/JELLY-24 > Project: jelly > Type: Task > Components: documentation > Reporter: Morgan Delagrange > Assignee: Morgan Delagrange > Priority: Minor > Fix For: 1.1-beta-1 > > 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=10415308592&r=1&w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
