Re: [JEXL] svn commit: r543799 - in /jakarta/commons/proper/jelly/trunk/xdocs/style: ./ project.css

[peter royal]

On Jun 3, 2007, at 8:27 AM, Rahul Akolkar wrote:

On 6/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: proyal
Date: Sat Jun  2 15:59:58 2007
New Revision: 543799

URL: http://svn.apache.org/viewvc?view=rev&rev=543799
Log:
add new project stylesheet




Missing props.


I set eol-style.. doesn't need anything else, right?

-pete


--
[EMAIL PROTECTED] - http://fotap.org/~osi





smime.p7s
Description: S/MIME cryptographic signature

Re: [jexl] grammar for defining a map

[peter royal]

On Jun 3, 2007, at 8:24 AM, Rahul Akolkar wrote:

On 6/2/07, peter royal <[EMAIL PROTECTED]> wrote:

On Jun 1, 2007, at 10:09 PM, Dion Gillard wrote:
> +1

done! see http://svn.apache.org/viewvc/jakarta/commons/proper/jexl/
trunk/src/test/org/apache/commons/jexl/MapLiteralTest.java?
view=markup for example usage.




Cool. Can you complete the related commit (see nightly build and  
gump nags).


Yup, just saw the nag and patched it up. Thanks for the reminder!

-pete


--
[EMAIL PROTECTED] - http://fotap.org/~osi





smime.p7s
Description: S/MIME cryptographic signature

Re: svn commit: r543746 [1/2] - in /jakarta/commons/proper/jelly/trunk: ./ jelly-tags/ jelly-tags/ant/xdocs/ jelly-tags/antlr/xdocs/ jelly-tags/avalon/xdocs/ jelly-tags/bean/xdocs/ jelly-tags/beanshel

[peter royal]

On Jun 2, 2007, at 11:25 AM, Lukas Theussl wrote:
There is a part of my patch missing from your commit: the xdocs/ 
style/project.css file (quite vital for the general look of the  
site... ;) ), did you 'svn add' it?


ah, whoops :) thanks for catching that!

-pete


--
[EMAIL PROTECTED] - http://fotap.org/~osi





smime.p7s
Description: S/MIME cryptographic signature

Re: [jexl] grammar for defining a map

[peter royal]

On Jun 1, 2007, at 10:09 PM, Dion Gillard wrote:

+1


done! see http://svn.apache.org/viewvc/jakarta/commons/proper/jexl/ 
trunk/src/test/org/apache/commons/jexl/MapLiteralTest.java? 
view=markup for example usage.


-pete



On 6/2/07, peter royal <[EMAIL PROTECTED]> wrote:

So, I'd like to propose a syntax addition to jexl for allowing the
definition of a map:

   [ key => value, key => value ]

.. I have a patch ready to go.. I know there is the talk of "grammar
changes for 2.0", but that's who-knows-when and this is a very small
tweak that is an evolutionary change :)

-pete

--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi






--
dIon Gillard
Rule #131 of Acquisition: Information is Profit.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
[EMAIL PROTECTED] - http://fotap.org/~osi





smime.p7s
Description: S/MIME cryptographic signature

[jira] Commented: (JELLY-272) Lots of defect links in website

[peter royal (JIRA)]

[ 
https://issues.apache.org/jira/browse/JELLY-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500950
 ] 

peter royal commented on JELLY-272:
---

ah, k. patch applied, the updated site just needs pushing now.

> Lots of defect links in website
> ---
>
> Key: JELLY-272
> URL: https://issues.apache.org/jira/browse/JELLY-272
> Project: Commons Jelly
>  Issue Type: Bug
> Environment: none
>Reporter: Peter Büttner
> Attachments: JELLY-272.patch
>
>
> I found al lot of dead links in the jelly 'website', links to examples an a 
> lot 
> here: http://jakarta.apache.org/commons/jelly/tag-reference/index.html
> e.g. this is dead 
> http://jakarta.apache.org/commons/jelly/tag-reference/bsf.html
> and all of it sibling nodes.
> Opening http://jakarta.apache.org/commons/jelly/tag-reference/all.html
> and selecting any tagdoc shows a page, but with empty content.
> I think the CMS is defect.
> Greetings
> Peter

-- 
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: (JELLY-272) Lots of defect links in website

[peter royal (JIRA)]

[ 
https://issues.apache.org/jira/browse/JELLY-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500912
 ] 

peter royal commented on JELLY-272:
---

Lukas -- awesome! Can you commit it? :)

> Lots of defect links in website
> ---
>
> Key: JELLY-272
> URL: https://issues.apache.org/jira/browse/JELLY-272
> Project: Commons Jelly
>  Issue Type: Bug
> Environment: none
>Reporter: Peter Büttner
> Attachments: JELLY-272.patch
>
>
> I found al lot of dead links in the jelly 'website', links to examples an a 
> lot 
> here: http://jakarta.apache.org/commons/jelly/tag-reference/index.html
> e.g. this is dead 
> http://jakarta.apache.org/commons/jelly/tag-reference/bsf.html
> and all of it sibling nodes.
> Opening http://jakarta.apache.org/commons/jelly/tag-reference/all.html
> and selecting any tagdoc shows a page, but with empty content.
> I think the CMS is defect.
> Greetings
> Peter

-- 
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]

[jexl] grammar for defining a map

[peter royal]

So, I'd like to propose a syntax addition to jexl for allowing the  
definition of a map:


  [ key => value, key => value ]

.. I have a patch ready to go.. I know there is the talk of "grammar  
changes for 2.0", but that's who-knows-when and this is a very small  
tweak that is an evolutionary change :)


-pete

--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi



smime.p7s
Description: S/MIME cryptographic signature

[jira] Resolved: (JEXL-28) Enhance the resolution of properties and methods

