Re: Heads up on potential move for Taglibs
Seems reasonable. Any idea what happens to commit rights? On Sun, Jul 12, 2009 at 1:30 AM, Henri Yandell flame...@gmail.com wrote: Jakarta is a slowly dwindling project at Apache. A long time ago we agreed that its deep structure created isolated sub communities and Apache decided to become a flat organization. Thus for all projects in Jakarta there is the question of where to go. I've been floating the idea to Jakarta and Tomcat of moving the active parts of Taglibs over to Tomcat. This idea seems to be getting +1s on all sides. The general idea is: * Move Standard, JSTL implementation, over to Tomcat. 1.0 would be deprecated. * Move RDC over to Tomcat. * Start a new taglib (my new favourite name is Extended; ie: Apache Extended Taglib to complement the Apache Standard Taglib) that is built from the undeprecated parts of Taglibs that find favour. Some might be refactored from Taglibs to EL functions. Think the Commons Lang of Taglibs. * Other taglibs to be retired within Jakarta and make their way over to the Apache Attic. Hen -- Kris Schneider mailto:k...@directthought.com directThought http://www.directThought.com/
Re: Heads up on potential move for Taglibs
OK, sounds good. Let me know if you need an official +1 from me sent somewhere. On Mon, Jul 13, 2009 at 11:08 AM, Henri Yandell flame...@gmail.com wrote: Expecting that they'd be maintained for those who are committing. So Rahul, myself and you if you're interested. Hen On Mon, Jul 13, 2009 at 6:36 AM, Kris Schneiderk...@directthought.com wrote: Seems reasonable. Any idea what happens to commit rights? On Sun, Jul 12, 2009 at 1:30 AM, Henri Yandell flame...@gmail.com wrote: Jakarta is a slowly dwindling project at Apache. A long time ago we agreed that its deep structure created isolated sub communities and Apache decided to become a flat organization. Thus for all projects in Jakarta there is the question of where to go. I've been floating the idea to Jakarta and Tomcat of moving the active parts of Taglibs over to Tomcat. This idea seems to be getting +1s on all sides. The general idea is: * Move Standard, JSTL implementation, over to Tomcat. 1.0 would be deprecated. * Move RDC over to Tomcat. * Start a new taglib (my new favourite name is Extended; ie: Apache Extended Taglib to complement the Apache Standard Taglib) that is built from the undeprecated parts of Taglibs that find favour. Some might be refactored from Taglibs to EL functions. Think the Commons Lang of Taglibs. * Other taglibs to be retired within Jakarta and make their way over to the Apache Attic. Hen -- Kris Schneider mailto:k...@directthought.com directThought http://www.directThought.com/ - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org -- Kris Schneider mailto:k...@directthought.com directThought http://www.directThought.com/
Re: Slowly x:forEach/x:out tags
On Mon, Oct 27, 2008 at 12:44 PM, emerson cargnin [EMAIL PROTECTED] wrote: So there is no plans to fix this is future versions? I'd have to say, no, there doesn't seem to be a plan to fix this in Standard 1.1. We have quite a few number of x:forEach/x:out on our JSPs. I believe our managers wouldn't be willing to refactor all the pages to switch that for xslt, which I'd believe would be overkill. Understood. Is there someone in charge of the x taglibs? I suppose that would be Jakarta committers with an interest in the Standard taglib. I happen to be one of those, but I'm not actively working on it at the moment. It seems like this is really one of the worst areas of the implementation, but it's hard to gauge how much pain it's actually causing (besides yours, of course). There's not much traffic on the Jakarta taglibs lists and I have no idea if this ever comes up on other lists/forums. Personally, I'd love to be able to fix it, but I just can't promise to be able to make the time to do it. Maybe... regards Emerson 2008/10/22 Kris Schneider [EMAIL PROTECTED]: I don't believe there's an impending fix for Standard 1.1.x, although the bug report (https://issues.apache.org/bugzilla/show_bug.cgi?id=27717) does contain some potential approaches. One of the things I mentioned in the first comment of the bug report is to try using XSLT as an alternative: http://www.mail-archive.com/[EMAIL PROTECTED]/msg06341.html On Tue, Oct 21, 2008 at 2:09 PM, emerson cargnin [EMAIL PROTECTED] wrote: I'm using tomcat 5.5.26 and JDK 1.5. After we upgraded standard and jstl version to 1.1.2, the pages started to take more than 30 seconds to render. In this discussion: http://marc.info/?l=taglibs-devm=119820558711402w=2 they have the same problem, the context is the same and they end up finding that the problem is on the implementation of x:forEach and x:out. We reverted to 1.0.6 versions of those jars, but this is a temporary fix, as we want to be able to use features from the new especifications. Reverting fixed the problem. Does anyone know if there is a plan to fix this libraries? Or should I ask this somewhere else? Then please just tell me. regards Emerson -- Kris Schneider mailto:[EMAIL PROTECTED] directThought http://www.directThought.com/ -- Kris Schneider mailto:[EMAIL PROTECTED] directThought http://www.directThought.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slowly x:forEach/x:out tags
On Mon, Oct 27, 2008 at 4:19 PM, Henri Yandell [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 11:48 AM, Kris Schneider [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 12:44 PM, emerson cargnin [EMAIL PROTECTED] wrote: So there is no plans to fix this is future versions? I'd have to say, no, there doesn't seem to be a plan to fix this in Standard 1.1. We have quite a few number of x:forEach/x:out on our JSPs. I believe our managers wouldn't be willing to refactor all the pages to switch that for xslt, which I'd believe would be overkill. Understood. Is there someone in charge of the x taglibs? I suppose that would be Jakarta committers with an interest in the Standard taglib. I happen to be one of those, but I'm not actively working on it at the moment. It seems like this is really one of the worst areas of the implementation, but it's hard to gauge how much pain it's actually causing (besides yours, of course). There's not much traffic on the Jakarta taglibs lists and I have no idea if this ever comes up on other lists/forums. Personally, I'd love to be able to fix it, but I just can't promise to be able to make the time to do it. Maybe... It's the ugliest bug in the taglibs. I spent some time on it last year, but couldn't identify a solution as I was knee deep in copied Xerces (or was it Xalan?) internals. Yup, pretty much exactly where I was at with: https://issues.apache.org/bugzilla/show_bug.cgi?id=27717#c1 (wow, that was 4.5 years ago!) Haven't had the time, or nerve ;-), to go back...yet... I'm pretty sure I dumped it into an email here a while back, but one of the things I thought would be worth investigating is to use JAXP 1.3 (https://jaxp.dev.java.net/) and integrate with the javax.xml.xpath API instead of Xerces/Xalan. I'm pretty sure JAXP 1.3 got backported to Java 1.3, but I'm not sure if the same thing happened with JAXP 1.4. Hen -- Kris Schneider mailto:[EMAIL PROTECTED] directThought http://www.directThought.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slowly x:forEach/x:out tags
I don't believe there's an impending fix for Standard 1.1.x, although the bug report (https://issues.apache.org/bugzilla/show_bug.cgi?id=27717) does contain some potential approaches. One of the things I mentioned in the first comment of the bug report is to try using XSLT as an alternative: http://www.mail-archive.com/[EMAIL PROTECTED]/msg06341.html On Tue, Oct 21, 2008 at 2:09 PM, emerson cargnin [EMAIL PROTECTED] wrote: I'm using tomcat 5.5.26 and JDK 1.5. After we upgraded standard and jstl version to 1.1.2, the pages started to take more than 30 seconds to render. In this discussion: http://marc.info/?l=taglibs-devm=119820558711402w=2 they have the same problem, the context is the same and they end up finding that the problem is on the implementation of x:forEach and x:out. We reverted to 1.0.6 versions of those jars, but this is a temporary fix, as we want to be able to use features from the new especifications. Reverting fixed the problem. Does anyone know if there is a plan to fix this libraries? Or should I ask this somewhere else? Then please just tell me. regards Emerson -- Kris Schneider mailto:[EMAIL PROTECTED] directThought http://www.directThought.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reg:£ symbol
On 11/26/07, Chandragiri, Srinivas [EMAIL PROTECTED] wrote: Hi Iam facing problem while displaying £ symbol Instead of £ symbol ,iam getting £ response.setContentType(text/html; charset=iso-8859-1); is not working in my machine That looks like servlet code - are you generating your HTML with a servlet or a JSP? This type of question should really be posted to the taglibs-user list...assuming it has anything to do with taglibs...or even JSP... ;-) Thanks and Regards Srinivas Chandragiri Analyst Programmer Syntel Ltd. Pride Silicon Plaza, Pune- India Mobile +91 9960601018 Email [EMAIL PROTECTED] www.syntelinc.com -- Kris Schneider mailto:[EMAIL PROTECTED] directThought http://www.directThought.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [standard] More bugs to resolve - thoughts?
On 9/28/07, Henri Yandell [EMAIL PROTECTED] wrote: On 8/24/07, Kris Schneider [EMAIL PROTECTED] wrote: On 8/24/07, Henri Yandell [EMAIL PROTECTED] wrote: I've been churning on with my patch to add a caching SPI to Standard. Here's the state, and what I think we should do: 17700 - Ostensibly this is a complaint that there is no caching in the i18n stuff. When you dig deeper, it doesn't make sense as the poster is complaining that the Resources class that handles errors for Standard is the one that needs caching, and he refers to ResourceMessages which does not exist. Too confusing, so WONTFIX. 31789 - Memory leak in ELEvaluator. This is the big issue - EL bits are never GC'd it seems and it grows and grows until things OOM. This is because caching is done. I've not tested this, though all I'm adding is the ability to plug your own cache in, or choose between forever caching or no caching. It's open source. If someone feels this problem strongly enough, it's not hard to go in and change it so it uses a LRUCache or something. So WONTFIX. At one point, there was a fairly healthy discussion about this: http://marc.info/?t=10982070521 Unfortunately, it seemed to just die rather abruptly. Since we're focusing on JSTL 1.1, I'd want to go back and review the code to see what's what. Based on my schedule, I won't be able to do that for another week. At the very least, I think we should expose ELEvaluator.mBypassCache via configuration and then actually honor it if it's set to false. I believe the current code skips the cache lookup when it's false but still caches the evaluation results - that seems like a bug (except that the code comments seem to imply that was the desired behavior). What do you think to the latest commit Kris? Is Justyna's unreleased 1.0.x fix good enough for us to use for 1.1.3? I think it was mentioned elsewhere, but it might be worthwhile to pull in the latest collections code instead of just using what was checked-in for 1.0.x (if that's what happened). Otherwise it seems fine. The only thing that nags at me is the potential for this to be a concurrency bottleneck. As with the old solution, the cache is wrapped with Collections.synchronizedMap which means that get/put share the same lock. I'm not aware of an LRU cache based on the JSR 166 (util-concurrent) backport, but something like that would probably be better. At worst, this isn't any different from the old solution... Now that I've got concurrency on the brain, I'm not sure whether the new solution is actually thread-safe: Should setBypassCache be synchronized? Hm, that's actually a new method, right? Previously, sCachedExpressionStrings was created upfront and mBypassCache was forced to be a constructor arg... Hen -- Kris Schneider mailto:[EMAIL PROTECTED] directThought http://www.directThought.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [standard] More bugs to resolve - thoughts?
On 8/24/07, Henri Yandell [EMAIL PROTECTED] wrote: I've been churning on with my patch to add a caching SPI to Standard. Here's the state, and what I think we should do: 17700 - Ostensibly this is a complaint that there is no caching in the i18n stuff. When you dig deeper, it doesn't make sense as the poster is complaining that the Resources class that handles errors for Standard is the one that needs caching, and he refers to ResourceMessages which does not exist. Too confusing, so WONTFIX. 31789 - Memory leak in ELEvaluator. This is the big issue - EL bits are never GC'd it seems and it grows and grows until things OOM. This is because caching is done. I've not tested this, though all I'm adding is the ability to plug your own cache in, or choose between forever caching or no caching. It's open source. If someone feels this problem strongly enough, it's not hard to go in and change it so it uses a LRUCache or something. So WONTFIX. At one point, there was a fairly healthy discussion about this: http://marc.info/?t=10982070521 Unfortunately, it seemed to just die rather abruptly. Since we're focusing on JSTL 1.1, I'd want to go back and review the code to see what's what. Based on my schedule, I won't be able to do that for another week. At the very least, I think we should expose ELEvaluator.mBypassCache via configuration and then actually honor it if it's set to false. I believe the current code skips the cache lookup when it's false but still caches the evaluation results - that seems like a bug (except that the code comments seem to imply that was the desired behavior). 32311 - No Date caching. I can get 30% speed improvements here with caching. I'm not convinced it's worth it. So WONTFIX. All a bit of a shame, as I've a large patch with nothing hugely wrong with it :) But I've no urge to do non-surgical things. Any thoughts? Any +1s on closing these 3 issues? Hen -- Kris Schneider mailto:[EMAIL PROTECTED] directThought http://www.directThought.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [unstandard] Picking through the datetime taglib
On 7/23/07, Henri Yandell [EMAIL PROTECTED] wrote:
Here are the tags in the DateTime taglib:
* currentTimeGets the current time in milliseconds since Jan 1, 1970 GMT.
* formatFormats a date in milliseconds since Jan 1, 1970 GMT for
output as a date string.
* parse Parses a date string and outputs the time in milliseconds
since Jan 1, 1970 GMT.
* timeZone Create a time zone script variable for use with the parse
or format tags.
* timeZones Loop through all time zones.
* monthsLoop through the months of the year.
* weekdays Loop through the days of the week.
* amPms Loop through the am/pm names.
* eras Loop through the era names.
-
Of the first batch; format and parse are taken of care of in JSTL with
fmt:formatDate and fmt:parseDate. The currentTime tag is effectively
handled by doing:
jsp:useBean id=now class=java.util.Date /
I'm never sure whether it's better to educate people in doing such
things, or if there should be a:
un:currentTime var=now/
Probably it's best to just push towards useBean. Also, the timeZone
attribute to the two fmt: tags can take a String as well as an Object,
so presumably that makes that one redundant.
jsp:useBean has it's share of semantic quirks so it's not always
going to be a useful alternative. It looks like Unstandard already
includes ClassUtils.createInstance(String), and if it was exposed as
an EL function, you could do something like:
c:set var=currentTime value=${un:createInstance('java.util.Date')}/
So the question becomes whether there is any value in the iterator
style tags. I don't see a lot. Any thoughts? I'm tempted to think
'deprecate' for datetime and bring nothing into Unstandard.
If I had to recreate the iterator functionality in one of my own apps,
I think I'd be tempted to leverage EL functions instead of tags.
Simply create a set of static utility methods to generate the
collections and then use JSTL iteration. Regardless of how the
functionality is implemented (tags or functions), the bigger question
is whether or not it ought to be in Unstandard. I've never needed
something like it myself, but as Rahul points out, I can see where it
might come in handy.
Hen
--
Kris Schneider mailto:[EMAIL PROTECTED]
directThought http://www.directThought.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [unstandard] Picking through the datetime taglib
On 7/24/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 7/24/07, Kris Schneider [EMAIL PROTECTED] wrote: On 7/23/07, Henri Yandell [EMAIL PROTECTED] wrote: Here are the tags in the DateTime taglib: snip/ So the question becomes whether there is any value in the iterator style tags. I don't see a lot. Any thoughts? I'm tempted to think 'deprecate' for datetime and bring nothing into Unstandard. If I had to recreate the iterator functionality in one of my own apps, I think I'd be tempted to leverage EL functions instead of tags. Simply create a set of static utility methods to generate the collections and then use JSTL iteration. Regardless of how the functionality is implemented (tags or functions), the bigger question is whether or not it ought to be in Unstandard. snap/ Correct, and I punted on that. What is the (new) scope of Unstandard? Something more constrained than anything thats somewhat useful but not in JSTL? Here's the old and tired scope: The Unstandard Tag Library is a collection of tags and features which users have requested of the Jakarta Standard Tag Library. It is not really tied to the Standard Taglib or JSTL but is instead just somewhere to speed the availability of ideas before JSTL responds to user demand. I'm of the opinion that's just fine for the new hotness scope. I'm just not sure how to quantify the users have requested part. I can certainly recall people wanting field (constant) and method access, but other than that... -Rahul I've never needed something like it myself, but as Rahul points out, I can see where it might come in handy. Hen -- Kris Schneider mailto:[EMAIL PROTECTED] directThought http://www.directThought.com/ -- Kris Schneider mailto:[EMAIL PROTECTED] directThought http://www.directThought.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [standard] 1.1.3 release work
Just got back from vacation. I'll catch up and see where I can help... On 7/22/07, Henri Yandell [EMAIL PROTECTED] wrote: There are 8 open bugs atm for this release. http://wiki.apache.org/jakarta-taglibs/Standard_1%2e1%2e3 * 41221 is a task to update the source headers. We'll do that right at the end. * 17700, 32311, 31789 are all handled by my caching improvement - but I know that the improvement needs more work to be fully functional. I was testing it further on a machine that's currently out of action, and I had fixed NullPointers there etc. I need to get moving on that again. * 27717 (slow x:foreach) definitely needs fixing but hasn't been investigated for a while. Need a volunteer to dig into this. * 25623 (non releasing forEach) needs discussion. Does anyone have any opinions on whether we shouldn't WONTFIX this? Martin/Paul - this one mentions Struts. * 33934 (leak in c:set) needs discussion/resolving. Kris, you had thoughts here, is it one you could take on and resolve? * 31084 (mysql formatting issue) needs investigating. Anyone want to volunteer on this one? So that's it. We're really close to a release :) Hen -- Kris Schneider mailto:[EMAIL PROTECTED] directThought http://www.directThought.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)
Henri Yandell wrote: On 5/21/07, Karl von Randow [EMAIL PROTECTED] wrote: Henri Yandell wrote: Four 'volunteers' so far: Martin, Rahul, Kris, myself. me too Oops - mental slip. I meant Karl rather than Kris. Kris, you up for any of this? Absolutely. I think someone else mentioned looking at Unstandard for opportunities to provide EL functions instead of just tags. I've got a handful of functions that I've been carting around to the various projects I've been working on and I think they're generic enough to be useful. Oh, I'm also up for just focusing on JSP 2.0 - I think Unstandard is currently focused on JSP 1.2 (it does its own EL eval). One other thing - someone else had talked about compiling against various JDK version, but we have a commitment to meet the requirements of whatever spec version we're targeting. For example, I think JSP 2.0 still supports JDK 1.3.1, so, IMHO, that's what we need to compile against and distribute...at a minimum. Not very sexy, but there it is. Of course, there's nothing stopping us from providing alternate version compiled against 1.4.2, 1.5.0, etc. Although, that's one of the reasons to provide source code... Hen -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Taglibs future
Henri Yandell wrote: The Taglibs project has been dead for years. I'm sure it's not going to improve; taglibs are a pain to implement (especially if support is targeting older JSP specs), JSTL replaced many and at the same time JSP stopped being the obvious choice for web applications. It's frustrating to both users and committers to have the project sitting with doors apparently open, so I'd like to suggest a closing up of shop. Using a similar argument - app servers are a pain to implement and Java stopped being the obvious choice for web applications - one could argue that Tomcat should pack it in. Obviously, I disagree that those are valid reasons for taking action. I'm also at a loss as to what having the doors apparently open implies. I can't recall many (any?) user questions posted to the list going unanswered. A few of the answers might amount to, Yup, looks like a bug, but that taglib isn't currently under development, but they're still answers ;-). For me, the biggest difference between Taglibs and a project like Tomcat is simply the community. That's the focus of Apache, right? So, the only justifiable reason for closing up shop would be the loss of community (dev and/or user). Unfortunately, that's a difficult argument to refute for Taglibs and I agree that the situation is unlikely to improve. My guess is that Tomcat and Geronimo are probably serving the community needs of the users. I'm not sure I understand exactly what you're suggesting from a big-picture perspective. Do you think that the entire Taglibs project should go away or do you think that it should remain but only support three taglibs: Standard 1.1, Unstandard and RDC? Here's what I'm thinking: 1) Standard Taglib 1.1.3 release. This is getting pretty close, so it would be very nice to get a release out. Sure. I'm happy to do some more work on it. 2) RDC Taglib needs to continue. It's not had a lot of activity recently, but I'm presuming that Rahul is still active on this one and that it would need to continue. My suggestion is that it joins Jakarta Commons (either at jakarta.apache.org/commons or commons.apache.org if Commons moves there). Its build system could be brought up to date too. Can't really speak to that, but Rahul's already responded. I couldn't locate it, but I thought there was supposed to be some sort of generic Web Components project. Ring a bell for anyone else? 3) Others would be end of lifed - with a request going out to find out which ones are strongly active. I would still like to coalesce many into the sandbox'd Unstandard Taglib, ie) a single taglib with various bits of value that JSTL did not replace (and making it JSP 2.0 or 2.1 specific); so I am interested in hearing which functionalities are valuable. Kicking a useful Unstandard release out the door would be great. I'd be happy to work on that as well. Since Standard 1.1 is a JSP 2.0 taglib, it seems like it would make sense to target that as well. Target date for all of this would be the end of this year. Hen -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion of Bug 33934
Henri Yandell wrote: Not great feedback I'm afraid - the suggestion of fixing things in doEndTag sounds fine to me (null or ), but I'm not deep into the spec. If it's not an attribute of the tag, and it'll get recreated anew in doStartTag I don't see any reason to avoid GC having a chance. At least it's something ;-). I'd thought about trying to track down the right place to post some questions to the current JSTL (1.2) implementors (Glassfish? jstl-spec-public and/or jsp-spec-public on java.net? or?), but haven't bothered yet. I'll probably just go ahead with the fix by doing two things: Have org.apache.taglibs.standard.tag.common.core.SetSupport implement TryCatchFinally. Based on my reading of the JLS, this should maintain binary compatibility. In the doFinally method, set the target field to . Just to be clear on what should happen, it won't get recreated anew in doStartTag. For a request-time value, the container should always call setTarget before calling doStartTag/doEndTag. For a literal value, doEndTag always throws an exception, so there's no need to worry about persisting the value. Same for the c:forEach, though I've no great itch to hunt down other cases. I haven't looked at forEach yet... Hen On 3/27/07, Kris Schneider [EMAIL PROTECTED] wrote: On further reflection, perhaps target should be set to instead of null to maintain exception consistency... Kris Schneider wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=33934 After some thought, here's why I think we can actually set the target property to null in doEndTag (or doFinally, if we add it) instead of release. If a request-time value is used (scriptlet expression or EL), then the spec requires that the container must reset the property's value between all reuses. In other words, setTarget should be called each time the tag is (re)used. If a literal value is used, then the container is not required to reset the property's value. First, there's type conversion to deal with. However, since the property's type is Object, a new String instance will be used. In turn, this will cause doEndTag to throw an exception because String does not expose any writable Bean properties. So, AFAICT, the only way to get a valid value for target is with a request-time value. Feedback? P.S. This is in the context of JSP 2.0 and JSTL 1.1. It may still hold true for JSP 1.2 and JSTL 1.0, even for different reasons ;-), but I haven't thought much about it... -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion of Bug 33934
Kris Schneider wrote: Henri Yandell wrote: Not great feedback I'm afraid - the suggestion of fixing things in doEndTag sounds fine to me (null or ), but I'm not deep into the spec. If it's not an attribute of the tag, and it'll get recreated anew in doStartTag I don't see any reason to avoid GC having a chance. At least it's something ;-). I'd thought about trying to track down the right place to post some questions to the current JSTL (1.2) implementors (Glassfish? jstl-spec-public and/or jsp-spec-public on java.net? or?), but haven't bothered yet. I'll probably just go ahead with the fix by doing two things: Have org.apache.taglibs.standard.tag.common.core.SetSupport implement TryCatchFinally. Based on my reading of the JLS, this should maintain binary compatibility. In the doFinally method, set the target field to . Sigh. That's not really legal either. If it's not a String, then setting it to null might work. The problem is that in between doStartTag and doEndTag/doFinally, user code is allowed to call getTarget and it needs to return the proper value - even if it eventually causes doEndTag to throw an exception. Obviously, I'll cogitate some more... Just to be clear on what should happen, it won't get recreated anew in doStartTag. For a request-time value, the container should always call setTarget before calling doStartTag/doEndTag. For a literal value, doEndTag always throws an exception, so there's no need to worry about persisting the value. Same for the c:forEach, though I've no great itch to hunt down other cases. I haven't looked at forEach yet... Hen On 3/27/07, Kris Schneider [EMAIL PROTECTED] wrote: On further reflection, perhaps target should be set to instead of null to maintain exception consistency... Kris Schneider wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=33934 After some thought, here's why I think we can actually set the target property to null in doEndTag (or doFinally, if we add it) instead of release. If a request-time value is used (scriptlet expression or EL), then the spec requires that the container must reset the property's value between all reuses. In other words, setTarget should be called each time the tag is (re)used. If a literal value is used, then the container is not required to reset the property's value. First, there's type conversion to deal with. However, since the property's type is Object, a new String instance will be used. In turn, this will cause doEndTag to throw an exception because String does not expose any writable Bean properties. So, AFAICT, the only way to get a valid value for target is with a request-time value. Feedback? P.S. This is in the context of JSP 2.0 and JSTL 1.1. It may still hold true for JSP 1.2 and JSTL 1.0, even for different reasons ;-), but I haven't thought much about it... -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion of Bug 33934
Kris Schneider wrote: Kris Schneider wrote: Henri Yandell wrote: Not great feedback I'm afraid - the suggestion of fixing things in doEndTag sounds fine to me (null or ), but I'm not deep into the spec. If it's not an attribute of the tag, and it'll get recreated anew in doStartTag I don't see any reason to avoid GC having a chance. At least it's something ;-). I'd thought about trying to track down the right place to post some questions to the current JSTL (1.2) implementors (Glassfish? jstl-spec-public and/or jsp-spec-public on java.net? or?), but haven't bothered yet. I'll probably just go ahead with the fix by doing two things: Have org.apache.taglibs.standard.tag.common.core.SetSupport implement TryCatchFinally. Based on my reading of the JLS, this should maintain binary compatibility. In the doFinally method, set the target field to . Sigh. That's not really legal either. If it's not a String, then setting it to null might work. The problem is that in between doStartTag and doEndTag/doFinally, user code is allowed to call getTarget and it needs to return the proper value - even if it eventually causes doEndTag to throw an exception. Obviously, I'll cogitate some more... :-/ Of course, there is no such method as getTarget on either SetSupport or SetTag... Just to be clear on what should happen, it won't get recreated anew in doStartTag. For a request-time value, the container should always call setTarget before calling doStartTag/doEndTag. For a literal value, doEndTag always throws an exception, so there's no need to worry about persisting the value. Same for the c:forEach, though I've no great itch to hunt down other cases. I haven't looked at forEach yet... Hen On 3/27/07, Kris Schneider [EMAIL PROTECTED] wrote: On further reflection, perhaps target should be set to instead of null to maintain exception consistency... Kris Schneider wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=33934 After some thought, here's why I think we can actually set the target property to null in doEndTag (or doFinally, if we add it) instead of release. If a request-time value is used (scriptlet expression or EL), then the spec requires that the container must reset the property's value between all reuses. In other words, setTarget should be called each time the tag is (re)used. If a literal value is used, then the container is not required to reset the property's value. First, there's type conversion to deal with. However, since the property's type is Object, a new String instance will be used. In turn, this will cause doEndTag to throw an exception because String does not expose any writable Bean properties. So, AFAICT, the only way to get a valid value for target is with a request-time value. Feedback? P.S. This is in the context of JSP 2.0 and JSTL 1.1. It may still hold true for JSP 1.2 and JSTL 1.0, even for different reasons ;-), but I haven't thought much about it... -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Discussion of Bug 33934
http://issues.apache.org/bugzilla/show_bug.cgi?id=33934 After some thought, here's why I think we can actually set the target property to null in doEndTag (or doFinally, if we add it) instead of release. If a request-time value is used (scriptlet expression or EL), then the spec requires that the container must reset the property's value between all reuses. In other words, setTarget should be called each time the tag is (re)used. If a literal value is used, then the container is not required to reset the property's value. First, there's type conversion to deal with. However, since the property's type is Object, a new String instance will be used. In turn, this will cause doEndTag to throw an exception because String does not expose any writable Bean properties. So, AFAICT, the only way to get a valid value for target is with a request-time value. Feedback? P.S. This is in the context of JSP 2.0 and JSTL 1.1. It may still hold true for JSP 1.2 and JSTL 1.0, even for different reasons ;-), but I haven't thought much about it... -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion of Bug 33934
On further reflection, perhaps target should be set to instead of null to maintain exception consistency... Kris Schneider wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=33934 After some thought, here's why I think we can actually set the target property to null in doEndTag (or doFinally, if we add it) instead of release. If a request-time value is used (scriptlet expression or EL), then the spec requires that the container must reset the property's value between all reuses. In other words, setTarget should be called each time the tag is (re)used. If a literal value is used, then the container is not required to reset the property's value. First, there's type conversion to deal with. However, since the property's type is Object, a new String instance will be used. In turn, this will cause doEndTag to throw an exception because String does not expose any writable Bean properties. So, AFAICT, the only way to get a valid value for target is with a request-time value. Feedback? P.S. This is in the context of JSP 2.0 and JSTL 1.1. It may still hold true for JSP 1.2 and JSTL 1.0, even for different reasons ;-), but I haven't thought much about it... -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17388] - Result set created in query tag is never released + update tag
Henri Yandell wrote: I put together a Derby test bit for a different issue that I ended up WONTFIXing. I could add this in so you can make a test for this issue? If you think that'll work, sure. I haven't given the test too much thought yet ;-). I should probably go back and make similar changes in UpdateTagSupport. I know it already takes care of closing the PreparedStatement, but there can still be some exception hiding. I'm also not sure why Throwable is being caught in those two tags... Hen On 1/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=17388. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=17388 --- Additional Comments From [EMAIL PROTECTED] 2007-01-29 11:04 --- Just a quick note that I checked-in a fix last week (r499150): http://svn.apache.org/viewvc/jakarta/taglibs/proper/standard/trunk/src/org/apache/taglibs/standard/tag/common/sql/QueryTagSupport.java?view=diffrev=499150r1=499149r2=499150 I guess I won't close this until it can be tested properly... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going beyond the spec?
Henri Yandell wrote: On 12/13/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 12/13/06, Henri Yandell [EMAIL PROTECTED] wrote: We've a few issues that are asking for things not in the spec. In some cases the spec clearly states not to do that, so I've WONTFIX'd. However in others this is something that is undefined by the spec. For example: https://issues.apache.org/bugzilla/show_bug.cgi?id=34315 [which I've WONTFIXd, but we could reopen] and https://issues.apache.org/bugzilla/show_bug.cgi?id=39431 Seems like now is a good time to decide what the next release will be. As far as I understand, this is where the RI was developed, but the RI itself sits over at Sun. The 1.2 RI is a fork of this code sitting in Glassfish. Whatever 1.1.x we release now wouldn't be an RI release (??). snip/ We should eradicate any references alluding to being an RI in any subsequent releases, IMO. Martin suggests differently. I suspect we'll need to talk to the EG to figure out what is going to happen when we do the next release. Unless something has changed, this is still the home of the RI for JSTL 1.0 and 1.1. JSTL 1.2 is another story - and one I haven't really been following all that closely. Two things jump to mind as questions: 1) Will the EG be redistributing the release from java.sun as the official RI? I'm pretty sure Sun used to just bundle it within the WSDP: http://java.sun.com/webservices/downloads/1.6/index.html In fact, it was bundled as a Nonredistributable Component: http://java.sun.com/webservices/docs/1.6/ReleaseNotes.html 2) Is there a TCK we need to run to claim that we are a JSTL implementation? That's a good question. This implies that there might be: http://jcp.org/aboutJava/communityprocess/mrel/jsr052/index.html That said - do we want to be allowing things that differ from the spec? Changing the tld by allowing optional user/passwd bits (as per 34315) seems unlikely. However having a system property of jakarta.taglibs.standard.apos.escape=true seems doable (for 39431). snap/ No, IMO. Opens the door for but you allowed foo, so why not bar kind of logic, which gets subjective and extremely hard to put a cap on. OTOH, why would anyone use the Jakarta Taglibs releases instead of the RI? One reason that is often compeling (in the generic RI vs. other impl arguments) is the availability of non-standard, but highly useful features and add-ons. This is where a niche could be carved (ofcourse, needs dev resources, since see above para). Amicable licensing could be another advantage. Amicable licensing is likely to be the main reason if we ever do a JSTL 1.2. The 1.2 spec doesn't seem much changed from the 1.1 spec so it wouldn't be impossible. Glassfish is still licensed under CDDL (dual with GPL), so as long as we don't need to modify it and re-ship it (in Tomcat, Geronimo etc) then we don't have any driving need for an AL 2.0 licensed version. I have to admit I'm a bit curious about the JSTL 1.2 code in GlassFish. I'm pretty sure it was seeded with the code from Standard 1.1, but at some point the license was just switched to CDDL. Is that kosher? There is still an org.apache package structure in the source tree: https://glassfish.dev.java.net/source/browse/glassfish/appserv-jstl/src/org/apache/ Apart from making sure bugs are fixed, I don't think it's likely we'd want to get into the add-ons niche. Sounds like we've quite the consensus so far on this question. No New Features!. I'll continue to punt such enhancements over to Glassfish and the EG; depending on their fix we could then consider the fix here. Just a note that there are differences between spec features and implementation features. For example, we could completely replace the XPath engine (again) if there were compelling reasons to do so. Hen -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [standard] Thoughts on currently open bugs
Henri Yandell wrote: Spent a while going through the current open bugs in Jakarta Standard. Here are my thoughts: http://people.apache.org/~bayard/jstl.html On a related note, I always have to dig to find the minimum J2SE requirements when going back and looking at this stuff, so I thought I'd document it here: We need to support J2SE 1.3. On page xix of the JSP 2.0 Spec is the following: The JSP 2.0 specification requires the Java 2 Platform, Standard Edition version 1.3 or later for standalone containers, and version 1.4 for containers that are part of a Java 2 Enterprise Edition 1.4 environment. All JSP containers must be able to run in a J2SE 1.4 environment. It's from the Relation To JSP 1.2 section. Additionally, if anyone's planning on doing cross-compilation, be sure to understand these: http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/javac.html#crosscomp-options http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/javac.html#crosscomp-example I've seen quite a few suggestions that all you need to do is use -target. It ain't so! Hen -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working on Standard taglib 1.1 bugfixes
Henri Yandell wrote: A couple of us at my workplace would like to work on resolving some of the bugs open for the Standard taglib. Ccing the Expert Group for their opinions too as they were pretty much the developers of the code here. Some questions: 1) Which is more valuable, 1.1.x bugfixes or 1.0.x ones? My assumption has been to work on the 1.1.x ones. I'd say it's whichever is the most important to the community, although that may be difficult to determine based solely on the participation on the taglib mail list. It might be worthwhile posting a poll to the Tomcat users and/or a java.net/java.sun.com forum for feedback. 2) [Experts] Are the bugs fixed elsewhere? ie) the Sun RI or Glassfish? Should people even be using the Jakarta taglib or are the Sun versions of 1.0.x and 1.1.x more maintained (ignoring license issues)? I could be wrong, but I don't think there was ever a separate Sun version of 1.0/1.1. 3) Anyone else interested? I keep meaning to clean some of this stuff up, so maybe having someone else working on it will add some motivation. Hen [I work at SourceLabs; it's in our interest to get bugs fixed so my boss has okay'd a couple of us spending a day a week on it] -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cache] standard dependency
Rahul Akolkar wrote: Why do we have the standard binary in the cache taglib repo [1]? Anyone mind if we remove it? I assume it's merely a convenience for building and install. It's been there since the initial Subversion rev in April 2002 (although I'm sure it existed back in the CVS days as well). I recently updated it to v1.0.6 as part of some work I'm doing in support of Bug 39612 [1]. Moving cache to a 2.0 base will eliminate its dependency on standard. In any case, IMO, its next release should be as a 2.0 taglib. Having a JSP 2.0-based release at some point is fine, but here's what I was planning: Finish cleanup and release v1.0.1. Concurrency/synchronization issues for Bug 39612 [1] not addressed. Perhaps fix Bug 18198 [2]. Create a dependency on J2SE 1.4.2 and release v1.1. Fix concurrency/synchronization issues for Bug 39612 [1]. Fix Bug 18198 [2] if it didn't make it into v1.0.1. The dependency on J2SE 1.4.2 is to make it possible to use java.util.LinkedHashMap to replace the need for a custom LRU cache and to make it possible to use the backport of JSR 166 (java.util.concurrent) [3]. I don't see any community push for a JSP 2.0-based implementation. Of course, there's not much of a community push for anything theses days. Is it that the taglib community is really subsumed by Tomcat or the java.sun.com/java.net forums? On the other hand, the main driver for changes to the Cache taglib is Bug 39612 [1] which states that the environment includes JBoss 4.x.x. JBoss 4.0 is a J2EE 1.4 app server, which implies JSP 2.0. I've sent an email to the bug submitter to see if a JSP 2.0-based solution is workable. If so, then I'm all for just doing that instead of my staged plan... -Rahul [1] http://svn.apache.org/repos/asf/jakarta/taglibs/proper/cache/trunk/lib/ [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=39612 [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=18198 [3] http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cache] standard dependency
Rahul Akolkar wrote: On 5/26/06, Kris Schneider [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: Why do we have the standard binary in the cache taglib repo [1]? Anyone mind if we remove it? I assume it's merely a convenience for building and install. It's been there since the initial Subversion rev in April 2002 (although I'm sure it existed back in the CVS days as well). I recently updated it to v1.0.6 as part of some work I'm doing in support of Bug 39612 [1]. snip/ Yes, the update is what got my attention to it. I'll remove it when am back from the long weekend trip. I can take care of it while I'm working on other stuff since it will likely change some parts of the build process. Moving cache to a 2.0 base will eliminate its dependency on standard. In any case, IMO, its next release should be as a 2.0 taglib. Having a JSP 2.0-based release at some point is fine, but here's what I was planning: Finish cleanup and release v1.0.1. Concurrency/synchronization issues for Bug 39612 [1] not addressed. Perhaps fix Bug 18198 [2]. Create a dependency on J2SE 1.4.2 and release v1.1. Fix concurrency/synchronization issues for Bug 39612 [1]. Fix Bug 18198 [2] if it didn't make it into v1.0.1. The dependency on J2SE 1.4.2 is to make it possible to use java.util.LinkedHashMap to replace the need for a custom LRU cache and to make it possible to use the backport of JSR 166 (java.util.concurrent) [3]. snap/ Sure, an interim bugfix release makes sense. Though I'm not sure about two. Moving to JSP 2.0 takes care of the JDK 1.4 upgrade, so if it were upto me, I'd fold those two in (its awkward to require a JDK version higher than the base for the J2EE version in use, and such a situation is best avoided, IMO). I don't see any community push for a JSP 2.0-based implementation. Of course, there's not much of a community push for anything theses days. Is it that the taglib community is really subsumed by Tomcat or the java.sun.com/java.net forums? snip/ We have a lot more options (at the technology level) now. Speaking for myself, I moved to 2.0 long time ago -- I have no interest in 1.1 taglibs, and little interest in 1.2. I think we should encourage moves towards 2.0 (and new tag libraries to possibly require 2.0), especially since all containers (that I use) have 2.0 support at this time and are gearing up for 2.1 support with unified EL, so 1.2 will soon be a couple of versions old. It will be a sign that we're moving forward, as a community. So, atleast I'm pushing ;-) I understand, but it doesn't make much sense to fix someone's bug and make it inaccessible to them at the same time. Since the bug submitter is running JBoss 4, which requires J2SE 1.4 as a J2EE 1.4 app server, I can collapse my two releases into one that also requires J2SE 1.4. If the bug submitter is fine with JSP 2.0, then I'll make those changes as well. On the other hand, the main driver for changes to the Cache taglib is Bug 39612 [1] which states that the environment includes JBoss 4.x.x. JBoss 4.0 is a J2EE 1.4 app server, which implies JSP 2.0. I've sent an email to the bug submitter to see if a JSP 2.0-based solution is workable. If so, then I'm all for just doing that instead of my staged plan... snap/ Cool, and thanks for the recent fixes. -Rahul -Rahul [1] http://svn.apache.org/repos/asf/jakarta/taglibs/proper/cache/trunk/lib/ [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=39612 [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=18198 [3] http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [moved] Sun JSTL Standard versus Jakarta JSTL Standard
Rahul Akolkar wrote: [moved to dev list from user list] On 5/2/06, Kris Schneider [EMAIL PROTECTED] wrote: Not sure if this is exactly what you're after, but you have to keep in mind that JSTL is a specification. In order to actually make use of it, you need an implementation. That's where the Standard taglib comes in - it's an implementation of the JSTL spec. Standard 1.0 implements JSTL 1.0 and Standard 1.1 implements JSTL 1.1. snip/ Or maybe Sébastien is refering to the Glassfish one? In any case, thoughts from anyone whether we (Jakarta Taglibs) should be recommending the Glassfish equivalent hereafter? That depends on whether someone needs a Java EE 5 app server and JSTL 1.2. Personally, I'm still releasing production apps that need to run on Tomcat 4.1 and WLS 8.1 with a 1.4.2 JDK. I guess I hadn't realized that JSTL is actually part of the Java EE 5 spec: All Java EE products are required to provide JSTL for use by all JSP pages. I haven't really been following Glassfish all that much, but I downloaded the 9.0-b42 installer (Milestone 6) and, after installing, ran: java -cp glassfish\lib\appserv-jstl.jar org.apache.taglibs.standard.Version Which produced: standard-taglib 1.1.2 So, I guess I'm not really sure what the state of JSTL 1.2 development is at this point. -Rahul Sébastien Brodeur wrote: What is the difference between the Sun version of standard JSTL and the Jakarta one? -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Deprecate Redundant Taglibs
+1 for all Rahul Akolkar wrote: This has been discussed before, but its time for some book-keeping. I would like to call a VOTE for declaring the following Taglibs as deprecated. The reasons, in each case, are (probably in the order of importance): 1) Much of the functionality provided by these Taglibs is now available via JSTL 2) There are no immediate plans (that I am aware of) for any dev activity for these Taglibs projects 3) There has been little dev activity for these Taglibs projects over the last year For the votes that pass, the respective Taglibs will be listed as deprecated on the Taglibs website. Ofcourse, the versioned releases will continue to be available, but there will be no nightlies (Glenn has already removed these from the nightlies last week). VOTE (A) - Application Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) VOTE (B) - DBTags Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) VOTE (C) - Page Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) VOTE (D) - Request Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) VOTE (E) - Response Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) VOTE (F) - Session Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) I'm +1 to deprecating all six. Not to take anything away from the utility they provided in their heyday. -Rahul -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki update notifications
It was part of the original request for the wiki, but apparently never got set up. I just sent a request to infra to have it fixed... Rahul Akolkar wrote: We don't get wiki update notifications as listed here [ http://wiki.apache.org/jakarta-taglibs/ ]. Who can help us? Kris? Thanks! -Rahul -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat jsp taglib/compilation/cache issue
(This is probably a more appropriate discussion for the taglibs-user list) What are the new versions of Tomcat and JSP that aren't working? What were the old versions? Which version of JSP is your taglib developed for? To make sure your tag handler behaves properly in the face of tag pooling, you may want to try the following: Locate $CATALINA_HOME/conf/web.xml Find the servlet element for jsp. Add an init-param to disable tag pooling: init-param param-nameenablePooling/param-name param-valuefalse/param-value /init-param If the handler behaves differently, then it probably has lifecycle issues, otherwise it might just be a logic bug. Of course, it's difficult to tell without seeing code... Quoting Sacha Stanton [EMAIL PROTECTED]: Hi, I have a tomcat taglib problem. If it's not something obvious, I would appreciate if anyone could give me a hand fixing it - hopefully I am not out of line on this newsgroup, but the server is in production and I am all out of ideas so I am happy to negotatiate a rate if it takes some time to solve. Here's an outline of the problem: 1) Tomcat/apache setup with a JSP form 2) custom taglib that handles form submissions 3) upon submit and correct field validation, the user is sent to a different page. Otherwise the same page comes back with error messages. This was all working on the old server, so either the new version of tomcat is a problem, or the setup is somehow wrong. I have the info from the previous setup. Here's the problem: Once the jsp page is edited or touched, and tomcat compiles the page, the following happens: 1) If the user correctly fills out the form, they get redirected correctly to the next page (this can be repeated over and over) 2) once any user fills out the form incorrectly and they get the same page with please complete the form correctly, any future submissions (whether valid or not) get the same page with the same please complete the form correctly message. This happens until the page is edited or touched, after which all correct submissions work until someone puts in bad data and then it keeps looping. It seems like some kind of global variable or caching issue to me, but I am not expert with taglibs and tomcat so I need some help! If anyone thinks you might be able to solve it, send me a note to discuss. Thanks, -Sacha -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Missing binary downloads
I'm not really sure what the release history is for those taglibs. I just assumed that they'd never officially reached a 1.0 version and have pointed people at http://cvs.apache.org/builds/jakarta-taglibs/nightly/projects/ for downloading nightlies. Quoting Henri Yandell [EMAIL PROTECTED]: Additionally (to the source email), there seem to be a bunch of taglibs that just have empty directories for their binary downloads: BSF Cache I18N Input IO JMStags JNDI Scrape Ultradev4 Utility (deprecated) XTags Is this a known problem? Did we lose them somehow in the move to mirroring a year or so back? Hen -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer: Dhiru Pandey
+1 Quoting Pierre Delisle [EMAIL PROTECTED]: Committers, I would like to nominate Dhiru Pandey as a new committer for jakarta-taglibs. Dhiru is a fellow Sun employee who is now co-leading with me both JSR-52 (JSTL) and JSR-267 (JSP Tag Library for Web Services). Dhiru has submitted quite a few patches recently for JSTL and is also committed to cleanup the rest of the JSTL bugs (yeah!). Here is my +1 for Dhiru. Thanks, -- Pierre -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leak in ELEvaluator (cont'd...)
Or just use the setAccessible hack:
elcache.jsp:
%@ page import=java.io.* %
%@ page import=java.lang.reflect.* %
%@ page import=java.util.* %
%@ page import=org.apache.taglibs.standard.lang.jstl.* %
%@ taglib prefix=c uri=http://java.sun.com/jstl/core; %
%
String genPath = pageContext.getServletContext().getRealPath(/generated.jsp);
PrintStream ps = null;
try {
ps = new PrintStream(new BufferedOutputStream(new
FileOutputStream(genPath, false), 4096));
ps.println(% + @ taglib prefix=\c\
uri=\http://java.sun.com/jstl/core\; %\);
ps.println(htmlhead);
ps.println(meta http-equiv=\refresh\ content=\3;
URL=elcache.jsp\);
ps.println(titleGenerated/title);
ps.println(/headbodyul);
long time = System.currentTimeMillis();
for (int i = 0; i 100; i++) {
long value = time + i;
String var = v_ + value;
ps.print(li);
ps.print(c:set var=' + var + ' value='${ + value + }'/);
ps.print(c:out value='${pageScope. + var + }'/);
ps.println(/li);
}
ps.println(/ul/body/html);
} catch (FileNotFoundException exc) {
exc.printStackTrace();
} finally {
if (ps != null) {
ps.close();
}
}
Field cachedExpressionStringsField =
ELEvaluator.class.getDeclaredField(sCachedExpressionStrings);
cachedExpressionStringsField.setAccessible(true);
Map cachedExpressionStrings =
(Map)cachedExpressionStringsField.get(ELEvaluator.class);
%
html
head
meta http-equiv=refresh content=3; URL=generated.jsp
titleEL Cache Test/title
/head
body
pNumber cached expr strings: %= cachedExpressionStrings.size()
%/p
/body
/html
It should increase by 200 each time elcache.jsp is accessed. The reason for
the non-zero refresh is that a newly generated.jsp only seemed to be
recognized for every request by introducing a slight delay. I ran TC
4.1.31's Jasper in dev mode so it would check for mods on every request as
well as setting it not to fork compiles. Of course, JSP compilation could
still be performed in a background thread within the same JVM, which might
explain why the delay was required...
Daryl Beattie wrote:
Yeah, that's basically it! Dunno why I never thought of using a
scriptlet instead of writing a custom tag... It's probably because
scriptlets are so frowned-upon where I currently work that I hardly ever
consider using them.
One thing I did in one of my tests was actually to print out the size of
the cache in the JSP. So as my JSP refreshed every second, I could watch
the size of the cache climb. This, of course, requires a change to
ELEvaluator.java so that the size of the cache is publicly visible --
perhaps by adding a getCacheSize() method.
Although I don't like to have my test JSPs actually display their own
results, the problem with this kind of test is that it can't be easily
converted to a unit test; it's results are somewhat subjective.
Because of that, I found that adding the cache size to the JSP eased my
results.
By adding this to ELEvaluator.java:
public static int getELCacheSize() {
return ELEvaluator.sCachedExpressionStrings.size();
}
You can then change the body of the JSP to:
body
pEL Cache Test/p
pEL Cache Size: %=ELEvaluator.getELCacheSize()%/p
/body
Then you just load the JSP and watch it climb; if it climbs
indefinitely, you've got a bug in the cache. If it climbs to a fixed
size and stops there's no bug. ...And I would personally put the refresh
delay down to 0 just so that the cache is filled up faster... cuz I'm
impatient. :)
- Daryl Beattie
-Original Message-
From: Kris Schneider [mailto:[EMAIL PROTECTED]
Sent: Friday, February 25, 2005 1:57 PM
To: Tag Libraries Developers List
Subject: Re: Memory Leak in ELEvaluator (cont'd...)
Here's an approach to dynamically generating unique
expressions that might work as a test.
elcache.jsp:
%@ page import=java.io.* %
%@ taglib prefix=c uri=http://java.sun.com/jstl/core; %
%
String genPath =
pageContext.getServletContext().getRealPath(/generated.jsp);
PrintStream ps = null;
try {
ps = new PrintStream(new BufferedOutputStream(new
FileOutputStream(genPath, false), 4096));
ps.println(% + @ taglib prefix=\c\
uri=\http://java.sun.com/jstl/core\; %\);
ps.println(htmlhead);
ps.println(meta http-equiv=\refresh\ content=\3;
URL=elcache.jsp\);
ps.println(titleGenerated/title);
ps.println(/headbodyul);
long time = System.currentTimeMillis();
for (int i = 0; i 100; i++) {
long value = time + i;
String var = v_ + value;
ps.print(li);
ps.print(c:set var=' + var + ' value='${ + value
+ }'/);
ps.print(c:out value='${pageScope. + var + }'/);
ps.println(/li);
}
ps.println(/ul/body/html);
} catch (FileNotFoundException exc) {
exc.printStackTrace();
} finally {
if (ps != null) {
ps.close();
}
}
%
html
head
meta http-equiv=refresh content=3; URL=generated.jsp
titleEL Cache Test
Re: Memory Leak in ELEvaluator (cont'd...)
Here's an approach to dynamically generating unique expressions that might work
as a test.
elcache.jsp:
%@ page import=java.io.* %
%@ taglib prefix=c uri=http://java.sun.com/jstl/core; %
%
String genPath = pageContext.getServletContext().getRealPath(/generated.jsp);
PrintStream ps = null;
try {
ps = new PrintStream(new BufferedOutputStream(new FileOutputStream(genPath,
false), 4096));
ps.println(% + @ taglib prefix=\c\
uri=\http://java.sun.com/jstl/core\; %\);
ps.println(htmlhead);
ps.println(meta http-equiv=\refresh\ content=\3; URL=elcache.jsp\);
ps.println(titleGenerated/title);
ps.println(/headbodyul);
long time = System.currentTimeMillis();
for (int i = 0; i 100; i++) {
long value = time + i;
String var = v_ + value;
ps.print(li);
ps.print(c:set var=' + var + ' value='${ + value + }'/);
ps.print(c:out value='${pageScope. + var + }'/);
ps.println(/li);
}
ps.println(/ul/body/html);
} catch (FileNotFoundException exc) {
exc.printStackTrace();
} finally {
if (ps != null) {
ps.close();
}
}
%
html
head
meta http-equiv=refresh content=3; URL=generated.jsp
titleEL Cache Test/title
/head
body
pEL Cache Test/p
/body
/html
If you drop this into TC's $CATALINA_HOME/webapps/ROOT and add the JSTL libs to
$CATALINA_HOME/webapps/ROOT/WEB-INF/lib, it should do what you want. I tested
this with TC 4.1.31 and Standard 1.0.6, but didn't do any sort of profiling. If
you don't see the output from generated.jsp change for each request, try
increasing the refresh interval.
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: session cookies and standard.tag.el.core.UrlTag
Quoting Stefán Baxter [EMAIL PROTECTED]: Hi, Testing the tag with browser having different cookie settings reviles that it correctly embeds sessionid in URLs even the first time something that the other method will not do and that is the reason for my interest. If some is familiar with what controls this behavior then please clarify. Are you saying you see a difference between these two: request.encodeURL: %= response.encodeURL(/) % c:url: c:url value=// There shouldn't be. The only difference is as I stated, c:url performs an initial check to see if the URL is absolute. If it's not absolute, it uses encodeURL. Can you provide some code that illustrates what you're observing? Best regards, -Stefan Kris Schneider wrote: Quoting Stefán Baxter [EMAIL PROTECTED]: Hi, I'm new to JSTL and currently trying to adapt a project that I'm working on to it. Am I right in assuming that standard.tag.el.core.UrlTag relies on it's own/JSTL functions to determine if sessionid needs to be embedded in theURL. I see different behavior between it and HttpServletResponse.encodeURL(). Can someone please explain where the tag is gettings it's logic from? According to the spec, c:url will not rewrite/encode an absolute URL. About the only thing this amounts to in the actual code is a check for the presence of the : character. If it's *not* there, then the URL will be rewritten/encoded with HttpServletResponse.encodeURL. Best regards, -Stefan -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03)
Instead of patching back to Jaxen/SAXPath, it might have been better to investigate Xalan's CachedXPathAPI as outlined in my comment for this bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=27717 The things I'm unsure of are whether or not it's safe to cache the information at the risk of missing changes to the underlying document and how we should manually manage the cache. Most of that uncertainty is just not being all that familiar with those corners of the code... Wim Goossens wrote: Wim Goossens schreef: Chris, Kris, Pierre, Do you know anything about a fix for this problem ? I also submitted a bug report, probably at the wrong place, in february. No solution so far. http://developer.java.sun.com/developer/bugParade/bugs/4993200.html Regards, Wim -Oorspronkelijk bericht- Van: Johnson, Chris [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 16 maart 2004 18:29 Aan: Tag Libraries Users List Onderwerp: RE: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03) Thanks for all of the help so far. I submitted bug 27717. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 10:58 AM To: Tag Libraries Users List Subject: Re: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03) Yes, as Kris mentioned, please file a bug report with proper test cases. We'll have a look into it. -- Pierre Kris Schneider wrote: You're posting to the right place to make people aware of the problem. To formalize the issue, a bug report should probably get submitted: http://issues.apache.org/bugzilla/enter_bug.cgi?product=Taglibs As part of the report, it would be helpful to include a simplified test case (XML and JSP files) that reproduces the problem. If you have any questions about the bug submission process just let me (us) know. At this point, the problem seems to be either the way JSTL is using Xalan or Xalan itself. Quoting Johnson, Chris [EMAIL PROTECTED]: That gets rid of the xalan file search, but the performance is still awful. For now I guess I'll try to look into xslt, but this looks like a bug that needs to be fixed or something. Who else needs to know about this to get it either fixed, or to tell me what else I might be doing wrong (if anything). Here's more of what truss is spitting out if that helps: lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_mutex_lock(0x0002E7E0) = 0 lwp_mutex_unlock(0x0002E7E0)= 0 lwp_mutex_lock(0x0002E710) = 0 lwp_cond_wait(0x0002E728, 0x0002E710, 0x) = 0 lwp_cond_broadcast(0x0002E728) = 0 lwp_mutex_unlock(0x0002E778)= 0 lwp_mutex_lock(0x0002E778) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x) = 0 lwp_mutex_unlock(0x0002E848)= 0 lwp_mutex_lock(0x0002E848) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x) = 0 lwp_mutex_unlock(0x0002E848)= 0 lwp_mutex_lock(0x0002E848) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_mutex_lock(0x0002E7E0) = 0 lwp_mutex_unlock(0x0002E7E0)= 0 lwp_mutex_lock(0x0002E710) = 0 lwp_cond_wait(0x0002E728, 0x0002E710, 0x) = 0 lwp_cond_broadcast(0x0002E728) = 0 lwp_mutex_unlock(0x0002E778)= 0 lwp_mutex_lock(0x0002E778) = 0 lwp_mutex_lock(0x0002E848) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x) = 0 poll(0xE997FBC0, 0, 50
Re: SVN migration
Not a lot of chatter on this, eh? I'll just reiterate that I think it makes the most sense to just do the least surprising thing and adopt proper along with commons. Quoting Martin Cooper [EMAIL PROTECTED]: On Wed, 5 Jan 2005 17:16:05 -0500, Rahul P Akolkar [EMAIL PROTECTED] wrote: Martin Cooper wrote: Perhaps we can brainstorm on names for a bit, and see if anyone can come up with something better. Kris Schneider wrote: Wouldn't you like to be a proper too... Just brainstorming: core reminds me of a core dump and proper makes me feel like its improper for me to be in the sandbox :) Why not use the same nomenclature as the left-side menu on our web home? http://jakarta.apache.org/taglibs/ jakarta/ taglibs/ supported/ ... sandbox/ ... Maybe even have siblings toolext and deprecated (siblings of supported). The problem with this is that, in reality, individual taglibs can move back and forth between supported and unsupported, depending upon committer interest in them. The term 'supported' on the web site is really a misnomer. There are several taglibs listed in the 'supported' section of the web site that really aren't supported in any real way. And then there's JSTL, which is listed separately on the web site, but is probably the best supported of all. The goal here is simply to reproduce the current two CVS repo directories under a single 'taglibs' root in SVN. I don't want to get into trying to invent new categories for the various pieces of code that we have. (If we really want to recategorise, let's just get the migration done first; moving things around is easy once we're using SVN.) In Commons, the distinction between Proper and Sandbox is that components in Proper have demonstrated that a community has developed around them, and that they are ready, or nearly ready, for an official release. Components that are still in their infancy, in terms of either or both of community or code, live in the Sandbox. To be honest, Taglibs seems somewhat dysfunctional when it comes to community and to the distinction between proper and sandbox. But that's a discussion for another day. ;-) Let's just pick a name for the proper part of it, and get the migration to Subversion under our belt. -- Martin Cooper Have a good 2005! -Rahul -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration
The structure sounds fine, but is commons really going with the label, proper? I prefer core, but I guess it's nothing to lose sleep over. I've only played a little with SVN, but would an expanded view of the structure look like this: jakarta/ taglibs/ core/ ... standard/ branches/ tags/ trunk/ string/ branches/ tags/ trunk/ ... sandbox/ ... datagrid/ branches/ tags/ trunk/ ... Quoting Martin Cooper [EMAIL PROTECTED]: On Wed, 5 Jan 2005, Glenn Nielsen wrote: I am not against migrating to subversion. Just be aware that the nightly script I run to generate the nightly builds depends on CVS. I would rather see a quick migration of the entire code base than a taglib here and a taglib there that takes months. If it takes months I will have to be constantly mucking around with the nightly build script. Absolutely. The idea is to migrate in two steps - first taglibs itself, and then the sandbox. One question comes to mind as I think about this. Taglibs has the same structure as Commons, insofar as there are proper and sandbox pieces. As with Commons, we'll want to put both Taglibs pieces under one root. Taglibs doesn't currently have the notion of Proper per se, but I think this would be a good time to introduce it. So we'd have: jakarta/ taglibs/ proper/ sandbox/ Does this make sense to folks? -- Martin Cooper Regards, Glenn On Mon, Jan 03, 2005 at 10:23:01PM -0500, Henri Yandell wrote: Just wondering if the Taglibs community have any thoughts on a migration to Subversion? I'm aiming to get Jakarta migrated over to Subversion this quarter and this email is intended to nudge the start of the Taglibs migration. The process seems pretty easy, though I'm not finished on my first one (jakarta-regexp): http://www.apache.org/dev/cvs2svn.html The Jakarta status is in the wiki at: http://wiki.apache.org/jakarta/Migrating_20to_20Subversion Alternatively, I'm looking to hear the problems with the idea of a migration to SVN so I can get the Infrastructure guys to deal with them. Thanks, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Precompilation
One of the things I keep meaning to play with, but never seem to get to, is to precompile with Tomcat and then include jasper-runtime.jar with the app to run on non-Tomcat containers... Felipe Leme wrote: Martin, Why don't you open an issue on the jsp-spec-public relating your problem? Here is the link: https://jsp-spec-public.dev.java.net/ I don't think this can be solved in the JSP 2.1 timeframe (as it would be out of the JSR-245 scope, and this is not a simple issue) but it is never too early for the EG to discuss the issue. -- Felipe PS: I myself agree with you but haven't had the time to raise the issue in the EG yet :-( On Tue, 2004-11-16 at 21:58, Martin Cooper wrote: Unfortunately, over the years I have got the impression that the people on the EG either don't see the problem or don't think it's important to solve. Where apps are deployed in-house, having precompiled pages may be optional, but when shipping product to customers, compiling on site is usually not even possible, since it requires a JDK, which is typically not distributable. A big mess, but I suspect we're stuck with it. -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leak in ELEvaluator.java (standard v1.0.6)
, 45% by my custom tags), 37.7% of the
expressions contain ${. [My count was taken JUST before checking the
cache for the expressions.] It would therefore seem reasonable that I
could write a method in my base tag to reduce the overhead of
unnecessary evaluation by doing this:
protected String eval(String value) throws JspException {
if (value == null) value = ;
if (value.indexOf(${) = 0) {
return (String) ExpressionEvaluatorManager.evaluate(, value,
String.class, this, pageContext);
}
else {
return value;
}
}
Would the same change work for the JSTL code also? Does it
already do this?
Are there some expressions which do not have ${ in them that
still need to be parsed into expressions? From [very briefly] looking at
the code, I can find no way that an Expression would be returned without
the String value of the expression containing ${. In fact I read in
the JSTL 1.0 Spec The EL is envoked exclusively via the construct
${expr}.
It would make sense not to cache the static expressions, since
there is no evaluation work to be saved by caching them (only memory to
be used). Of course, it would appear from my brief scan of the code that
evaluation work is done for them and memory is used caching them.
Does this make sense, or is there something else in the code
already optimizing for this case?
Sincerely,
Daryl.
-Original Message-
From: Daryl Beattie [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 21, 2004 10:33 AM
To: 'Tag Libraries Developers List'
Subject: RE: Memory Leak in ELEvaluator.java (standard v1.0.6)
Sounds good to me. Maybe in the documentation we could list the
different cache classes that are bundled the commons code by default.
That way we could include a couple different implementations and have
the users choose from them depending upon usage (much like how the JRE
comes with different GC implementations). That would be ideal. :)
- Daryl.
-Original Message-
From: Felipe Leme [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 20, 2004 8:23 PM
To: Tag Libraries Developers List
Subject: RE: Memory Leak in ELEvaluator.java (standard v1.0.6)
On Wed, 2004-10-20 at 16:26, Daryl Beattie wrote:
Also, do we want to worry about the fact that users of the standard
taglib have to set some magical (i.e. non-obvious) parameter that will
make the difference between their system being slow due to
re-evaluating expressions or taking up huge amounts of memory? They
might not expect such a thing... It would be nicer if it was somewhat
self-managing, or at least set to a default value that works for 90%
of the users. (Maybe I am not in that 90%...)
I think the best solution would be provide some sort of SPI for the
ELEvaluatorCache, for instance, a Config based property that defines the
name of a class that would implement the cache (which in turn would be a
special cache interface or just a POJUM - Plain Old Java Util Map :-).
We could also pass other init-params to fine-tune that cache (and these
parameters would depend on the implementing class). Of course, we would
provide the default implementation that covers the 90% of the cases
(maybe even self-tunable :-) plus lot of documentations.
Actually, we could go one step further and extend this SPI in other
critical places (see for instance
http://issues.apache.org/bugzilla/show_bug.cgi?id=17700 ).
-- Felipe
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leak in ELEvaluator.java (standard v1.0.6)
Heh, my reading comprehension skills are failing. JSP 1.2 requires J2SE 1.2 and JSP 2.0 requires J2SE 1.3. Just to clarify Option #2, we're talking about taking the source code for org.apache.commons.collections.map.LRUMap, changing its package, and resolving all its dependencies by doing the same thing with the source code for those classes and interfaces, right? If so, that seems reasonable. It would be nice to be able to script that somehow... In addition to the use of LRUMap, did anyone want to offer an opinion on exposing a mechanism to configure the cache size (setting cache size = 0 would effectively bypass caching)? Personally, I think it's a good idea. In keeping with the mechanics of the Config class, how about defining a servlet context init param? Something like: context-param param-nameorg.apache.taglibs.standard.lang.jstl.exprCacheSize/param-name param-value100/param-value /context-param Any thoughts on using different caching strategies? How about leveraging reference objects (SoftReference might be appropriate)? Quoting Justyna Horwat [EMAIL PROTECTED]: After sending my original mail yesterday I had looked at the JSP 2.0 requirements and you're right, they don't require J2SE 1.4. Out of the options I like Option #2 the best as well for the same reasons as Daryl and Felipe mentioned. I looked at the Collections source and they list the JDK dependency as JDK 1.2 or later. If support of the Collections classes becomes an issue we can revisit this decision and always decide to add the jar dependency in the future. Unless there are any objections, I'm going to go ahead with Option #2 and add the Collections LRUMap classes and dependencies into JSTL both 1.0 and 1.1. Thanks, Justyna Felipe Leme wrote: On Wed, 2004-10-20 at 01:04, Kris Schneider wrote: I think I jumped to the conclusion that Daryl was using JSTL 1.1 and hence made the JSP 2.0 - J2EE 1.4 - J2SE 1.4 connections. And even JSP 2.0 doesn't require J2SE 1.4, when running inside a 'standalone' web-container (i.e, outside a J2EE 1.4 container). required to support J2SE 1.3. I'm not sure I like taking on the dependency, but the Collections project already contains the classes I thought about the Collections too, but then Standard would be compound of 3 jars, which would certainly cause a lot of trouble, as people is used to only copying jstl.jar and standard.jar. We have alternatives, too: - merge commons-collection.jar into standard.jar - replicate the necessary classes into Standard src code org.apache.commons.collections.LRUMap (v.2.1.1) and org.apache.commons.collections.map.LRUMap (v.3.1). I can't seem to put a finger on the J2SE requirements for Collections though... Assuming these classes doesn't have deep dependencies on others, I would say the second option would be better (in the worst case, we would do some minor changes in the classes, like removing calls to Commons Logging, if any). -- Felipe -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leak in ELEvaluator.java (standard v1.0.6)
Of course it helps. By the way, you wouldn't have to *only* use soft references. I dimly recall implementing a cache that combined the use of strong references for the entries that *had* to be in the cache (according to some strategy) and using soft references for other entries. I suppose you could also define an upper bound on the number of additional soft cahce entries. Sort of a two-level cahce. That approach may not meet your needs either, but I just wanted to point out the possibility. When we start talking about having a more full-featured cache (self-balancing), we're moving beyond the scope of just grabbing a class from Collections and renaming it. That's not necessarily bad, we just have to weigh the options. I'm not sure that using a servlet context init param is magical or non-obvious, although it still might be ;-). It's the same mechanism that can be used to perform static configuration of certain JSTL features (dynamic configuration would be the domain of the javax.servlet.jsp.jstl.core.Config class). However, I agree we need to try and pick a default that's generally useful, but as you say, that's pretty difficult. Quoting Daryl Beattie [EMAIL PROTECTED]: I thought about a SoftReference Map... But I personally would like to keep a handle on the size of cache instead of having it eat up all my memory and then forcing a garbage collection to remove soft references. My app, for example, has to be FAST, which means pause times for GC activity have to be very low. I use the low-pause collector for that reason. But when I tested with SoftReference Map caches, I found that all my memory was gone and then a huge full GC took place that paused the VM for a considerable length of time. Since then I've not used SoftReference Maps because I'm scared of the memory usage. On the other hand, finding the right default value for the max cache size is not easy. I'm noticing that a exprCacheSize of 100 is way too small; just one user on my system produces 400 expressions in no time. If the cache were limited to 100 in size by default, my processor would still be maxed out. Naturally the size of the cache would vary from application to application... Would it be possible to have a self-balancing cache? One that would grow to a size where the hit-rate would be steady at about 70%? Then again, the hit-rate would depend upon the variety of expressions being evaluated, which again depends upon how expressions are used in the application. WeakHashMaps won't help us, since the expression Strings are created/destroyed by every tag As for more solution ideas, I don't have any right now. I'll give it some more thought. Also, do we want to worry about the fact that users of the standard taglib have to set some magical (i.e. non-obvious) parameter that will make the difference between their system being slow due to re-evaluating expressions or taking up huge amounts of memory? They might not expect such a thing... It would be nicer if it was somewhat self-managing, or at least set to a default value that works for 90% of the users. (Maybe I am not in that 90%...) I don't know if this info helps... You did ask for my thoughts. :) - Daryl. -Original Message- From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 1:56 PM To: Tag Libraries Developers List Subject: Re: Memory Leak in ELEvaluator.java (standard v1.0.6) Heh, my reading comprehension skills are failing. JSP 1.2 requires J2SE 1.2 and JSP 2.0 requires J2SE 1.3. Just to clarify Option #2, we're talking about taking the source code for org.apache.commons.collections.map.LRUMap, changing its package, and resolving all its dependencies by doing the same thing with the source code for those classes and interfaces, right? If so, that seems reasonable. It would be nice to be able to script that somehow... In addition to the use of LRUMap, did anyone want to offer an opinion on exposing a mechanism to configure the cache size (setting cache size = 0 would effectively bypass caching)? Personally, I think it's a good idea. In keeping with the mechanics of the Config class, how about defining a servlet context init param? Something like: context-param param-nameorg.apache.taglibs.standard.lang.jstl.exprCacheSize/param-n ame param-value100/param-value /context-param Any thoughts on using different caching strategies? How about leveraging reference objects (SoftReference might be appropriate)? Quoting Justyna Horwat [EMAIL PROTECTED]: After sending my original mail yesterday I had looked at the JSP 2.0 requirements and you're right, they don't require J2SE 1.4. Out of the options I like Option #2 the best as well for the same reasons as Daryl and Felipe mentioned. I looked at the Collections source and they list the JDK dependency as JDK 1.2 or later. If support of the Collections classes becomes an issue we can revisit
RE: Memory Leak in ELEvaluator.java (standard v1.0.6)
Some quick options off the top of my head: J2EE 1.4 requires J2SE 1.4, so we could create an LRU cache with LinkedHashMap (override the removeEldestEntry method). We could also implement a cache using reference objects. Since ELEvaluator already has a constructor arg for bypassing the cache, we could expose a way to configure its use. I think the only place one is currently created is as a singleton within Evaluator. Obviously, this could also be combined with a more memory-friendly cache. Quoting Daryl Beattie [EMAIL PROTECTED]: Hi everyone, Following up on the memory leak; I have found that the possible memory leak in the ELEvaluator is indeed a real memory leak. Beyond profiling to find the bug, I have gone to the trouble of disabling the sCachedExpressionStrings cache in ELEvaluator, recompiling the standard taglib, deploying and re-testing with the cache-disabled jar. What I found is that indeed the leak did disappear, and after running under a load for 8 hours my app was using the same amount of memory as it had used in the first 20 minutes. So it definitely is a leak. What should be done about it? Is there a last-recently-used map that we could be using instead of just a regular HashMap? Should I stick with my cache-disabled jar? I would like to know how you folks would like to handle the bug so that I can eventually get a new version of the standard taglib. Otherwise, I'll be stuck deploying my hacked jar and relying on my own hacked version of the taglib. Let me know if there's any way I can help to get this problem fixed; I'd be glad to volunteer some effort and even some profiling testing. Sincerely, Daryl. -Original Message- From: Daryl Beattie [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 5:40 PM To: [EMAIL PROTECTED] Subject: Possible Memory Leak in ELEvaluator.java (standard v1.0.6) Hi everybody, I have a question about a possible memory leak in ELEvaluator.java. I have noticed when profiling that HashMap entries (containing Strings, etc.) are kept by the sCachedExpressionStrings static variable and never removed. Over the course of running an application for several hours that uses tags that have evaluations in them, this Map builds up in memory -- in fact I noticed that it was 343k for just one tag alone after I ran my app for 5 minutes. I have dynamically constructed expressions, and am concerned that each one is being cached even if that expression is never used again. Would it be prudent to use some other kind of Collection to store these cached expressions (such as one that times out its entries after a certain amount of time)? Also, I have toyed with the idea of adding functionality to permanently disable the cache, but since I do not know the expense of creating a new ELParser with the String expression, I do not know if this will cripple my system. I believe I have a normal percentage of re-used expressions across my tags. I also find it interesting that there is functionality to bypass getting values from the cache, but there is not yet a way to disable its use. Even when bypassing the cache, the cache grows over time. What do you think about this possible leak? Sincerely, Daryl. -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leak in ELEvaluator.java (standard v1.0.6)
I think I jumped to the conclusion that Daryl was using JSTL 1.1 and
hence made the JSP 2.0 - J2EE 1.4 - J2SE 1.4 connections. Since we're
really talking about JSTL 1.0 (JSP1.2 - J2EE 1.3), I think we're
required to support J2SE 1.3. I'm not sure I like taking on the
dependency, but the Collections project already contains the classes
org.apache.commons.collections.LRUMap (v.2.1.1) and
org.apache.commons.collections.map.LRUMap (v.3.1). I can't seem to put a
finger on the J2SE requirements for Collections though...
Justyna Horwat wrote:
Hi Daryl,
There is actually a bug report already filed:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30136
One possible solution that Kris mentioned is using an LRU cache. We
could do something as follows in ELEvaluator.java:
final int MAX_ENTRIES = 100; //*** profiling would help here ***
static Map sCachedExpressionStrings =
Collections.synchronizedMap(
Map cache = new LinkedHashMap (MAX_ENTRIES + 1, .75F, true) {
public boolean removeEldestEntry(Map.Entry eldest) {
return size() MAX_ENTRIES;
}
}
);
I don't have any profilers setup so I'd appreciate your analysis of
these changes.
I also need to investigate the impact of adding a J2SE 1.4 dependency in
the codebase. If it's a problem then we may need to do our own
LinkedHashMap implementation.
Thanks,
Justyna
Kris Schneider wrote:
Definitely file a bug in bugzilla. Before a fix gets coded, however,
there has
to be some developer (meaning committer) consensus on what the fix
actually is.
This is the correct forum for the discussion and hopefully the bug
report will
spur additional comments.
Quoting Daryl Beattie [EMAIL PROTECTED]:
Okay So I'm not used to this; how does the task of fixing this
problem get assigned? Should I open a bug in bugzilla for it?
I'd gladly work on it and see what I can get done (as long as I can ask
you developers for assistance if I need to know how something works).
The only question mark in my mind right now is where to put the
configuration option, but I'm sure once I start digging through the code
I'd find it easily enough.
- Daryl.
-Original Message-
From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Tuesday, October
19, 2004 2:43 PM
To: Tag Libraries Developers List
Subject: RE: Memory Leak in ELEvaluator.java (standard v1.0.6)
Some quick options off the top of my head:
J2EE 1.4 requires J2SE 1.4, so we could create an LRU cache with
LinkedHashMap (override the removeEldestEntry method).
We could also implement a cache using reference objects.
Since ELEvaluator already has a constructor arg for bypassing the cache,
we could expose a way to configure its use. I think the only place one
is currently created is as a singleton within Evaluator. Obviously, this
could also be combined with a more memory-friendly cache.
Quoting Daryl Beattie [EMAIL PROTECTED]:
Hi everyone,
Following up on the memory leak; I have found that the
possible
memory leak in the ELEvaluator is indeed a real memory leak. Beyond
profiling to find the bug, I have gone to the trouble of disabling the
sCachedExpressionStrings cache in ELEvaluator, recompiling the
standard taglib, deploying and re-testing with the cache-disabled jar.
What I found is that indeed the leak did disappear, and after
running under a load for 8 hours my app was using the same amount of
memory as
it had used in the first 20 minutes.
So it definitely is a leak.
What should be done about it? Is there a last-recently-used map
that
we could be using instead of just a regular HashMap? Should I stick
with my cache-disabled jar?
I would like to know how you folks would like to handle the bug
so
that I can eventually get a new version of the standard taglib.
Otherwise, I'll be stuck deploying my hacked jar and relying on my own
hacked version of the taglib. Let me know if there's any way I can
help to get this problem fixed; I'd be glad to volunteer some effort
and even some profiling testing.
Sincerely,
Daryl.
-Original Message-
From: Daryl Beattie [mailto:[EMAIL PROTECTED]
Sent: Friday, October 15, 2004 5:40 PM
To: [EMAIL PROTECTED]
Subject: Possible Memory Leak in ELEvaluator.java (standard v1.0.6)
Hi everybody,
I have a question about a possible memory leak in
ELEvaluator.java. I have noticed when profiling that HashMap entries
(containing Strings, etc.) are kept by the sCachedExpressionStrings
static variable and never removed. Over the course of running an
application for several hours that uses tags that have evaluations
in them, this Map builds up in memory -- in fact I noticed that it
was 343k for just one tag alone after I ran my app for 5 minutes. I
have dynamically constructed expressions, and am concerned that each
one is
being cached even if that expression is never used again.
Would it be prudent to use some other kind of Collection to
store these cached expressions (such as one that times out
Re: JSTL XML tags performance
Justyna, Yup, I know it's bundled with 5.0, but I just haven't come across any information that says JAXP 1.3 is also targeted to work with earlier versions of Java. I also haven't been able to track down any free-standing JAXP 1.3 implementations. Any idea if there are any? Thanks. Quoting Justyna Horwat [EMAIL PROTECTED]: Hi Kris, With J2SE 5.0 the JAXP 1.3 implementation will be a part of your runtime. You won't have to download anything extra in order to use JAXP 1.3 with J2SE 5.0. With J2SE 1.4.x or earlier you will need to bundle JAXP 1.3 along with your JSTL implementation classes. This is similar to what you had to do if you were running J2SE 1.3.x which didn't have the JAXP 1.2 implementation and wanted to use JSTL 1.1.x. Thanks, Justyna Kris Schneider wrote: Justyna, I'm having a hard time tracking down any information on whether a JAXP 1.3 implementation will be available for anything earlier than J2SE 5.0. Any idea if there will be (or is) something that will work with J2SE 1.4.2? Thanks. Quoting Justyna Horwat [EMAIL PROTECTED]: Hi Flavio, Before I left for vacation, I created a branch where I created a first revision of JSTL that leverages the JAXP 1.3 APIs. It's not finished yet but the majority of the work is done. The tag is: standard-111_JAXP13_BRANCH I believe that the performance problem can be addressed by moving towards the standard JAXP 1.3 implementation. Thanks, Justyna -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL XML tags performance
Justyna, Thanks for the scoop ;-). I did a little more digging and actually found a couple of posts on the Xerces/Xalan lists where Sun is offering to donate the JAXP 1.3 sources to Apache. Sounds like it's just a matter of waiting for stuff to become available... Justyna Horwat wrote: Hi Kris, I sent a note to my local JAXP guru and he said there will be several different standalone JAXP 1.3 implementations available real soon. Unfortunately until they are publicly available I cannot go into more details. I've also been told that JAXP 1.3 standalone build has been tested and definitely will also work with JDK 1.4.x. Thanks, Justyna Kris Schneider wrote: Justyna, Yup, I know it's bundled with 5.0, but I just haven't come across any information that says JAXP 1.3 is also targeted to work with earlier versions of Java. I also haven't been able to track down any free-standing JAXP 1.3 implementations. Any idea if there are any? Thanks. Quoting Justyna Horwat [EMAIL PROTECTED]: Hi Kris, With J2SE 5.0 the JAXP 1.3 implementation will be a part of your runtime. You won't have to download anything extra in order to use JAXP 1.3 with J2SE 5.0. With J2SE 1.4.x or earlier you will need to bundle JAXP 1.3 along with your JSTL implementation classes. This is similar to what you had to do if you were running J2SE 1.3.x which didn't have the JAXP 1.2 implementation and wanted to use JSTL 1.1.x. Thanks, Justyna Kris Schneider wrote: Justyna, I'm having a hard time tracking down any information on whether a JAXP 1.3 implementation will be available for anything earlier than J2SE 5.0. Any idea if there will be (or is) something that will work with J2SE 1.4.2? Thanks. Quoting Justyna Horwat [EMAIL PROTECTED]: Hi Flavio, Before I left for vacation, I created a branch where I created a first revision of JSTL that leverages the JAXP 1.3 APIs. It's not finished yet but the majority of the work is done. The tag is: standard-111_JAXP13_BRANCH I believe that the performance problem can be addressed by moving towards the standard JAXP 1.3 implementation. Thanks, Justyna -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clarification of Bug 17165 (also Bug 31585)
Aha! That's why this post never showed up in [EMAIL PROTECTED] ;-). Nothing to see here, keep moving... Quoting Kris Schneider [EMAIL PROTECTED]: Currently, Bug 17165 is resolved invalid and Bug 31585 is resolved duplicate (of 17165). The basic conclusion seems to be that nothing can be done on Struts' part. I sketched out the use of an internal reference object for Bug 31585, but now I'm curious whether or not it would really be of use. If the container just maintains strong references to the tag handler instances, then using an internal reference object to wrap the collection should help. That way, each tag handler instance only maintains a strong reference to the collection between doStartTag and doEndTag invocations. However, if the container also maintains strong references to the attribute values, then an internal refernce object won't help. Can anyone shed some light on whether or not a container is likely to maintain strong references to tag attribute values (or the results of calling a tag handler's property read methods)? Bug 17165: http://tinyurl.com/49r9b Bug 31585: http://tinyurl.com/465uf -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Clarification of Bug 17165 (also Bug 31585)
Currently, Bug 17165 is resolved invalid and Bug 31585 is resolved duplicate (of 17165). The basic conclusion seems to be that nothing can be done on Struts' part. I sketched out the use of an internal reference object for Bug 31585, but now I'm curious whether or not it would really be of use. If the container just maintains strong references to the tag handler instances, then using an internal reference object to wrap the collection should help. That way, each tag handler instance only maintains a strong reference to the collection between doStartTag and doEndTag invocations. However, if the container also maintains strong references to the attribute values, then an internal refernce object won't help. Can anyone shed some light on whether or not a container is likely to maintain strong references to tag attribute values (or the results of calling a tag handler's property read methods)? Bug 17165: http://tinyurl.com/49r9b Bug 31585: http://tinyurl.com/465uf -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Wiki for Taglibs?
Right, we'll make that the first FAQ: How should I answer a FAQ? ;-) [ ] +1 I want my Taglibs Wiki! [ ] 0 I am neutral on a Taglibs wiki [ ] -1 No Wiki for Taglibs! Quoting Martin Cooper [EMAIL PROTECTED]: If you want to make this thread the vote thread, then you should prefix the subject with [VOTE] so that people know there's a vote going on, rather than just a discussion thread. I am neutral on a Taglibs wiki, simply because there isn't all that much traffic on the lists, so I'm not sure how much it would be used. On the other hand, I do see that we could put a FAQ there, so I'd be supportive it if people promise to answer questions with just links to the FAQ instead of repeating the solutions. ;-) -- Martin Cooper On Tue, 28 Sep 2004 11:43:09 -0400, Kris Schneider [EMAIL PROTECTED] wrote: If I'm grokking the Apache Wiki structure properly, Taglibs isn't included. It seems like it would be a helpful resource to have available, so I found this at http://wiki.apache.org/general/HowToMakeWikiAdminRequests: If your request is for a new subwiki to be set up, take these steps: 1. discuss the plan with the appropriate development teams and gain consensus. 2. make sure the appropriate Project Management Committee (PMC) wants to have the wiki set up and assume responsibility over it. 3. only after #1 and #2 are done, send an e-mail. So I guess this note qualifies as the start of #1. I'll jump right in and call for a vote, but additional discussion is certainly welcome (especially if I'm being clueless about how to get this thing set up). [ ] +1 I want my Taglibs Wiki! [ ] -1 No Wiki for Taglibs! My vote's a +1. -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
