Re: cvs commit: jakarta-commons/jelly project.xml
I've never understood removing the ability to use a standard XML feature. I understand why it would be discouraged, but removing seems wrong. It'll be optional. The parser used without it, I'm told, is an order of magnitude faster with it turned off. This becomes an issue when things like transitive dependencies are enabled because there are quite a number of POMs to parse traversing the dependency tree. Still, nothing is set in stone. Sounds good. I've reverted to using 1.0.1 anyway as 1.1-SNAPSHOT of maven has issues ATM. Yep, well it's fairly early in the dev. cycle and a few things in there are proof of concept as much as anything and there is some cleaning up to do. Still, feel free to file issues if there are blocking problems so they can be sorted earlier rather than later. Do you want me to adjust the build, or shall I leave it with you? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/jelly project.xml
I may have been the one doing this. It is related to the fact that, at least at the time, maven had no way to specify to digester the system-ID of the parsed document which made it that the parser was only able to resolve the entities wrt to the working directory which broke in... jelly-tags/xxx/... I think it has been fixed in Digester and this may have changed in maven, but I think it was still in the 1.0. paul Le 22 nov. 04, à 06:38, Dion Gillard a écrit : I've never understood removing the ability to use a standard XML feature. I understand why it would be discouraged, but removing seems wrong. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction][VOTE] Release 1.0-RC1
+1 Stefan Oliver Zeigermann wrote: Dear community, I would like to see a 1.0 release candidate. The code is stable, junt tests pass, document exists and the scripts are in good shape. Still we should check that everything looks the way we expect before releasing a final 1.0. I already created the distributions calling 'ant package'. They are ready for inspection here: http://www.apache.org/~ozeigermann/ So, I am +1 for a release. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stefan Lützkendorf -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Chain 1.0
Not to jump all over you, but Chain was there for a year, and I too used
it in prouduction. Alternative interfaces would mean redesign and maybe
even problems for current users, it is not backwards compatible.
A key to its power is the Map. I realy think that if you got a chance to
use it it would come to you.
I too agree that WebContext caries to much info. Also... the point of
the map is to add what you need. I can think of 100 Contexts (Portlet,
Hessian, Soap, JSF, JMS, Jabber, ).
Maybe in the 1.1 release those things are marked for deprecation.
.V
Matt Sgarlata wrote:
Before a 1.0 release, I would like to suggest an alternative Context
interface. Sorry, I realize I'm getting to the game a little late ;) I
think it is inappropriate for Context to extend from Map, because a
Context as defined in the Chain package isn't really a Map. Maps are
great, but for what the Chain package is trying to do they're probably
overkill. One testament to this fact is the incredible difficulty of
implementing the ServletWebContext class. Implementing methods like
entrySet(), keySet(), and values() are a real pain, and the
implementations are all O(n)... ouch.
Below is my suggested alternative interface. It's simple by design, to
make it easy to implement.
public interface Context {
public String[] getPropertyNames() throws ContextException;
public Object get(String propertyName) throws ContextException;
public void set(String propertyName, Object propertyValue)
throws ContextException;
}
I also am concerned that the ServletWebContext class exposes too much
information that is specific to the presentation tier. Even if a
business object were to depend only on the Context interface, if a
ServletWebContext was passed in, the business object would be tied to
HTTP symantics with calls such as
context.get(sessionScope.myBean.myProperty). I would recommend a
context simliar to the one available to the JST: let request attributes
be a scratchpad and let session and application items be visible so long
as they aren't blocked by a lower level.
For full javadoc on my ideas behind contexts, please see the
net.sf.morph.Context class and the net.sf.morph.context.* package.
Also, take a look at net.sf.morph.context.ServletWebContext. Here's a
link to the Morph homepage where you can access the Morph API:
http://www.crystalcognition.com/sgarlatm/morph
I'm not on SourceForge yet but I applied on Friday so hopefully I'll be
there soon!
Matt
- Original Message - From: Martin Cooper [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, November 21, 2004 6:01 PM
Subject: [VOTE] Release Chain 1.0
I believe Chain is now sufficiently complete and stable to warrant an
official 1.0 release. There are no outstanding bug reports, and the
component is already in use in a number of projects.
The plan is to release HEAD as Commons Chain 1.0 on completion of a
successful vote. I will be the release manager.
---
[ ] +1 I support this release and am willing to help
[ ] +0 I support this release but am unable to help
[ ] -0 I do not support this release
[ ] -1 I do not support this release, and here are my reasons
---
Here is my own +1.
--
Martin Cooper
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Resources to Commons Proper
-0 I haven't been involved with this project at all, however I haven't had any impression of there being an active community working with the component. In fact, I can't remember seeing any emails about [resources] except for lots of failed gump reports (which indicates a lack of maintainance to me). If I get time, I may research to see if my memory is accurate, because if so I may change my vote to -1. Perhaps you could clarify who the users of this are, and why now is the time to promote it? Stephen --- Martin Cooper [EMAIL PROTECTED] wrote: The Resources project has been in the sandbox for quite some time, and is essentially complete and almost ready for a release. Several projects are using it already, and others are ready to pick it up once it is released. Therefore I propose that we promote Resources out of the sandbox and into Commons Proper, in preparation for a 1.0 release in the near future. --- [ ] +1 I support this proposal and am willing to help [ ] +0 I support this proposal but am unable to help [ ] -0 I do not support this proposal [ ] -1 I do not support this propsal, and here are my reasons --- Here is my own +1. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Chain 1.0
Hi, --- [ X ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- The design discussions have merit, but they should be deferred to version 1.1 or later, and should not hold up the 1.0 release. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Resources to Commons Proper
- Original Message - From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, November 22, 2004 8:09 AM Subject: Re: [VOTE] Promote Resources to Commons Proper -0 I haven't been involved with this project at all, however I haven't had any impression of there being an active community working with the component. Well, that's because this effort is mostly complete. Trust me, activity level will explode as soon as resources becomes a core dependency in Struts. We are almost there. I have already begun work on a plugin that let's people use the existing commons-resources with previous Struts versions 1.1 and 1.2.x as well as several DBMS-based impls hosted on sf.net due to licensing (and now, build) issues. In fact, I can't remember seeing any emails about [resources] except for lots of failed gump reports (which indicates a lack of maintainance to me). No, actually the failed gump reports were due to the fact that someone changed something in the gump environment that this project depended on, but was either unaware or unconcerned enough to realize they broke it. I'm talking about the dependency on an iBatis jar that was moved or deleted. So, since noone answered my plea for help, I removed the files that needed them and I will release them separately under sf.net (as mentioned above). After doing that, gump stopped puking to the list. I am aware of what gump is and why we use it. But the 2 main build processes I happen to care about are Ant and Maven. Commons Resources has always built fine with both, and the fairly complete tests always pass without issue. Sorry if this seems like a rant, but I am actually more pissed off at myself for being helpless when it comes to gump than I am about someone affecting the build. If I get time, I may research to see if my memory is accurate, because if so I may change my vote to -1. Perhaps you could clarify who the users of this are, and why now is the time to promote it? Right at this moment, there is a very small user base. However, if you consider the thousands of existing and future users of Apache Struts as a good number, then you might change your mind about that -1. Commons Resources is slated (and has been for quite some time) to be used by Struts just as digester, logging, beanutils, etc are now. The home page for resources should have spelled that out for you. http://jakarta.apache.org/commons/sandbox/resources/ Stephen -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32347] New: - bean.propertyName does not evaluate correctly if the bean implements java.util.List
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=32347.
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=32347
Summary: bean.propertyName does not evaluate correctly if the
bean implements java.util.List
Product: Commons
Version: 1.0 Final
Platform: PC
OS/Version: Windows 2000
Status: NEW
Severity: normal
Priority: P2
Component: EL
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I was using EL in a choose tag and could not get it to work at all on a
particular page. It worked on other pages, but on one particular page I kept
getting errors no matter what I tried. I would get errors like the following:
${VistaTreeModelProxy.empty == false} contains invalid expression(s):
javax.servlet.jsp.el.ELException: Encountered empty, expected one of
[IDENTIFIER]
at org.apache.jasper.compiler.DefaultErrorHandler.jspError
(DefaultErrorHandler.java:39)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch
(ErrorDispatcher.java:409)
After trying many different syntaxes, I got a trace of:
2004-11-22 09:28:16 ApplicationDispatcher[/JSF] Servlet.service() for servlet
jsp threw exception
javax.servlet.jsp.el.ELException: The . operator was supplied with an index
value of type java.lang.String to be applied to a List or array, but that
value cannot be converted to an integer.
at org.apache.commons.el.Logger.logError(Logger.java:481)
at org.apache.commons.el.Logger.logError(Logger.java:498)
at org.apache.commons.el.Logger.logError(Logger.java:566)
at org.apache.commons.el.ArraySuffix.evaluate(ArraySuffix.java:227)
at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:145)
I downloaded the source and followed the stack-trace. It looks as though the
fact that my bean implemented java.util.List was causing the problem. (This is
the only difference I could really find from my identical use of the choose
tag in other pages.)
From what I have read, the dot-syntax should always try for a bean property,
but this doesn't seem to work in the case of a List. Also, using the
[property] syntax will also always try to coerce property into an integer.
I am not sure if this is correct either, although what I have read is a bit
ambiguous.
To work-around this, just don't use EL when it gets confused. The syntax below
works:
c:when test=%= VistaTreeModelProxy.isEmpty() == false %
--
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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32347] - bean.propertyName does not evaluate correctly if the bean implements java.util.List
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=32347.
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=32347
--- Additional Comments From [EMAIL PROTECTED] 2004-11-22 17:06 ---
Try using
c:when test=${fn:length(VistaTreeModelProxy) 0 %
You will need JSTL functions library.
The behaviour you describe is meant to be used this way:
c:out value=${VistaTreeModelProxy[0]}/
and it will write the first element from your list!
--
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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
cool, thanks Emmanuel. Eric will this be the last step for leaving sandbox? Regards, Matthias -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Sunday, November 21, 2004 3:48 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: [VOTE] Promote Email to Commons Proper I prepared a bundle for dumbster on codehaus. It will be synchronize with ibiblio in few hours. Emmanuel - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Friday, November 19, 2004 5:26 AM Subject: Re: [VOTE] Promote Email to Commons Proper Impressively, Jason has now updated the SF site, the Dumbster site and released a new version under the ASL 2.0. All that remains is to get it into Maven, and I figure that one of the [email] guys can happily do that (there are instructions on the Maven site for it). So nothing looks likely to slow down a release, and many kudos to Jason Kitchen for being so responsive to our legal particulars. Hen On Thu, 18 Nov 2004 19:57:09 +, robert burrell donkin [EMAIL PROTECTED] wrote: On 18 Nov 2004, at 11:39, Eric Pugh wrote: Alright.. This thread has somewhat gotton away from me. Since Dumbster is now licensed as ASL (despite the website being out of date), can we move to a conclusion on this thread? If we consider that [email] hasn't materially changed, and therefore a new vote isn't required, then I currently tally: +1 Eric Pugh +1 Matthias Wessendorf +1 Yoav Shapira Robert, you raised the original lgpl issue which I hope is now sorted out. While you didn't specifically put a -1 down, I think it was implied. Would you be willing to change that to something else? i'm now +1 to promotion (and like henri -1 to release until all the loose ends concerning the dumbster license) i would like to see a note added to the web site recommending the latest (ASF licensed) dumbster. i'd also like to see a new version of dumbster (with an ASL license) uploaded to the maven java repository and the project.xml updated to reflect that. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Resources to Commons Proper
Hi, Perhaps you could clarify who the users of this are, and why now is the time to promote it? That was exactly my question too before voting ;) ? Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32347] - bean.propertyName does not evaluate correctly if the bean implements java.util.List
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=32347. 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=32347 --- Additional Comments From [EMAIL PROTECTED] 2004-11-22 17:53 --- I appreciate the additional options! Background --- I am using JSF and a component by a 3rd party. The isEmpty() method is a method in their TreeModel interface. I need to use HTML frames to display the page, since I need HTML frame's resizing ability. However, using frames can cause the pages in the frames to load in the wrong order. This causes NPEs, which I solved by refreshing quick pages after the slower pages load. Oh, what a complicated web we weave... -- Their TreeModelImpl (which my TreeModelProxy extends) implements List, but my TreeModelProxy has a Map that holds the different tree models I will be using. My TreeModel proxy overrides *all* the TreeModel methods to return the correct value based on the selected model in the map. On initialization there are no complete models to load, so in my TreeModelProxy isEmpty() returns true if there are no complete models. I never use the List object that backs my TreeModelProxy. So, why does TreeModelProxy extend their TreeModelImpl (which implements List) at all? Good question. This is because in the component library I am using, their is another bug where they mistakenly cast the model to their TreeModelImpl class, and not just to their TreeModel interface. If it was not for the JSF component cast issue, I would never have ran into this since my TreeModelProxy would have extended Object and only implemented their TreeModel. -- 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Chain 1.0
Hi everyone, thanks for your feedback. Sounds like my ideas for a different
Context are an enhancement request for Chain 1.1 or Chain 2.0.
As for the Context vs. Map issue, I think the approach I'll take in the
Morph framework is to have the DelegatingContext class implement Map. That
way, in most situations the Map interface will be very easily accessible.
Also, to create a new Context implementation, only the methods defined in
the BeanReflector interface will have to be implemented, which is a lot
easier than implementing the entire Map contract.
Just to give you an idea how easy the BeanReflector interface is to
implement, the entire implementation is only 45 lines for a reflector that
exposes HTTP request parameters. That's in contrast to 121 lines in
org.apache.commons.chain.web.servlet.ServletParamMap. (Note, these counts
start at the line of code that contains the opening brace for the class...
for example, at the line 'final class ServletParamMap implements Map {')
Matt
- Original Message -
From: Shapira, Yoav [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Monday, November 22, 2004 8:47 AM
Subject: RE: [VOTE] Release Chain 1.0
Hi,
---
[ X ] +1 I support this release and am willing to help
[ ] +0 I support this release but am unable to help
[ ] -0 I do not support this release
[ ] -1 I do not support this release, and here are my reasons
---
The design discussions have merit, but they should be deferred to
version 1.1 or later, and should not hold up the 1.0 release.
Yoav
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged. This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else. If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Resources to Commons Proper
On Sun, 21 Nov 2004 18:20:33 -0800 (PST), Martin Cooper [EMAIL PROTECTED] wrote: The Resources project has been in the sandbox for quite some time, and is essentially complete and almost ready for a release. Several projects are using it already, and others are ready to pick it up once it is released. Therefore I propose that we promote Resources out of the sandbox and into Commons Proper, in preparation for a 1.0 release in the near future. --- [X] +1 I support this proposal and am willing to help [ ] +0 I support this proposal but am unable to help [ ] -0 I do not support this proposal [ ] -1 I do not support this propsal, and here are my reasons --- Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Resources to Commons Proper
On Mon, 22 Nov 2004 13:09:41 + (GMT), Stephen Colebourne [EMAIL PROTECTED] wrote: -0 I haven't been involved with this project at all, however I haven't had any impression of there being an active community working with the component. In fact, I can't remember seeing any emails about [resources] except for lots of failed gump reports (which indicates a lack of maintainance to me). I've observed that 99% of the failed Gump reports have been due to failures in the builds of the downstream dependencies -- the last time that Resources build was broken because of a problem in it's own source was a long time ago. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Chain 1.0
On Sun, 21 Nov 2004 15:01:02 -0800 (PST), Martin Cooper [EMAIL PROTECTED] wrote: I believe Chain is now sufficiently complete and stable to warrant an official 1.0 release. There are no outstanding bug reports, and the component is already in use in a number of projects. The plan is to release HEAD as Commons Chain 1.0 on completion of a successful vote. I will be the release manager. --- [X] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Chain 1.0
Hi Martin, On Mon, 2004-11-22 at 20:39, Martin Cooper wrote: This sounds like an enhancement request to me. Are you really suggesting that Chain should not be released until your specific enhancement is endorsed and incorporated into the component? I'm afraid I, for one, can't sign up for that. I think Matt's comment was entirely reasonable. The whole point of a 1.0 release is to freeze the API. If the API isn't right, then people certainly should speak up *before* the API freeze. Of course it is better to speak up well before then if possible, but a release proposal is bound to prompt people to get around to voicing that concern they have had kicking around in the back of their mind for a while. Anyone raising the prospect of a release should be expecting this sort of thing. It looks to me, as an outsider, like the concensus is that the existing interface *is* ok, but as a commons committer I hope that everyone will give it serious consideration, and not ignore it as too late. It is perfectly valid to change APIs before 1.0 (keeping compatibility is *desirable* but not mandatory). It's certainly better than being stuck with the wrong API post-1.0. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Chain 1.0
Sorry, one more comment for ServletWebContext, below... - Original Message - From: Don Brown [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Sunday, November 21, 2004 11:11 PM Subject: Re: [VOTE] Release Chain 1.0 As for ServletWebContext, I see your point, but I'd argue that business classes would never see the actual ServletWebContext, but rather get passed an application-specific context, which may or may not contain ServletWebContext. For Struts, I'm thinking we'd use an ActionContext, which would look for objects in the scope hierarchy on a get() as you suggest, if it detected a WebContext. Otherwise, the value would come right out of the ActionContext. I could see the value in bringing that scope logic to WebContext, however. OK, assuming we like ServletWebContext as it currently stands, wouldn't it make more sense for getRequestScope(), getSessionScope(), etc. to return Context instead of Map? Don Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Chain 1.0
On Tue, 23 Nov 2004 09:37:27 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Hi Martin, On Mon, 2004-11-22 at 20:39, Martin Cooper wrote: This sounds like an enhancement request to me. Are you really suggesting that Chain should not be released until your specific enhancement is endorsed and incorporated into the component? I'm afraid I, for one, can't sign up for that. I think Matt's comment was entirely reasonable. The whole point of a 1.0 release is to freeze the API. If the API isn't right, then people certainly should speak up *before* the API freeze. You're right, of course. Of course it is better to speak up well before then if possible, but a release proposal is bound to prompt people to get around to voicing that concern they have had kicking around in the back of their mind for a while. Anyone raising the prospect of a release should be expecting this sort of thing. I was (over)reacting to exactly that. Chain was promoted out of the sandbox almost 6 months ago, so seeing such a fundamental change being proposed at this point was a bit like a bolt from the blue. Matt, I apologise for jumping down your throat. It looks to me, as an outsider, like the concensus is that the existing interface *is* ok, but as a commons committer I hope that everyone will give it serious consideration, and not ignore it as too late. It is perfectly valid to change APIs before 1.0 (keeping compatibility is *desirable* but not mandatory). It's certainly better than being stuck with the wrong API post-1.0. Agreed. I have first hand experience of dealing with a poor API being exposed in a release... -- Martin Cooper Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Resources to Commons Proper
On Mon, 22 Nov 2004 13:09:41 + (GMT), Stephen Colebourne [EMAIL PROTECTED] wrote: -0 I haven't been involved with this project at all, however I haven't had any impression of there being an active community working with the component. In fact, I can't remember seeing any emails about [resources] except for lots of failed gump reports (which indicates a lack of maintainance to me). The core functionality in Resources was complete some time ago, with properties file and XML implementations. We (meaning James Mitchell ;) started to add database implementations, but fell foul of the LGPL / Java issues, so those implementations were moved out of the ASF. Since the core implementation was completed, I suspect there has actually been more discussion of this component on the Struts mailing lists than here, since the core is really just done. Being done, it really should be published as such, so that other projects and users who need a release can rely on one. Promoting Resources out of the sandbox is the first step in that process. If I get time, I may research to see if my memory is accurate, because if so I may change my vote to -1. Perhaps you could clarify who the users of this are, and why now is the time to promote it? The immediate user of Resources will be Struts 1.3. The Struts community has been discussing switching to this component for a long time. We just branched our 1.2 development so that we can start on 1.3, hence the renewed push to bring Resources to the world. In the meantime, I am aware that a number of people have picked up Resources independent of Struts and are using it in production. I'm assuming it just works for them, since, as you noted, there isn't much traffic on the lists. I do believe that there will be more direct interest in this component once it is in use in Struts, but Struts is by no means the sole consumer for a component such as this. -- Martin Cooper Stephen --- Martin Cooper [EMAIL PROTECTED] wrote: The Resources project has been in the sandbox for quite some time, and is essentially complete and almost ready for a release. Several projects are using it already, and others are ready to pick it up once it is released. Therefore I propose that we promote Resources out of the sandbox and into Commons Proper, in preparation for a 1.0 release in the near future. --- [ ] +1 I support this proposal and am willing to help [ ] +0 I support this proposal but am unable to help [ ] -0 I do not support this proposal [ ] -1 I do not support this propsal, and here are my reasons --- Here is my own +1. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Resources to Commons Proper
OK, I'm going to leave my vote as -0. I do believe that there should be some signs of life in a component before promotion, rather than seeing a vote thread appear from thin air. I am not going to try to actively block the component however. Instead, I trust that you and the other struts committers will prove good guardians of the code if and when it needs maintaining. Stephen - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] -0 I haven't been involved with this project at all, however I haven't had any impression of there being an active community working with the component. Well, that's because this effort is mostly complete. Trust me, activity level will explode as soon as resources becomes a core dependency in Struts. We are almost there. I have already begun work on a plugin that let's people use the existing commons-resources with previous Struts versions 1.1 and 1.2.x as well as several DBMS-based impls hosted on sf.net due to licensing (and now, build) issues. In fact, I can't remember seeing any emails about [resources] except for lots of failed gump reports (which indicates a lack of maintainance to me). No, actually the failed gump reports were due to the fact that someone changed something in the gump environment that this project depended on, but was either unaware or unconcerned enough to realize they broke it. I'm talking about the dependency on an iBatis jar that was moved or deleted. So, since noone answered my plea for help, I removed the files that needed them and I will release them separately under sf.net (as mentioned above). After doing that, gump stopped puking to the list. I am aware of what gump is and why we use it. But the 2 main build processes I happen to care about are Ant and Maven. Commons Resources has always built fine with both, and the fairly complete tests always pass without issue. Sorry if this seems like a rant, but I am actually more pissed off at myself for being helpless when it comes to gump than I am about someone affecting the build. If I get time, I may research to see if my memory is accurate, because if so I may change my vote to -1. Perhaps you could clarify who the users of this are, and why now is the time to promote it? Right at this moment, there is a very small user base. However, if you consider the thousands of existing and future users of Apache Struts as a good number, then you might change your mind about that -1. Commons Resources is slated (and has been for quite some time) to be used by Struts just as digester, logging, beanutils, etc are now. The home page for resources should have spelled that out for you. http://jakarta.apache.org/commons/sandbox/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging: WeakHashtable
On 18 Nov 2004, at 21:41, Brian Stansberry wrote: custom LogFactory implementations are not very useful at the moment and so i'd be happy just to live with a note in the documentation about this limitation. Sounds good. I'll put some thought to a good note, although it might be a few days. Were you thinking in the Javadoc, or somewhere else? a good note for the javadocs would be excellent. (the content will probably end up in the main documentation but where exactly needs a little thought.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/logging/optional/src/test/org/apache/commons/logging LogFactoryTest.java
rdonkin 2004/11/22 14:50:07
Modified:logging/optional/src/test/org/apache/commons/logging
LogFactoryTest.java
Log:
Improved test cases for WeakHashMap classloading. Contributed by Brian
Stansberry.
Revision ChangesPath
1.3 +146 -96
jakarta-commons/logging/optional/src/test/org/apache/commons/logging/LogFactoryTest.java
Index: LogFactoryTest.java
===
RCS file:
/home/cvs/jakarta-commons/logging/optional/src/test/org/apache/commons/logging/LogFactoryTest.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- LogFactoryTest.java 17 Nov 2004 23:23:21 - 1.2
+++ LogFactoryTest.java 22 Nov 2004 22:50:07 - 1.3
@@ -17,8 +17,11 @@
package org.apache.commons.logging;
+import java.io.ByteArrayOutputStream;
+import java.io.FileNotFoundException;
+import java.io.IOException;
+import java.io.InputStream;
import java.lang.ref.WeakReference;
-import java.util.Hashtable;
import junit.framework.TestCase;
@@ -46,119 +49,97 @@
* Tests that LogFactories are not removed from the map
* if their creating ClassLoader is still alive.
*/
-public void testHoldFactories()
-{
-// Get a factory and create a WeakReference to it that
-// we can check to see if the factory has been removed
-// from LogFactory.properties
-LogFactory factory = LogFactory.getFactory();
-WeakReference weakFactory = new WeakReference(factory);
-
-// Remove any hard reference to the factory
-factory = null;
+public void testHoldFactories() throws Exception
+{
+// 1) Basic test
-// Run the gc, confirming that the original factory
+// Get a weak reference to the factory using the classloader.
+// When this reference is cleared we know the factory has been
+// cleared from LogFactory.factories as well
+WeakReference weakFactory = loadFactoryFromContextClassLoader();
+// Run the gc, confirming that the factory
// is not dropped from the map even though there are
-// no other references to it
-int iterations = 0;
-int bytz = 2;
-while(iterations++ MAX_GC_ITERATIONS) {
-System.gc();
-
-assertNotNull(LogFactory released while ClassLoader still
active.,
- weakFactory.get());
-
-// create garbage:
-byte[] b;
-try {
- b = new byte[bytz];
- bytz = bytz * 2;
-}
-catch (OutOfMemoryError oom) {
-// This error means the test passed, as it means the
LogFactory
-// was never released. So, we have to catch and deal with it
-
-// Doing this is probably a no-no, but it seems to work ;-)
-b = null;
-System.gc();
-break;
-}
-}
+// no other references to it
+checkRelease(weakFactory, true);
+
+// 2) Test using an isolated classloader a la a web app
+
+// Create a classloader that isolates commons-logging
+ClassLoader childLoader = new IsolatedClassLoader(origLoader);
+Thread.currentThread().setContextClassLoader(childLoader);
+weakFactory = loadFactoryFromContextClassLoader();
+Thread.currentThread().setContextClassLoader(origLoader);
+// At this point we still have a reference to childLoader,
+// so the factory should not be cleared
+
+checkRelease(weakFactory, true);
}
-
+
/**
- * Tests that a LogFactory is eventually removed from the map
- * after its creating ClassLoader is garbage collected.
+ * Tests that a ClassLoader is eventually removed from the map
+ * after all hard references to it are removed.
*/
-public void testReleaseFactories()
+public void testReleaseClassLoader() throws Exception
{
-// Create a temporary classloader
-ClassLoader childLoader = new ClassLoader() {};
+// 1) Test of a child classloader that follows the Java2
+//delegation model (e.g. an EJB module classloader)
+
+// Create a classloader that delegates to its parent
+ClassLoader childLoader = new ClassLoader() {};
+// Get a weak reference to the factory using the classloader.
+// When this reference is cleared we know the factory has been
+// cleared from LogFactory.factories as well
cvs commit: jakarta-commons/logging/optional/src/test/org/apache/commons/logging SubDeploymentClass.java
rdonkin 2004/11/22 14:50:25
Added: logging/optional/src/test/org/apache/commons/logging
SubDeploymentClass.java
Log:
Improved test cases for WeakHashMap classloading. Contributed by Brian
Stansberry.
Revision ChangesPath
1.1
jakarta-commons/logging/optional/src/test/org/apache/commons/logging/SubDeploymentClass.java
Index: SubDeploymentClass.java
===
/*
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.logging;
import java.lang.ref.WeakReference;
/**
* Class that mocks a user class deployed in a sub-deployment that
* interacts with LogFactory.
*
* @author bstansberry
*
* @see LogFactoryTest
*/
public class SubDeploymentClass implements IFactoryCreator {
private WeakReference weakFactory = null;
public SubDeploymentClass() {
LogFactory factory = LogFactory.getFactory();
weakFactory= new WeakReference(factory);
}
public WeakReference getWeakFactory() {
return weakFactory;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/logging/optional/src/test/org/apache/commons/logging IFactoryCreator.java
rdonkin 2004/11/22 14:50:51
Added: logging/optional/src/test/org/apache/commons/logging
IFactoryCreator.java
Log:
Improved test cases for WeakHashMap classloading. Contributed by Brian
Stansberry.
Revision ChangesPath
1.1
jakarta-commons/logging/optional/src/test/org/apache/commons/logging/IFactoryCreator.java
Index: IFactoryCreator.java
===
/*
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.logging;
import java.lang.ref.WeakReference;
/**
* Interface implemented by SubDeploymentClass. The LogFactoryTest's
* IsolatedClassLoader will delegate loading of this interface to the
* test runner's classloader, so the test can interact with
* SubDeploymentClass via this interface.
*
* @author bstansberry
*
* @see LogFactoryTest
*/
public interface IFactoryCreator {
WeakReference getWeakFactory();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31286] - Memory leaks in JBoss due to LogFactory cache
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=31286. 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=31286 --- Additional Comments From [EMAIL PROTECTED] 2004-11-22 23:52 --- Nice work. Committed. Many Thanks. I'm happy that this bug can be closed but I will leave it open for a while yet just in case Brian (or anyone else) wants to attach improvements. Robert -- 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
On 19 Nov 2004, at 16:35, Oliver Zeigermann wrote: OK, do not know why but after a while I was just convinced: I will start a vote for a release candicate :) generally, the combination of a noisy, high volume list together with committers who are involved in a variety of projects means that a little bit more formality can help the communication process. the release candidate is also a dry run for the real release. i can definitely recommend fixing showstoppers just before a release than just after :) P.S.: Robert do you have any telepathic skills? ;) sadly, i only look as if i should ;) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/jelly project.xml
On 22 Nov 2004, at 05:38, Dion Gillard wrote: On Mon, 22 Nov 2004 13:00:47 +0800, Brett Porter [EMAIL PROTECTED] wrote: Is there any reason not to modify the inheritence to remove the entity? Just the history of inheritance not quite working. since the commons moved to maven for documentation (and many build), there's been quite a history of pain associated with getting the inheritance to work as we'd like. i think i was probably one of the initiators of the entity based approach as a way round the problems but i've always thought that inheritance was more elegant. brett: if you're around and you think that it should be possible to get the inheritance based approach to work now then maybe we could start looking at moving the commons in general back onto it. (my other pet maven peeve is that every release i have to fiddle around for ages trying to get commit history related stuff to work correctly with an ssh agent.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/jelly project.xml
since the commons moved to maven for documentation (and many build), there's been quite a history of pain associated with getting the inheritance to work as we'd like. Yep - a lot of work was needed in this through the 1.0 release candidates. Is it ok to assume Maven 1.0+ for building? brett: if you're around and you think that it should be possible to get the inheritance based approach to work now then maybe we could start looking at moving the commons in general back onto it. Sure, I'll try this on Jelly as soon as I get a chance, and look at the broader commons if everyone is happy with it. (my other pet maven peeve is that every release i have to fiddle around for ages trying to get commit history related stuff to work correctly with an ssh agent.) This is probably a matter of having changelog use developerConnection (ssh) instead of connection (pserver) when specified and somehow you tell it you are a developer. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/jelly project.xml
On Tue, 23 Nov 2004 07:30:26 +0800, Brett Porter [EMAIL PROTECTED] wrote: since the commons moved to maven for documentation (and many build), there's been quite a history of pain associated with getting the inheritance to work as we'd like. Yep - a lot of work was needed in this through the 1.0 release candidates. Is it ok to assume Maven 1.0+ for building? My only addition would be a 1.0.x release only, no CVS builds. Sure, I'll try this on Jelly as soon as I get a chance, and look at the broader commons if everyone is happy with it. That'd be great. -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/jelly project.xml
Is it ok to assume Maven 1.0+ for building? My only addition would be a 1.0.x release only, no CVS builds. Absolutely. Sure, I'll try this on Jelly as soon as I get a chance, and look at the broader commons if everyone is happy with it. That'd be great. Ok, hopefully should be able to find some time this week. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Chain 1.0
At 3:01 PM -0800 11/21/04, Martin Cooper wrote:
I believe Chain is now sufficiently complete and stable to warrant
an official 1.0 release. There are no outstanding bug reports, and
the component is already in use in a number of projects.
Just now, running maven java:install-snapshot from CVS HEAD, I had
one test failure:
Testsuite: org.apache.commons.chain.impl.CatalogFactoryBaseTestCase
Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 1.141 sec
Testcase:
testPristine(org.apache.commons.chain.impl.CatalogFactoryBaseTestCase):
FAILED
null
junit.framework.AssertionFailedError
at
org.apache.commons.chain.impl.CatalogFactoryBaseTestCase.testPristine(CatalogFactoryBaseTestCase.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
This is probably not critical, as it seems only to be a side effect
of the unpredictable order in which JUnit test cases are executed
when the suite is created by reflection-- it's not as pristine as the
test would have you believe.
This can be fixed by replacing the suite() method with this:
public static Test suite() {
TestSuite suite = new TestSuite();
suite.addTest(new CatalogFactoryBaseTestCase(testPristine));
suite.addTest(new CatalogFactoryBaseTestCase(testDefaultCatalog));
suite.addTest(new CatalogFactoryBaseTestCase(testSpecificCatalog));
return suite;
}
Still, it would be nice for the release itself to be pristine --
maybe someone can fix this before cutting the release?
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
cvs commit: jakarta-commons/io/src/java/org/apache/commons/io FilenameUtils.java
scolebourne2004/11/22 16:04:29
Modified:io/src/test/org/apache/commons/io FilenameUtilsTestCase.java
io/src/java/org/apache/commons/io FilenameUtils.java
Log:
Add methods to handle filename prefixes
Revision ChangesPath
1.20 +166 -6
jakarta-commons/io/src/test/org/apache/commons/io/FilenameUtilsTestCase.java
Index: FilenameUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/io/src/test/org/apache/commons/io/FilenameUtilsTestCase.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- FilenameUtilsTestCase.java31 Oct 2004 00:03:03 - 1.19
+++ FilenameUtilsTestCase.java23 Nov 2004 00:04:29 - 1.20
@@ -113,6 +113,7 @@
public void testNormalize() throws Exception {
String[] src =
{
+null,
,
/,
///,
@@ -129,10 +130,14 @@
/foo/.././bar/,
//foo//./bar,
/../,
-/foo/../../ };
+/foo/../../,
+../foo,
+foo/../../bar,
+foo/../bar };
String[] dest =
{
+null,
,
/,
/,
@@ -149,15 +154,19 @@
/bar/,
/foo/bar,
null,
-null };
+null,
+null,
+null,
+bar };
assertEquals(Oops, test writer goofed, src.length, dest.length);
for (int i = 0; i src.length; i++) {
+String destStr = FilenameUtils.separatorsToSystem(dest[i]);
+String resultStr = FilenameUtils.normalize(src[i]);
assertEquals(
-Check if ' + src[i] + ' normalized to ' + dest[i] + ',
-dest[i],
-FilenameUtils.normalize(src[i]));
+Check if ' + src[i] + ' normalized to ' + destStr + ',
was ' + resultStr + ',
+destStr, resultStr);
}
}
@@ -214,6 +223,46 @@
}
//---
+public void testGetPrefixLength() {
+assertEquals(-1, FilenameUtils.getPrefixLength(null));
+if (WINDOWS) {
+assertEquals(-1,
FilenameUtils.getPrefixLength(1:\\a\\b\\c.txt));
+assertEquals(-1, FilenameUtils.getPrefixLength(1:));
+assertEquals(-1, FilenameUtils.getPrefixLength(1:a));
+assertEquals(-1,
FilenameUtils.getPrefixLength(\\a\\b\\c.txt));
+assertEquals(-1, FilenameUtils.getPrefixLength(a));
+
+assertEquals(0, FilenameUtils.getPrefixLength(a\\b\\c.txt));
+assertEquals(1, FilenameUtils.getPrefixLength(\\a\\b\\c.txt));
+assertEquals(3,
FilenameUtils.getPrefixLength(C:\\a\\b\\c.txt));
+assertEquals(9,
FilenameUtils.getPrefixLength(server\\a\\b\\c.txt));
+
+assertEquals(0, FilenameUtils.getPrefixLength(a/b/c.txt));
+assertEquals(1, FilenameUtils.getPrefixLength(/a/b/c.txt));
+assertEquals(3, FilenameUtils.getPrefixLength(C:/a/b/c.txt));
+assertEquals(9,
FilenameUtils.getPrefixLength(//server/a/b/c.txt));
+
+assertEquals(0, FilenameUtils.getPrefixLength(~/a/b/c.txt));
+assertEquals(0,
FilenameUtils.getPrefixLength(~user/a/b/c.txt));
+} else {
+assertEquals(-1, FilenameUtils.getPrefixLength(~));
+assertEquals(-1, FilenameUtils.getPrefixLength(~user));
+
+assertEquals(0, FilenameUtils.getPrefixLength(a/b/c.txt));
+assertEquals(1, FilenameUtils.getPrefixLength(/a/b/c.txt));
+assertEquals(2, FilenameUtils.getPrefixLength(~/a/b/c.txt));
+assertEquals(6,
FilenameUtils.getPrefixLength(~user/a/b/c.txt));
+
+assertEquals(0, FilenameUtils.getPrefixLength(a\\b\\c.txt));
+assertEquals(1, FilenameUtils.getPrefixLength(\\a\\b\\c.txt));
+assertEquals(2, FilenameUtils.getPrefixLength(~\\a\\b\\c.txt));
+assertEquals(6,
FilenameUtils.getPrefixLength(~user\\a\\b\\c.txt));
+
+assertEquals(0,
FilenameUtils.getPrefixLength(C:\\a\\b\\c.txt));
+assertEquals(1,
FilenameUtils.getPrefixLength(server\\a\\b\\c.txt));
+}
+}
+
public void testIndexOfLastSeparator() {
assertEquals(-1, FilenameUtils.indexOfLastSeparator(null));
assertEquals(-1,
FilenameUtils.indexOfLastSeparator(noseperator.inthispath));
@@
Re: [io] Filename prefixes
From: Tim O'Brien [EMAIL PROTECTED] What happens to getExtension() when there is no . character? Then there is no extension, returns . what is there are multiple ., are you thinking name.substring( name.lastIndexOf( . ) + 1 )? Yes What does getPrefix() return on Unix? Nothing? absolute paths have a prefix of / user directory paths are also a prefix (see lower down email) The basic code is now checked in. I am currently only looking for windows prefixes on windows, and unix prefixes on unix. Should this be extended/simplified to look for all prefixes in all cases??? ie. on a PC running windows, should ~user/ be matched as a prefix I think it probably should now I've coded it the other way... Stephen -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Sunday, November 21, 2004 7:18 PM To: Jakarta Commons Developers List Subject: Re: [io] Filename prefixes Basically it looks like we'll need: getPrefix() - C:\ getPath() - dev\project getFullPath() - C:\dev\project getName() - file.txt getExtension() - txt (input C:\dev\project\file.txt) Normalize/catPath can then use the other methods to stitch together a result. Naming: catPath() should be renamed to concat() getFullPath()/getPath() - are these logical names? Stephen - Original Message - From: Martin Cooper [EMAIL PROTECTED] On Mon, 22 Nov 2004 01:03:28 -, Stephen Colebourne [EMAIL PROTECTED] wrote: In order to write the normalize() method properly, I realised that we have to deal with filename prefixes properly. The point being that you can't .. up into a filename prefix. Here's the javadoc for the method I'm writing. Does this cover the cases? Looks good to me. I can't think of any other options, at least for Windows and Unix. -- Martin Cooper /** * Returns the length of the filename prefix, such as codeC://code or code~//code. * p * This method will handle a file in either Unix or Windows format. * The prefix includes the first slash in the full filename. * pre * Windows: * a\b\c.txt -- -- relative * \a\b\c.txt -- \ -- drive relative * C:\a\b\c.txt-- C:\ -- absolute * \\server\a\b\c.txt -- \\server\ -- UNC * * Unix: * a/b/c.txt -- -- relative * /a/b/c.txt -- / -- absolute * ~/a/b/c.txt -- ~/-- current user relative * ~user/a/b/c.txt -- ~user/-- named user relative * /pre * * @param filename the filename to find the prefix in, null returns -1 * @return the length of the prefix, -1 if invalid or null */ Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32350] New: - [chain] Consider making lookup commands default to same chain
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=32350. 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=32350 Summary: [chain] Consider making lookup commands default to same chain Product: Commons Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: chain AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've just now started looking at some of the changes related to the CatalogFactory implementations. I find the need to specify a catalog in the lookup commands clumsy and counter-intuitive. It seems to me one should be able to assume that lookups would be relative to other commands -- specifically for the LookupCommand, but in struts-chain the ExceptionCatcher command would also benefit. Yes, you have the issue then of how one specifies that the command to be looked up is in the default catalog, but I suspect that in reality the annoyance of someone forgetting to specify the catalogName until there's an error will happen much more than the need to specify look this up in an entirely different catalog and specifically the one-which-has-no-name Perhaps a boolean property defaultCatalog or a reserved catalog name like DEFAULT_CATALOG ? I'd be happy to provide a patch, but first -- will people support this change or veto it? -- 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Chain 1.0
Martin Cooper wrote: I believe Chain is now sufficiently complete and stable to warrant an official 1.0 release. There are no outstanding bug reports, and the component is already in use in a number of projects. The plan is to release HEAD as Commons Chain 1.0 on completion of a successful vote. I will be the release manager. --- [X] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my own +1. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32350] - [chain] Consider making lookup commands default to same chain
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=32350. 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=32350 --- Additional Comments From [EMAIL PROTECTED] 2004-11-23 02:12 --- I like the thinking behind this idea (avoid mistakes, and avoid double specification of things :-) -- but how would a given Lookup command instance know what catalog it, or its owning chain, was looked up in (if any)? I don't think we have any API for that at the moment. -- 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32350] - [chain] Consider making lookup commands default to same chain
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=32350. 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=32350 --- Additional Comments From [EMAIL PROTECTED] 2004-11-23 03:45 --- Well, I suppose to do it right would involve a few more changes than I thought at first: Command: public void setCatalog(Catalog) Command: public void release() Catalog: public void release() CatalogFactory: public void release() Then the CatalogFactory.clear() method would call release on all its catalogs before clearing the map, giving the command a chance to clear the circular reference back to its catalog. Not as lightweight as it first seemed. Is it worth it? -- 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Commons Jelly 1.0 Release Candidate 1 released.
The commons-jelly team is pleased to announce the commons-jelly 1.0-RC1 release! http://jakarta.apache.org/commons/jelly/ Jelly is a Java and XML based scripting engine. Jelly combines the best ideas from JSTL, Velocity, DVSL, Ant and Cocoon all together in a simple yet powerful scripting engine. Changes in this version include: New Features: o Add Regexp taglib Issue: JELLY-49. Fixed bugs: o Huge memory leak resulting from the use of ThreadLocal. Issue: JELLY-148. Thanks to Hans Gilde. o Character data is flushed by XMLOuput while XML data isn't. Issue: JELLY-138. o Scripts set the context URL when executing so that resources are found relative to the current script. Issue: JELLY-45. Changes: o Move to beanutils 1.7.0. -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32350] - [chain] Consider making lookup commands default to same chain
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=32350. 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=32350 --- Additional Comments From [EMAIL PROTECTED] 2004-11-23 05:25 --- I don't think so ... especially given that we currently don't require separate Command instances to be used in different chains either :-(. -- 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Created: (JELLY-163) Allow Expressions to throw exceptions
Paul,
For most tags, expressions are evaluated at runtime, but immediately before
the tag itself becomes aware of them. They're evaluated by the enclosing
TagScript (a Script that runs a Tag) immediately before the tag itself is
run. The tag just knows about the result of the expression, not the actual
evaluation.
An exception at this time could be caught by the enclosing tag, but not by
the tag that should have received the expression. So, there's currently no
generic way to have a tag say don't worry about expression evaluation
failures, just show me the contents/null/whatever.
Your example would work fine, the exception would be thrown out of the
script or could be caught by an enclosing tag.
Hans
-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
Sent: Monday, November 15, 2004 5:14 AM
To: Jakarta Commons Developers List
Subject: Re: [jira] Created: (JELLY-163) Allow Expressions to throw
exceptions
Hans,
I think this is exactly what made me stumble... I don't really get
this...
(I'm again about my fuzzyness of understanding jelly lifecycle... sorry
for this!). I see two times where such an exception can occur:
- at compilation time. This should be the same when a tag would meet
unknown attributes or a (strict) taglib would meet an unknown tag.
- at execution time, when the expression should return something
(maybe).
In both cases, the exception should be thrown and wrapped into some
generic exception which should include location information.
My current attempt was the script:
j:jelly xmlns:j=jelly:core
j:set var=b value=blop/
${b-'b'}
/j:jelly
Which did throw me an exception (as I instructed it) but which was not
caught, or wrapped...
In which of the two phases should such a thing be caught ?
Are there other phases ?
thanks
paul
Le 15 nov. 04, à 02:32, Hans Gilde (JIRA) a écrit :
Expressions are evaluated before the tag is run, so it normally
wouldn't know anything about them.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31286] - Memory leaks in JBoss due to LogFactory cache
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=31286. 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=31286 --- Additional Comments From [EMAIL PROTECTED] 2004-11-23 07:45 --- Created an attachment (id=13519) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13519action=view) Javadoc for WeakHashtable Attached adds some class level Javadoc to WeakHashtable that tries to explain the classloading situation where a call to release() is still needed. There's some other stuff that I'd like to do on this (perhaps use simple strong references for values in WeakHashtable; refactor LogFactoryTest and LoadTest to avoid code duplication), but they don't affect the functionality, and it will probably be a while before a can get to them. -- 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