[peter royal (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JEXL-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

peter royal resolved JEXL-28.
-

   Resolution: Won't Fix
Fix Version/s: 1.1.1

You can use your own Uberspect in JEXL-13 to achieve this.

> Enhance the resolution of properties and methods
> 
>
> Key: JEXL-28
> URL: https://issues.apache.org/jira/browse/JEXL-28
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Weikuo Liaw
>Priority: Critical
> Fix For: 1.1.1
>
>
> JexlContext need provide additional methods, such as
> 1) Object getProperty(Object object, String propName);
> 2) void setProperty(Object object, String propName, Object propValue);
> 3) Object invokeMethod(Object object, String methodName, Object[] params);
> where object can be null for the non-object properties/methods.
> ASTIdentifier, ASTArrayAccess, ASTAssignment, and ASTMethod can use them for 
> unresolvable properties/methods.
> This is similar to what are changed by myFacese over commons EL to support 
> friendly VariableResolver and PropertyResolver for applications.
> I use "ObjectinvokeMethod()" instead of "Method getMethod(object, 
> methodNae)", because a method may not be implemented as a java method. Such 
> as in commons validator, validators are registered in the configuration file 
> of validation forms.

-- 
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: (JEXL-13) [jexl] Make JEXL allow for an Uberspect plugin

[peter royal (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JEXL-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

peter royal resolved JEXL-13.
-

   Resolution: Fixed
Fix Version/s: (was: 2.0)
   1.1.1

I've been sitting on this solution for awhile.. you can supply your own 
Uberspect by creating an instance of the ExpressionFactory, rather than using 
the static instance that is provided.

> [jexl] Make JEXL allow for an Uberspect plugin
> --
>
> Key: JEXL-13
> URL: https://issues.apache.org/jira/browse/JEXL-13
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 1.0
> Environment: Operating System: All
> Platform: All
>Reporter: Doug Rand
>Assignee: peter royal
>Priority: Minor
> Fix For: 1.1.1
>
> Attachments: jexl-patch.txt, patch.txt
>
>
> Unlike Velocity, JEXL does not allow for the Uberspect object to be replaced 
> at
> runtime. By allowing replacement JEXL can be extended for Java 1.5 or other
> desireable functionality. I have a patch available for this.

-- 
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]

Re: [jelly] [vote] Release commons-jelly-tags-interaction 1.1

[peter royal]

The story seems quite simple so I thought I'd just ask for a vote  
sorry

if too stressed.
The interaction jelly tag-library is now ready for release 1.1.
It has been recently boosted with a finer control on auto-completion,
and maven console plugin is using it successfully.
Thanks to give it a try* and provide a vote.
This vote will last till Friday 12:00 GMT.

[ ] +1 yes let's release it
[X] +0 maybe
[ ] -0 seems not ready
[ ] -1 no, don't!


I support the release, but don't have time to actually test it.
-pete

--
[EMAIL PROTECTED] - http://fotap.org/~osi



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JEXL change desired

[peter royal]

On Jan 17, 2006, at 2:15 PM, [EMAIL PROTECTED] wrote:
I would like to propose a  change to JEXL to allow the introspector  
to be

plugged in rather than hardcoded. It looks like this would be a fairly
simple change.  My specific reason is that I would like to plug in  
a new
Introspector into both Velocity and JEXL in our implementation to  
allow

the recognition of certain Java 1.5 constructs - specifically varargs.


go for it.. it'd be great to have a java 1.5-ish introspector  
shipping with jexl as well! :)

-pete




smime.p7s
Description: S/MIME cryptographic signature

[jira] Commented: (JELLY-226) Upgrade dom4j and jaxen

[peter royal (JIRA)]

[ 
http://issues.apache.org/jira/browse/JELLY-226?page=comments#action_12361559 ] 

peter royal commented on JELLY-226:
---

understood. i'll push for a stable release of jaxen.

> 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] Commented: (JELLY-226) Upgrade dom4j and jaxen

[peter royal (JIRA)]

[ 
http://issues.apache.org/jira/browse/JELLY-226?page=comments#action_12361557 ] 

peter royal commented on JELLY-226:
---

Is Jaxen 1.1. a blocker? The 1.1 beta series is light-years better than 1.0 
was, and we're very slowly moving towards 1.1

> 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]

Re: [jelly] how to donate my JavaScript and Include tag libraries?

[peter royal]

On Sep 6, 2005, at 11:54 AM, Jon Brisbin wrote:
How would I go about donating these tags back to the Jelly  
community? Would it be beneficial to use the JavaScript tag as the  
basis for a standard tag with the jelly distro? I use it  
extensively and it would be an incredibly simple way to introduce  
scripting into an XML-based application. I use it to script my  
internal web application framework. I expose all the JellyContext  
variables to JavaScript, so you can manipulate the Jelly processing  
dynamically. It actually works pretty well and the capabilities  
make my life much easier when I go to write new apps.


The 'simple' answer is to post it as a patch in JIRA. I think it  
might make the most sense to have this available as a new tag  
library, would you agree?


Since it sounds like this is a larger contribution, it might be  
necessary for a CLA or a Software Grant to be filled out, apache.org/licenses/#clas>, but someone with more knowledge can  
clarify that..

-pete

--
peter royal



smime.p7s
Description: S/MIME cryptographic signature

[jira] Closed: (JELLY-219) Fix for JELLY-214 broke attribute behaviour of define:tag

[peter royal (JIRA)]

 [ http://issues.apache.org/jira/browse/JELLY-219?page=all ]
 
peter royal closed JELLY-219:
-

Fix Version: 1.1-beta-1
 Resolution: Fixed

Fixed! Thanks!

> Fix for JELLY-214 broke attribute behaviour of define:tag
> -
>
>  Key: JELLY-219
>  URL: http://issues.apache.org/jira/browse/JELLY-219
>  Project: jelly
> Type: Bug
>   Components: core / taglib.core, taglib.define
> Versions: 1.0-beta-4, 1.1-beta-1, 1.0-beta-5
>  Environment: Window XP, JDK1.5, Ant 1.6.5
> Reporter: Tony Robertson
>  Fix For: 1.1-beta-1

>
> When using the "tag" tag of the jelly:define taglib, the resulting tag is 
> supposed to support attributes getting exposed as context variables. eg:
>   
>   
>   message attribute is ${msg}
>   tag body is 
>   
>   
>   
> ...
>   other stuff
> This was broken by change to "org.apache.commons.jelly.impl.StaticTagScript" 
> that was introduced at revision 219726 as a fix for "JELLY-214" 
> Now, if any attributes are set on the tag, you get a class-cast exception 
> thrown when line 103 tries to cast the dynamic tag to a static tag.
> In fact, the condition on line 102 really doesn't make sense. Clearly the 
> "tag instanceof StaticTag" should be always required. I think the || 
> condition should probably be an &&.
> The following patch fixes this problem, but paul should probably check what 
> the intention of that line originally was.
> - Tony
> Index: StaticTagScript.java
> ===
> --- StaticTagScript.java  (revision 233399)
> +++ StaticTagScript.java  (working copy)
> @@ -99,7 +99,7 @@
>  value = expression.evaluate(context);
>  }
>  
> -if(expat.prefix!=null || expat.prefix.length()>0 && tag 
> instanceof StaticTag)
> +if (expat.prefix!=null && expat.prefix.length()>0 && tag 
> instanceof StaticTag)
>  ((StaticTag) dynaTag).setAttribute(name,expat.prefix, 
> expat.nsURI,value);
>  else
>  dynaTag.setAttribute(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
-
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]

Re: [jelly] 1.0-final problem wrt tag caching

[peter royal]

On Aug 15, 2005, at 3:22 AM, Paul Libbrecht wrote:
At least a quick summary of caching would be that: if caching is  
disabled, the tag object is renewed at the beginning of every new run.
(where I understood disabled caching would imply the tag would  
disappear much earlier).


Maybe that's a simple formulation...


That's exactly correct. On a per-thread basis, TagScript.run()  
results in a new Tag instance if caching is not enabled.

-pete

--
peter royal



smime.p7s
Description: S/MIME cryptographic signature

Re: [jelly] 1.0-final problem wrt tag caching

[peter royal]

On Aug 10, 2005, at 6:14 PM, Paul Libbrecht wrote:

I'm annoyed... I don't obtain the same results as you do.
With the default cacheTags value as false, I obtain only your test  
failing.


With the default cacheTags value as true, I obtain many failed tests.

Did you not say that with your commit, all jelly-core tests were  
passing ?


If not then we really need to push the NeedCaching and  
RefusesCaching interfaces. Right ?


yes, with the change I made, all the tests in jelly-core were  
passing. can you give an example or two of a test that's failing for  
you?


-pete

--
peter royal



smime.p7s
Description: S/MIME cryptographic signature

Re: [jelly] 1.0-final problem wrt tag caching

[peter royal]

On Jul 23, 2005, at 4:12 PM, Paul Libbrecht wrote:
Two things that are particularly picky and for which we need some  
form tag-caching:


- define'd tags ?
- the swing:action tag.

For the latter, things are particularly bad since you want to  
invoke the action on the bean of a tag (a component, say, that you  
want to change) without changing that component...


But... I'll let you experiment.


The unit tests for both of these taglibs passed with  
JellyContext.isCacheTags restored, so I've committed the change.


I'd like to pursue the interface that means 'cache me' so we can move  
forward with caching :)

-pete

--
peter royal



smime.p7s
Description: S/MIME cryptographic signature

Re: [jelly] 1.0-final problem wrt tag caching

[peter royal]

On Jul 27, 2005, at 4:16 PM, Paul Libbrecht wrote:

Maybe two simple steps:
- introduce caching flag... compatible to earlier version.
  But without guarantees...
- Introduce two flag interfaces:
   SingleUsageTag: needs to be recreated at every run
   StatefulTag: needs to be kept at every run
The value of the cache flag should be used for tags that implement  
neither of them.


If people agree we would, then, slowly mark tags that we know need  
one of the policies and people in an urge can apply SingleUsageTag  
to make sure the former policy is used. Moreover, several of the  
unit-tests should be run with and without setCacheTags.


How does it sound ?


At first blush, good idea!

Just got home from apachecon + holiday, so i have some catching up to  
do as well as looking at your last email about what the caching flag  
might break.


A simpler implementation might just be to introduce a 'StatefulTag'  
interface..

-pete

--
peter royal



smime.p7s
Description: S/MIME cryptographic signature

Re: [jelly] 1.0-final problem wrt tag caching

[peter royal]

On Jul 24, 2005, at 5:02 AM, Hans Gilde wrote:

So I'm looking at your test, and it looks like one should expect this
behavior (the test should always fail). Have you tried this test on a
pre-leak-fix version of Jelly? I'm going to do so tomorrow.


Yes. This test mimics a regression from an earlier RC that I ran into  
when upgrading Jelly in my application.


Previous behavior was for each call to TagScript.run() to use a new  
tag instance.


This isn't the same caching problem reported by other users. That  
problem is
caused not by repeated invocation of the same script, but by  
something that
is causing the same TagScript to be sued for two XML tags. This  
makes the

second instance use the variables from the first instance.


When we fixed the ThreadLocal memory leak, JellyContext.isCacheTags()  
was also removed. It is that function and the code in TagScript.run()  
that checks it that I restored.

-pete

--
peter royal



smime.p7s
Description: S/MIME cryptographic signature

Re: [jelly] 1.0-final problem wrt tag caching

[peter royal]

On Jul 22, 2005, at 1:34 AM, peter royal wrote:

I'll do what you did and spend some time tomorrow looking at the  
failures to see if we can have nirvana (no memory leak + exact  
behavior semantics from when we had the leak).




k, i was able to get all the tests in core to pass, including the new  
one I added about the tag caching. i'm offline so i can't test all  
the taglibs since i don't have everything needed in my maven repo,  
but i'm pretty sure they'll be okay too. i'll verify when i'm back  
online prior to committing.

-pete

--
peter royal




smime.p7s
Description: S/MIME cryptographic signature

Re: [jelly] 1.0-final problem wrt tag caching

[peter royal]

On Jul 21, 2005, at 8:40 PM, Paul Libbrecht wrote:

I've seen that mmmh so we should "just revert to not- 
caching" (by default) then test and change the ones that need  
caching, correct ?




potentially :)


Right, now, I "just did this" (it's just a few lines of code)  
and... well... I have, simply in core... the following tests failing:


TestChooseTag, TestForEachTag, TestInvokeStaticTag, TestInvokeTag,  
TestNewTag, TestSwitchTag, TestJelly


And they all succeed if I change JellyContext.cacheTags to true.
Moreover I remember that jelly:define was my major goal when making  
always caching...


Should I really commit that and then hunt individual failures with  
such a method as "TagScript.doCacheMe"?

Wouldn't a method "Tag.reset()" make more sense ?



No, don't commit yet.

I'll do what you did and spend some time tomorrow looking at the  
failures to see if we can have nirvana (no memory leak + exact  
behavior semantics from when we had the leak).

-pete

--
peter royal




smime.p7s
Description: S/MIME cryptographic signature

Re: [jelly] 1.0-final problem wrt tag caching

[peter royal]

On Jul 21, 2005, at 9:10 AM, Paul Libbrecht wrote:

I am sorry I wasn't able to take this further yet.
The idea was to introduce something like a reset() method on tags  
to ensure that nullity... but if you think we need to disable  
caching then we'll have to need a form of method like  
"doesNeedCaching" which would then cache in any cases. I know for  
example such things for Swing or Define tags (but not per-class).


I still think Cache.reset() is better and Kristofer accept it as an  
alternative. Would you ?


Since not caching tags was the default previously, I think we should  
revert to that (The difference between revisions 136360 and 136390 in  
svn).


It would be re-introducing JellyContext.isCacheTags(), but keeping  
the memory leak fix (iirc, that was only removed because we thought  
we could fix the memory leak by moving tag caching in the JellyContext?)


I just committed a unit test that illustrates the problem. Any  
solution that doesn't require modification of the unit test is fine  
with me (as I believe it represents the assumptions that Tag authors  
have made, and it would be very onerous to make all users validate  
their applications to determine where caching is *not* needed).

-pete

--
peter royal


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jelly] 1.0-final problem wrt tag caching

[peter royal]

On Jun 24, 2005, at 1:38 PM, Kristofer Eriksson wrote:
Secondly, to add to the above topic, I see the change in cache  
behavior

(since the patch?!?). When calling a Tag a second time attributes not
specified will have values previously set, as mentioned by Brett.

First call: 
Second call: 

The second time mytag is called, attr2 will still have the value  
"boo",

and not null or default value. My question is if this is the desired
behavior, if not, can this be fixed somehow.


I have confirmed this behavior and it is a regression in the way the  
memory leak patch is implemented. Trying to figure out how to fix it  
now :)

-pete

--
peter royal -> [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: BOF

[peter royal]

On Jul 19, 2005, at 9:55 AM, Torsten Curdt wrote:



Anyone interested in a jakarta commons
BOF at the ApacheCon?




yes, please set one up :)
-pete




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] SOLVED: Maven issue with Hans memory leak patch

[peter royal]

On May 1, 2005, at 9:09 AM, Brett Porter wrote:
I've solved this problem. One of the jelly tags was relying on a new
instance being created, but the instance is now being reused. Note  
that
the tag is the same call from the same script, so I assume that  
this is
valid, so I have made the tag not be stateful and it fixed the Maven
problem.

Does anyone know if this is correct behaviour?
Sounds correct to me :)
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: concurrency and starting a synchronized block

[peter royal]

On Feb 10, 2005, at 8:20 AM, Jörg Schaible wrote:
en get() twice:
Object o = map.get(key);
if (o == null) {
  synchronized(map) {
o = map.get(key);
if (o == null) {
  map.put(key,new Object());
}
  }
}
since 99% of the time it will not enter the block, the second lookup 
does not matter ...
Is that still enough to not be double-checked locking (which is broken 
in java..)

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all][VOTE] svn migration

[peter royal]

On Jan 23, 2005, at 7:24 AM, robert burrell donkin wrote:
so, for those who use IDEs who would suffer if we moved to subversion 
now, i have two questions:
i wouldn't say i would suffer, just that i wouldn't pull the trigger 
right now (but i'm not going to block forward progress)

would an extra month actually make any difference?
likely not. 6-8, perhaps.
if so, are there any volunteers who'd be willing to ensure that this 
month wasn't wasted by pushing forward development of their IDEs?
i pay for mine (IDEA).. and they're working on it. i believe someone 
said summertime would be about when it might be available.
-pete

smime.p7s
Description: S/MIME cryptographic signature

Re: [all][VOTE] svn migration

[peter royal]

On Jan 22, 2005, at 10:25 PM, Martin Cooper wrote:
If you're an IDE-only developer and you don't care about backing out
changes, merging, refactoring, or tagging and branching, then you
might have a point about a "winning proposition for the developer".
But once you've experienced SVN's atomic commits, remote moving,
renaming, tagging and branching, etc., you'll wonder how you ever
lived without it. ;-) Some of the stuff we've done with the Struts
repo, since we switched to SVN, we probably wouldn't have dreamed of
trying with only CVS.
I've done all of the above with CVS. And sure, it is less than ideal.  
But those generally aren't day-to-day operations.

Day-to-day the IDE is my view unto the code, and its ability to work 
seamlessly with the repository is key. Tool support will catch up for 
SVN, and that will be a glorious day!

cheers.
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all][VOTE] svn migration

[peter royal]

On Jan 22, 2005, at 1:31 PM, Tim O'Brien wrote:
Alright a sufficient amount of time has passed for public comments and
testing.
This is a vote thread for migrating commons to SVN.  If this vote
passes, I'll contact Justin and schedule the least disruptive migration
time possible.
-0
don't see it is a winning value proposition for the developer until 
tools catch up (specifically IDEA in my case and catching up is 
built-in support equivalent to CVS)
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] current context in thread-local ?

[peter royal]

On Dec 26, 2004, at 3:33 PM, Paul Libbrecht wrote:
In order to kill the evil caching bug, it looks like putting all 
script-to-tag storage in the JellyContext is the cleanest idea.
That means that TagScript.getTag() should become 
TagScript.getTag(JellyContext currentContext).
But now, the problem is that the method TagScript.getTag() should be 
either:
- suppressed but that's really a big change in the API, I'd just 
deprecate it
- pulling the context from such a static method as 
JellyContext.getCurrentJellyContext()
I'd go for the second if everyone agrees.
I'd like to fix the API. Lets avoid ThreadLocal usage if at all 
possible :)
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] Trying to understand ThreadLocal story

[peter royal]

On Dec 16, 2004, at 10:43 AM, Paul Libbrecht wrote:
Now... aren't we >just< missing a simple notion "run-session", passed 
between script-objects, where each TagScript could put it's tag ?
A simple hash-table where the key is the tag-script seems to satisfy 
requirements.
That run-session, in normal conditions, would be garbage collected at 
the end of the run(), at least.
Basically, yes. Rather than caching tags in the TagScript, we 
could/should cache them in a JellyContext. You could then discards the 
JellyContext to force the Tag's to be GC'd
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Jelly and a release

[peter royal]

On Oct 28, 2004, at 1:24 PM, Dion Gillard wrote:
We've covered most of the issues in Jira for Jelly to make a 1.0 
release.

I'd like to go ahead and make the current code a release candidate, 
1.0-RC1.

If anyone has changes or bugs that need to be addressed in 1.0,
*please* raise them now, so that we can decide to either include them
or wait.
So:
[X] +1. Release 1.0-RC1.
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jelly and a 1.0 release

[peter royal]

On Sep 19, 2004, at 8:33 PM, Hans Gilde wrote:
Yeah, no problem. No huge memory leak for 1.0. :)
yes please! :)
+1
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] Hans Gilde as a commons committer

[peter royal]

On Sep 8, 2004, at 2:47 AM, Dion Gillard wrote:
I hereby propose Hans Gilde as a Jakarta Commons committer.
He has been tirelessly working to get swing and xml issues fixed for
Jelly's upcoming release and would be a welcome addition to the team.
Here's my +1.
+1
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE-RESULT] Jakarta Commons Committer rights for Brett Porter

[peter royal]

Jakarta Commons has voted in favor of granting Brett Porter commit 
access.

Brett already has ASF commit access via the Maven project.
Projects to receive additional access to: jakarta-commons, 
jakarta-commons-sandbox

Vote Results:
-1: 0
+0: 1
+1: 11
Vote Thread:
http://marc.theaimsgroup.com/?t=10870959311&r=1&w=2
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jexl] A plan for a 1.0 release

[peter royal]

On Jun 4, 2004, at 10:55 AM, Tim O'Brien wrote:
Is there anyone out there with a release plan for JEXL 1.0?
If not, is there any object to the development of one?
Go for it!
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Change to Commons Charter

[peter royal]

On May 15, 2004, at 10:01 PM, Henri Yandell wrote:
On 'Removing Text':
[X] +1 Remove it
[ ] -1 Keep it
On 'Versioning the Charter':
[X] +1 Add a version
[ ] -1 No need to version things
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] Wishlist 1.0 (was RE: Release schedule for Jelly)

[peter royal]

On Feb 3, 2004, at 1:38 PM, Michael Lanzetta wrote:
I've got some free time.  I'm not a committer, but I'd certainly be 
willing
to help.  What areas should I concentrate on?
Whatever you want! Its open source, so no-one can force you to do 
anything :)

Manfred's list is a good start...
 * Documentation .. howto's and examples
 * Patches for bugs in JIRA
 * General JIRA cleanup to sort through the issues
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Wishlist 1.0 (was RE: Release schedule for Jelly)

[peter royal]

On Feb 3, 2004, at 11:39 AM, Manfred Riem wrote:
No you haven't been rude, I was just wondering when there will
be a official 1.0 release. I for one would like to have the
following things.
Are you volunteering? We'd love to have more assistance!
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Re: [jexl] - checking for unresolved variables

[peter royal]

On Jan 12, 2004, at 10:28 AM, Geir Magnusson Jr wrote:
2) A different approach, where the context is simple (allowing 
recycling w/o much effort of other backing impls) and Jexl is smart

Regarding #2, I can see 2 approaches.

One is to do it during evaluate(), like you proposed, which will 
change the state of some of the objects in the context, and not all if 
something is wrong :

   nuclearReactor.start(); nuclearReactor.setTemparature(temp); 
nuclearReactor.stop();

Granted, I know that you can't always ensure you get through, but 
still, adding another way causes concern.  On the flipside, it's 
simple

The other would be to have a checker  that takes an expression and 
figures out if it will go given a context.  That leads to a two step 
execution process, where you'd first run the check and then 
evaluate()

Comments?
an alternative approach..

lets leverage the map! the map knows if a variable exists. So how about 
JexlExpression.setExplicitVariableDeclaration( true ); and then Jexl 
just does (in ASTIdentifier, and I think that might be the only 
place..)

if( isExplicitVariableDeclaration )
{
final Map vars = jc.getVars();
 if( vars.doesKeyExist( val ) )
 {
 return vars.get( val );
 }
 else
 {
 throw new UnknownVariableException( val );
 }
}
else
{
return jc.getVars().get( val );
}
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Bugzilla Admin request

[peter royal]

On Jan 11, 2004, at 11:58 PM, Noel J. Bergman wrote:
Tim O'Brien wrote:

Could someone with access add a new component "configuration" under 
the
program "commons" in Bugzilla?
Would Jakarta Commons like to migrate into Jira?  We're in the process
(literally in the process) of bringing it live tonight.  Jelly is 
already in
there, and we can import from Bugzilla selectively.
I'd like to see jexl move over..
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Re: [jexl] - checking for unresolved variables

[peter royal]

On Jan 11, 2004, at 3:03 PM, Bill Horsman wrote:
Do you want me to resubmit the patch? BTW, my patch file didn't include
the new file I added. Is there anyway of including the new files too, 
or
do I just need to include them separately?
A new patch would be easiest :)

If you're working against an anon CVS checkout, -N to 'cvs diff' will 
include new files.
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Re: [jexl] - checking for unresolved variables

[peter royal]

On Jan 11, 2004, at 2:54 PM, Bill Horsman wrote:
On Sun, 2004-01-11 at 20:46, peter royal wrote:

So if implement the Map interface (or expose it) then you run the 
risk
of another class just calling get() instead of getVar() and bypassing
my
strict variable check.
Unless the new exception was a subclass of RuntimeException :)
Yep, that's true. Well, I can be persuaded either way. To extend Map or
just to use it. My gut instinct still says the composition is better.
Your gut is right, I just worry about the change to the client 
contract.. This would no longer be a "drop-in" upgrade. I'll ping Geir 
and get his opinion on this too..
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Re: [jexl] - checking for unresolved variables

[peter royal]

On Jan 10, 2004, at 2:21 PM, Bill Horsman wrote:
I've made some changes to allow for strict checking of unknown 
variables
inside an expression. Please see attached patch plus one new class
(UnknownVariableException). The changes were simple enough. The

  JexlHelper.createContext()

method is now overridden with a new

  JexlHelper.createContext(boolean strict)

method. The old one just calls the new one with strict = false. So the
default behaviour is unchanged.
Looks good. My only suggestion is that you likely want to check for 
existence of the key in the map in order to known when to throw the 
exception, as opposed to testing for null. That way you can have valid 
variables that are null.
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Re: [jexl] - checking for unresolved variables

[peter royal]

On Jan 10, 2004, at 5:56 PM, Bill Horsman wrote:
Do you mean the methods of the java.util.Map interface constrain the
implementation ?
That's not what I meant, but actually it does :) My getVar() method
throws an UnknownVariableException and in order to maintain that API I
would have to make the Map's get() method also throw that Exception.
Only you can't do that.
So if implement the Map interface (or expose it) then you run the risk
of another class just calling get() instead of getVar() and bypassing 
my
strict variable check.
Unless the new exception was a subclass of RuntimeException :)
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jexl] - checking for unresolved variables

[peter royal]

On Jan 9, 2004, at 4:34 PM, Bill Horsman wrote:
My first thoughts: add a method to Expression:

/**
 * Get a list of all the variables within this expression that
 * aren't known by the context
 * @param context contains variables we do know
 * @return a list of unknown variables (or a null if there are none).
 * Defining all these unknown variables does not guarantee that a
 * subsequent call to this method will produce no unknown variables.
 */
public String[] getUnknownVariables(JexlContext context);
The alternative to get the evaluate() method to throw a
UnknownVariablesException or something. But to do that, we have to
configure the Expression to know whether it should be lenient (the
current, default behaviour) or strict.
If we just want the first unknown variable, I think the implementation 
of that could be all in the JexlContext. Just have a JexlContext 
implementation that throws a runtime exception when an invalid variable 
is requested, as opposed to returning null.
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Jelly][RT] The purpose of the JellyContext

[peter royal]

On Dec 23, 2003, at 7:12 AM, Carsten Ziegeler wrote:
I just started to look at Jelly for using it as the main template
engine within Cocoon and was a little bit surprised by the
JellyContext class.
But first, Jelly is really great and provides exactly the
extensability I need.
yea! i'm heavily using it in cocoon and it rocks!

So, I think separating the concerns would make things easier.
What do you think of creating a "Parser" (whatever you call it),
that gets all the compileXX and runXX methods from the JellyContext
and leave only the context handling at the JellyContext.
I'd call it a 'ScriptLoader' or something, but I agree with the general 
idea. There are some bugs in the tracker that deal with relative URL's 
inside a script (using the import functionality) that could be solved 
while doing such a fix.

So we'd have:
  * JellyContext -> Context for the execution of a Script object 
(variable storage, resource loading, etc)
  * ScriptLoader -> Handles taglib registration and creation of Script 
objects (and immediate execution) from various sources ( URL, file, etc 
)

In addition, a compileXX/runXX method that can directly handle
an InputStream instead of a URL would be very great for Cocoon.
Or anything that is XMLizable (more useful for Cocoon, since you can 
hook an internal pipeline directly into a script). (I have one already, 
as well as a few other helper components, such as a compiled script 
cache, that you might find useful..)

If you're interested I can provide a patch.
patches welcome! :)
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Jelly] Anyone cares in patches?

[peter royal]

On Dec 8, 2003, at 6:50 AM, Paul Libbrecht wrote:
My current priorities for Jelly are as follows, unless something 
different is raised as essential:
-> documentation for users
-> documentation for "how-to-build"
	(including the memory issues and a better presentation
	of the non-downloadable-jars issue)
-> consideration of the many patches at Jira (and I fear also, some 
partially lost in Bugzilla)
-> consideration of the outstanding bugs...
-> enhancement of the build-system to be able, at least, to build 
without downloading the non-downloadable-jars

Opinions welcome.
yea!
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] New committer - Neil O'Toole

[peter royal]

[X] +1, Yes let him commit
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE-RESULT] Elect Paul Libbrecht as a Jakarta Commons Committer

[peter royal]

Jakarta Commons has voted in favor of granting Paul Libbrecht commit 
access.

Email: Paul Libbrecht <[EMAIL PROTECTED]>
Suggested userid: plibbrecht
Projects to receive access: jakarta-commons, jakarta-commons-sandbox
Vote results:
-1: none
0: none
+1:
__matthewHawthorne <[EMAIL PROTECTED]>
robert burrell donkin <[EMAIL PROTECTED]>
Henri Yandell <[EMAIL PROTECTED]>
Tim O'Brien <[EMAIL PROTECTED]>
Juozas Baliuka <[EMAIL PROTECTED]>
Mark R. Diggory <[EMAIL PROTECTED]>
peter royal <[EMAIL PROTECTED]>
an letter has also been sent to Paul following the template at 
<http://jakarta.apache.org/site/roles.html>
-peter royal

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Elect Paul Libbrecht as a Jakarta Commons Committer

[peter royal]

Paul Libbrecht <[EMAIL PROTECTED]> has been contributing to Jelly in 
the form of patches and valued support on the user list for over a year 
now. I think its about time that he be gifted with the ability to take 
his involvement to the next level.

+1 from me.

-pete

---
Vote: Elect Paul Libbrecht as a Jakarta Commons Committer
[ ] +1 Yes let him commit!
[ ] +0
[ ] -0
[ ] -1 No way (because of my reason included below...)
---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Jelly] invokeBody with nested tags?

[peter royal]

On Nov 2, 2003, at 9:21 AM, Vincent Massol wrote:
Does invokeBody only works with text? Can it work with nested tags too?
How can I achieve the above?
From what I know, it *should* work. invokeBody invokes nested tags when 
called from tags defined in java, i don't see why it should be 
different for jelly-based tags. if you work up a testcase and stick it 
in jira, that'll increase chances of other eyes looking at it :)
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Jelly] Moving some bugs around

[Peter Royal]

On Thursday, September 4, 2003, at 02:01  PM, Morgan Delagrange wrote:
Does it make sense to have distinct "core" and
"taglib.core" buckets, or should they be combined?
They are somewhat independent, but still part of the
same distribution.
I say combine them..
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jexl] dotted property names in expressions

[Peter Royal]

On Monday, August 18, 2003, at 04:42  PM, Ryan Hoegg wrote:
There is a problem with jexl when testing dotted property names for 
emptiness.  I am using it from jelly through maven:

maven -Ddotted.property.name=foo goal

inside the goal:


  Empty property 




 Empty little property 

I just added a unit test to the CVS version of jexl, I think it 
exercises this ( and works fine )
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Issue tracking (was Re: DO NOT REPLY [Bug 20787] - Jelly project.xml specifies dependencies that are not in Ibiblio repository)

[Peter Royal]

On Wednesday, September 3, 2003, at 08:38  PM, bob mcwhirter wrote:
Someone should probalby shut down the jelly bugzilla, since
I believe folks are using Jira for all of the jellybugs...
yup, i'm just trying to clear out the issues (2 maybe 3 left).. most 
people are good about using JIRA :)

thing is, how to go about closing it?
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] Is the CVS committer gone?

[Peter Royal]

On Thursday, August 28, 2003, at 01:55  AM, [EMAIL PROTECTED] wrote:
Bill, a list of bugs is one thing, but what we really need to do is
schedule them into a release.
See
http://jira.codehaus.org/secure/ 
BrowseProject.jspa?id=10012&report=roadmap
for what I started on.
If anyone wants to help prune Jelly's JIRA, just holler and I'll give  
you permissions to help create a release schedule.
-pete "with the usual excuse.. not enough hours in the day.."

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Sandbox Karma for Leo Sutic

[Peter Royal]

On Tuesday, August 19, 2003, at 04:22  PM, Noel J. Bergman wrote:
Leo Sutic is an active Avalon Committer, and has Jakarta Karma by 
virtue of
Avalon having been incubated in Jakarta.  He wishes to contribute to
Attributes in the sandbox.
+1
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] patch for the jelly shell script

[Peter Royal]

On Monday, August 11, 2003, at 08:28  AM, Jakob Praher wrote:
attached you find a patch to an extended version of the jelly script.
for instance it does symlink replacement, so that you can link the 
jelly
script conveniently in your local/bin directory. the script also fixes
some bugs like the forehead.jar reference, which is
forehead-$VERSION.jar not forehead.jar, etc.
Thanks for the contribution. Could you create an issue in our 
bugtracker, 
 and 
attached the patch there so it doesn't get lost? Thanks!!
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] Jelly needs a release Was: jelly demos don't compile even with the jars

[Peter Royal]

On Friday, August 8, 2003, at 04:27  AM, [EMAIL PROTECTED] wrote:
I'm +1.
Me too. In fact, I have volunteered to help move it through that 
process, I'm just juggling half a dozen things at the moment.

My goal was to get it to a 1.0 status, but doing another beta in the 
near-term might be better/easier.
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] moving to a release.

[Peter Royal]

On Sunday, August 10, 2003, at 08:53  PM, [EMAIL PROTECTED] wrote:
This allowed us to do some release planning, and gave everyone a long  
list
of things to look at to help, to move forward and to get things done.

I'm happy to help do this, what do others think?

Here's jelly's current roadmap:
http://jira.codehaus.org/secure/ 
BrowseProject.jspa?id=10012&report=roadmap

Here's maven's:
http://jira.codehaus.org/secure/ 
BrowseProject.jspa?id=10030&report=roadmap

here's my vote to say we schedule the bugs: +1.
+1

To that end, I've created 1.0-beta-4 and 1.0 versions in Jira that can  
be used to track.
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] patch for a core tag

[Peter Royal]

On Thursday, July 31, 2003, at 01:12  PM, Robert McIntosh wrote:
great! Should I resubmit this via jira or has it already been taken 
care of?
please resubmit, as i've been applying patches in a group on the 
weekends recently, and thats the best way to make sure it doesn't get 
dropped :)
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [JELLY][PATCH] Focus and Key Listeners added

[Peter Royal]

On Wednesday, July 23, 2003, at 05:19  PM, Sean W. Ferguson wrote:
This is my first ever attempt at a patch.  If I am doing wrong, please 
advise.

The purpose of this patch is to include new functionality in the jelly 
swing tag library.  I added a FocusListenerTag and a KeyListenerTag 
and modified ComponentTag and SwingTagLibrary.  In my zip are these 
four files plus the patchfile.txt
Can you create an issue in our issuetracker, 
 just to 
make sure this doesn't get lost in the shuffle?

thanks!
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-commons/jexl/src/java/org/apache/commons/jexl/parser ASTUnaryMinusNode.java ASTMethod.java Parser.java Parser.jj ParserTreeConstants.java ParserVisitor.java

[Peter Royal]

On Wednesday, June 25, 2003, at 07:17  AM, [EMAIL PROTECTED] wrote:
  +++ ASTMethod.java25 Jun 2003 11:17:00 -  1.4
  @@ -1,5 +1,7 @@
   package org.apache.commons.jexl.parser;
  +{
  +System.out.println("ASTMethod : "+ e);
  +e.printStackTrace();;
Why not just throw the exception and let the application display it as 
appropriate?
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-commons/jexl/src/java/org/apache/commons/jexl/parser ASTSubtractNode.java

[Peter Royal]

On Wednesday, June 25, 2003, at 06:49  AM, [EMAIL PROTECTED] wrote:
geirm   2003/06/25 03:49:48

  Modified:jexl/src/java/org/apache/commons/jexl/parser
ASTSubtractNode.java
  Log:
  Mark Wilkinson's patch (hack!) to the sub node - we really need to 
fix
  this another way - prollie in the introspector

  +/*
  + *  TODO - this is actually wrong - JSTL says to return a 
Long
  + *  but we have problems where you have something like
  + *
  + * foo.bar( a - b )
  + *
  + *  where bar wants an int...
  + *
  + */
A "proper" way to fix this would be to do coercion when passing 
arguments to method calls, right?
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly/jexl] any outstanding patches?

[Peter Royal]

On Friday, June 20, 2003, at 02:50  PM, robert burrell donkin wrote:
good to have you aboard the commons team.

just FYI there's an ettiquette page on the wiki 
(http://nagoya.apache.org/
wiki/apachewiki.cgi?JakartaCommonsEtiquette) just in case some of our 
habits seem a little strange. please remember to add your name to the 
status file of the components you make commits to. this helps to keep 
track of who's responsible (and so  has a binding vote) for each 
component.

(i guess that i should create a page with this one so that i don't 
have to keep repeating myself to every new committer...)
No problem, thanks for the welcome :)
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly/jexl] any outstanding patches?

[peter royal]

On Friday, June 20, 2003, at 12:10  PM, bob mcwhirter wrote:
On Fri, 20 Jun 2003, Peter Royal wrote:

If anyone has any outstanding patches for jelly or jexl, can you 
please
place them in bugzilla? I'll go through them all in the next week and
apply ones that are appropriate.
Jira?

http://jira.codehaus.org/secure/BrowseProject.jspa?id=10012
ah, yes. jira :)
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jelly/jexl] any outstanding patches?

[Peter Royal]

If anyone has any outstanding patches for jelly or jexl, can you please 
place them in bugzilla? I'll go through them all in the next week and 
apply ones that are appropriate.
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Jelly] What resources must be present for compiling?

[Peter Royal]

On Thursday, June 19, 2003, at 11:10  AM, Jason van Zyl wrote:
If you are compiling a bit of Jelly to a Script what resources must be
present to simply compile. This bit of Jelly may have various 
references
to classes that must be loaded and my question is must these resources
be present for the compile and if so which ClassLoader is used? Or will
the resources be searched for only when Script is run against a
JellyContext?
How/where are those references to classes? It is my understanding that 
to compile into a Script, the engine just needs to be able to resolve 
all of the tags. So if your references are only used when tags are 
evaluated, they shouldn't be needed at script compilation time..
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jelly] Is anyone maintaining it?

[Peter Royal]

I know there are users, but it anyone maintaining it? Anyone interested 
in applying outstanding patches and pushing for a release? I'm willing 
to help, I just have no commit rights :)
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jexl][patch] JSTL-compliant parameter coercion for LT/GT/LE/GE

[Peter Royal]

On Thursday, June 12, 2003, at 03:24  PM, Peter Royal wrote:
On Thursday, June 12, 2003, at 03:13  PM, Peter Royal wrote:
The attached patch implements JSTL-compliant parameter coercion when 
dealing with LT/GT/LE/GE expressions.
hrm, didn't come through before. Lets try as .diff vs .patch
Must not like attachments. Bugzilla it is then.
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jexl][patch] JSTL-compliant parameter coercion for LT/GT/LE/GE

[Peter Royal]

On Thursday, June 12, 2003, at 03:13  PM, Peter Royal wrote:
The attached patch implements JSTL-compliant parameter coercion when 
dealing with LT/GT/LE/GE expressions.
hrm, didn't come through before. Lets try as .diff vs .patch
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jexl][patch] Rethrow exceptions in method execution

[Peter Royal]

Current ASTMethod just prints any methods during method execution to 
the console. This is undesirable in unattended server processes unless 
someone is always monitoring STDERR.

The attached patch causes the thrown exception to flow out of jexl, and 
the calling program can deal with it accordingly.

The patch also modifies UberspectImpl to remove a containing 
InvocationTargetException.
-pete


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jexl][patch] JSTL-compliant parameter coercion for LT/GT/LE/GE

[Peter Royal]

The attached patch implements JSTL-compliant parameter coercion when 
dealing with LT/GT/LE/GE expressions.
-pete


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jelly][patch] More descriptive exception on failure to create Jexl expression

[Peter Royal]

If you have an invalid expression, such as 'variable.length = 0', Jexl 
just comes back with 'Invalid expression'.. Makes it kinda hard to 
locate the problem in your script :)

The attached patch just puts the expression text into the wrapped 
exception from Jexl.
-pete


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jelly][PATCH] FAQ for my-variable is zero question

[Peter Royal]

I've run into this, and I just saw a post on a random mailing list 
about this, so I figured it was a good FAQ candidate.

Answers "why is my-variable zero" when jexl interprets the expression 
as my (minus) variable.
-pete

--
peter royal -> [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Time for more mailing lists ?

[Peter Royal]

On Tuesday, January 28, 2003, at 10:39  AM, Costin Manolache wrote:

This has been discussed in the past - but the traffic on commons is
getting bigger as we add more very active components.

We could split the list based on category - expression languages 
(jxpath,
jexl, jsp-el, etc ), util libraries ( logging, discovery, modeler,
collections, etc ).

Opinions ? Should we vote ?

Traffic would not be as bad if cvs commit messages were not on this 
list. How about a separate list for cvs commits? (all modules)
-pete


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JEX wants to play in the sandbox - license issue

[Peter Royal]

On Wednesday 12 June 2002 09:35 am, Dmitri Plotnikov wrote:
> Before I drop it in the sandbox, I want to make sure it is ok that JEX
> depends on Rhino, which is under a license that is a combination of
> GPL, LGPL and MPL.  I read the parts of that license I could understand
> and it appears to be ok to include JS.jar wholesale without infecting
> Apache with GPL, but I am not a lawyer, so I cannot be absolutely sure.
>
> Could somebody clarify this license issue, please.

Cocoon (another apache project) also includes rhino.jar. I believe it was 
present the last time jars were audited.

IANAL tho :)
-pete

-- 
peter royal -> [EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>