DO NOT REPLY [Bug 33554] New: - [commons-launcher] Print targest instead of usage
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=33554. 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=33554 Summary: [commons-launcher] Print targest instead of usage Product: Commons Version: Nightly Builds Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: Sandbox AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] It would be more usable for end-user, if commons-launcher would print a list of targets on missing or wrong targets. It would be probably the best, if the target-name and (if available) the description of the targets are printed on console. Something like: Error: xxx is not a valid target Usage: myApp [options] [-] target [-Dname=value...] [-] [application arguments...] where options include: target: a do something A b do something B c do something B -help Print this usage statement -launchfile file The XML file to use (the default is launcher.xml) -executablename name The executable name to print in this usage statement -verbosePrint stack traces with error messages Probably the flags -launchfile, -executablename and -verbose could then also be hidden for productive systems. BTW, there is no component launcher in the component list. So I assigned it to sandbox. -- 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 33384] - [beanutils] add protected accessor to fundamental map in BeanUtils project
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=33384. 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=33384 --- Additional Comments From [EMAIL PROTECTED] 2005-02-14 09:24 --- (In reply to comment #1) Hi Marc Hi Robert. Changing access to members means that future changes will be limited by backwards compatibility. So, it's wiser to consider carefully before executing these changes. You're right. In my point of view, BeanUtils is a great tool box, and I'm not daring to modify it. I realize it's a Jakarta corner-stone. But I think it will be very usefull to allow some external extension _without_ modifying BeanUtils core. That what I've done for myself (see http://issues.apache.org/bugzilla/show_bug.cgi?id=33352). What would be useful is knowing what members you needed access to and a description of the use case (why you needed access to them). For doing the job above, I've created extendedtypePropertyDescriptor (where type=,Indexed,Mapped) upon javaBeans and Beanutils propertyDescriptors. These descriptors have a added MethodRegistery to link property to some adders or removers (and so on). They're just subclass of usual typePropertyDescriptors and do as well as them, so they're validating instanceof contract used in PropertyBeanUtils. In my ExtendedPropertyUtilsBean (what a crowing I am :), I do caching in a second descriptorsCache (guess ? extendedDescriptorCache of course :) and I override 'public PropertyDescriptor[] getPropertyDescriptors(Class beanClass)' to access to extended cache or usual cache. It works : my extension is sucessfull in several standard beanutils unit tests, and are behaving as PropertyUtilsBean for features as settypeProperty(...), gettypeProperty and so on. But I'm woried because of it makes redundant caches. For BeanUtils, it doesn't matter that used propertyDescriptor is a usual one or an extended one, because of resolution contract is an instanceof one. If I could, and some other peoples I think, take the risk to do some substutions directly in propertyCache, it could be available to extends for some custom purpose Beanutils without busting BeanUtils core, and offer to users some new compatible features in serenity for core users. So in my opinions, it just need to set propected access to propertyCache and MappedPropertyCache in PropertyBeanUtils and some usefull methods as findNextNestedIndex(String). I could be mistaken, but in my opinion it's not busting changes, they don't put in jeopardy beanUtils backward combatibility, and if it does, Ok, just advertise people in javadoc they're using these methods to their own risk. A little risk for a great extra no ? Robert Marc -- 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 33384] - [beanutils] add protected accessor to fundamental map in BeanUtils project
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=33384. 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=33384 --- Additional Comments From [EMAIL PROTECTED] 2005-02-14 09:27 --- (In reply to comment #2) /.../ So in my opinions, it just need to set propected access to propertyCache and MappedPropertyCache in PropertyBeanUtils and some usefull methods as findNextNestedIndex(String). I'm talking about protected methods access of course, no protected members. Marc -- 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 33548] - [collections] CaseInsensitiveMap performance optimization suggestion
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=33548. 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=33548 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement Summary|CaseInsensitiveMap |[collections] |performance optimization|CaseInsensitiveMap |suggestion |performance optimization ||suggestion -- 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 33554] - [launcher] Print targest instead of usage
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=33554. 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=33554 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows XP |All Platform|PC |All Summary|[commons-launcher] Print|[launcher] Print targest |targest instead of usage|instead of usage -- 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 33553] - [configuration] Cache DatabaseConfiguration values for higher performance
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=33553. 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=33553 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Cache DatabaseConfiguration |[configuration] Cache |values for higher |DatabaseConfiguration values |performance |for higher performance --- Additional Comments From [EMAIL PROTECTED] 2005-02-14 10:16 --- Adding a cache to DatabaseConfiguration is a good idea. However I'm not sure I would rely solely on the cache for some operations like isEmpty() or containsKey(). The cache should be first checked, and then the database should be queried if necessary. Checking if the cache is empty isn't enough to make sure the configuration is empty. Just out of curiosity, why did you change the private members to final ? -- 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]
svn commit: r153757 - in jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/DataConfiguration.java test/org/apache/commons/configuration/TestDataConfiguration.java test/org/apache/commons/configuration/TestPropertyConverter.java
Author: ebourg
Date: Mon Feb 14 02:03:35 2005
New Revision: 153757
URL: http://svn.apache.org/viewcvs?view=revrev=153757
Log:
Fixed getLongArray(), getFloatArray() and getDoubleArray() in DataConfiguration
(Bug 33524)
Changed getXXXArray() and getXXXList() to return an empty array/list for empty
values
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestPropertyConverter.java
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java?view=diffr1=153756r2=153757
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java
Mon Feb 14 02:03:35 2005
@@ -30,6 +30,7 @@
import org.apache.commons.collections.CollectionUtils;
import org.apache.commons.lang.ArrayUtils;
+import org.apache.commons.lang.StringUtils;
/**
* Decorator providing additional getters for any Configuration. This extended
@@ -41,7 +42,7 @@
* version./p
*
* @author a href=[EMAIL PROTECTED]Emmanuel Bourg/a
- * @version $Revision: 1.2 $, $Date: 2004/12/02 22:05:52 $
+ * @version $Revision: 1.2 $, $Date$
* @since 1.1
*/
public class DataConfiguration extends AbstractConfiguration
@@ -131,7 +132,7 @@
List list = null;
-if (value == null)
+if (value == null || (value instanceof String
StringUtils.isEmpty((String) value)))
{
list = defaultValue;
}
@@ -207,7 +208,7 @@
boolean[] array;
-if (value == null)
+if (value == null || (value instanceof String
StringUtils.isEmpty((String) value)))
{
array = defaultValue;
}
@@ -281,7 +282,7 @@
List list = null;
-if (value == null)
+if (value == null || (value instanceof String
StringUtils.isEmpty((String) value)))
{
list = defaultValue;
}
@@ -356,7 +357,7 @@
byte[] array;
-if (value == null)
+if (value == null || (value instanceof String
StringUtils.isEmpty((String) value)))
{
array = defaultValue;
}
@@ -430,7 +431,7 @@
List list = null;
-if (value == null)
+if (value == null || (value instanceof String
StringUtils.isEmpty((String) value)))
{
list = defaultValue;
}
@@ -505,7 +506,7 @@
short[] array;
-if (value == null)
+if (value == null || (value instanceof String
StringUtils.isEmpty((String) value)))
{
array = defaultValue;
}
@@ -580,7 +581,7 @@
List list = null;
-if (value == null)
+if (value == null || (value instanceof String
StringUtils.isEmpty((String) value)))
{
list = defaultValue;
}
@@ -655,7 +656,7 @@
int[] array;
-if (value == null)
+if (value == null || (value instanceof String
StringUtils.isEmpty((String) value)))
{
array = defaultValue;
}
@@ -729,7 +730,7 @@
List list = null;
-if (value == null)
+if (value == null || (value instanceof String
StringUtils.isEmpty((String) value)))
{
list = defaultValue;
}
@@ -804,7 +805,7 @@
long[] array;
-if (value == null)
+if (value == null || (value instanceof String
StringUtils.isEmpty((String) value)))
{
array = defaultValue;
}
@@ -825,7 +826,7 @@
Iterator it = values.iterator();
while (it.hasNext())
{
-array[i++] = PropertyConverter.toLong(it.next()).intValue();
+array[i++] = PropertyConverter.toLong(it.next()).longValue();
}
}
else
@@ -834,7 +835,7 @@
{
// attempt to convert a single value
array = new long[1];
-array[0] = PropertyConverter.toLong(value).intValue();
+array[0] = PropertyConverter.toLong(value).longValue();
}
catch (ConversionException e)
{
@@ -878,7 +879,7 @@
List list = null;
-if (value == null)
+if (value == null || (value instanceof String
StringUtils.isEmpty((String) value)))
{
list = defaultValue;
}
DO NOT REPLY [Bug 33520] - [configuration] DataConfiguration.getXXXArray() fails on empty values
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=33520. 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=33520 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-14 11:04 --- Patch applied -- 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 33524] - [configuration] Wrong primitive conversion in DataConfiguration
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=33524. 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=33524 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-14 11:04 --- Patch applied -- 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]
jsvc on Linux: multiple instances possible, why -pidfile?
Hi, I created multiple jsvc instances that did not die. That happens with the adapted Tomcat5.sh supplied with the Tomcat 5.5 distribution. That's a problem. I would appreciate some help in understanding the logic of the pid file. This is my view of things; please correct me and help me if I am wrong: If, as it is presently the case, jsvc creates a pid file, then it must not be possible for jsvc to launch a second copy of a service. jsvc should however be able to briefly run only itself as multiple instances - it must be allowed to do so in order to check the pid file. It would not be reliable to pass this responsibility to the OS. So any jsvc copy on top of the first should exit with an error condition, and it should not attempt to start the jvm with the server. If jsvc is NOT designed to block multiple service instances, then it must not write the PID file. In that case it would be the responsibility of the script to write the pid file and block multiple service instances. What to do? Many thanks, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153777 - jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestPropertyConverter.java
Author: ebourg
Date: Mon Feb 14 03:54:15 2005
New Revision: 153777
URL: http://svn.apache.org/viewcvs?view=revrev=153777
Log:
Removed a temporary test that wasn't supposed to be commited :)
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestPropertyConverter.java
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestPropertyConverter.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestPropertyConverter.java?view=diffr1=153776r2=153777
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestPropertyConverter.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestPropertyConverter.java
Mon Feb 14 03:54:15 2005
@@ -71,8 +71,4 @@
assertEquals(3rd element, new Integer(3), it.next());
}
-public void testToLong()
-{
-assertEquals(81008931800 to long, 81008931800L,
PropertyConverter.toLong(81008931800).longValue());
-}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester2] Additions
Hi Oliver, On Mon, 2005-02-14 at 08:16 +0100, Oliver Zeigermann wrote: [update] - now all member variables of DefaultRuleManager are private - introduced copy ctor for copying members from subclasses thanks - that looks good to me. - DefaultRuleManager now returns an unmodifiable list upon getMatchingActions I'm not so sure about this one. This change means a new object is created each time getMatchingActions is called, and that is once for every xml element in the input document. And in addition, each method call is relayed by the UnmodifiableList wrapper to the underlying one, resulting in a performance hit too. Is this significant in the context of parsing an xml document? I don't know; maybe it's not measurable. However the benefits of this change are really limited only to preventing bad code in SAXHandler or RuleManager classes. Cases where users write their own versions of those will be extremely rare. And mistakes in the core digester classes are, I think, likely to be picked up by our unit tests. So my current feeling is that while the above change **is theoretically correct**, I would leave it out and return the actual list, just documenting that it should be treated as unmodifiable. Comments? - created a new FallbackRuleManager class that only takes care about fallback actions [see my comments at end first!] Have you considered writing this class as a *decorator* rather than a subclass of DefaultRuleManager? If it was a decorator, it could then be applied to any rulemanager class, not just the default. It would be used as follows: RuleManager realrm = new DefaultRuleManager(); // or any other type RuleManager rm = new FallbackRuleManagerDecorator(realrm); Digester digester = new Digester(rm); The disadvantage would be that it would be necessary to implement each of the RuleManager methods in order to forward them to the decorated instance, together with the performance hit that would entail. [ah, if only this were Ruby] - SupplementaryRuleManager now takes account of the explicitely unmodifiable list returned by DefaultRuleManager and does a wild mixture of caching and concatenating the list returned from DefaultRuleManager and its own list of supplementary actions [see my comments at end first!] The ReadOnlyConcatList is cute. I don't think it would save any time or effort over List list = new ArrayList(l1.size() + l2.size()); list.appendAll(l1); list.appendAll(l2); but I guess the unmodifiable feature is thrown in for free. I've been thinking about the caching and see a mild problem. If wildcard pattern a (equivalent to */a in digester1), and a elements are scattered around in various places in the input document, then the cache is going to grow fairly large. So basically, whether caching improve things or not depends upon whether the input xml is simple and repetitive (caching wins) or reasonably unstructured (caching loses). And given we can't tell which is more likely over the set of digester users (at least I don't have a clue) I would probably prefer the simplest solution - not to cache. I'm also thinking about the possibility that we may move to a RuleManager style that matches based on much richer state than just the current path. FOr example, if we want to support patterns like this: /foo/[EMAIL PROTECTED]'me']/baz[pos()==last()][1] then getMatchingActions will definitely not be taking a String path any more, but instead an array of w3c.dom.Element objects or similar so it has sufficient info to decide whether the pattern matches or not. That won't affect many places in the code, but would make this caching impossible to implement so we'd have to take it out then anyway. [1] sorry my xpath is a bit rusty - this is probably not valid - Both FallbackRuleManager and SupplementaryRuleManager now can have several callback actions - Still docs and tests need improvement - will do so once the code seems somewhat stable Comments? You're probably going to hit me for this :-) After some thought, I think my preferred option would be to include fallback and supplementary features as standard, ie define them in the RuleManager interface, provide an implementation in the DefaultRuleManager class, and to remove the FallbackRuleManager and SupplementaryRuleManager classes completely. I've always said I'm happy for fallback features to be in DefaultRuleManager, and after thought I believe it ought to be defined as part of the main RuleManager interface. And as you're so keen for supplementary actions, I'm ok with adding them too as long as there is no performance hit for people who don't use them. Note that this would definitely be the easiest solution from the user point of view, with no special classes required in order to use supplementary actions. And I would go for the simplest implementation of supplementary actions, by simply creating a new list each time getMatchingActions is called when one or more supplementary actions are
Re: [Subversion] Revision Keyword
Simon Kitching wrote: And you can get subversion commands to ignore certain files by setting the global-ignores entry in ~/.subversion/config. I have the following: [miscellany] global-ignores = *.o *.lo *.la .*~ *~ .#* *.class .*.marks I believe it's much safer in the long run to do this in the repository folder properties than relying on client-side configuration (although it's probably best to do the first and recommend the second to all users). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCL problems
Robert, I am a bit surprised by your question. As the current release manager for JCL, I suppose that you are aware that LogFactoryImpl only uses the thread context class loader (TCCL) to search for classes. You were aware of that, weren't you? In theory, this is supposed to let a copy of commons-logging.jar placed in a parent class loader to discover another logging API, say log4j, whose classes are visible to a child class loader with the child loader also set to be the TCCL. However, this dynamic discovery does not work. The copy of log4j.jar must be placed next to commons-logging.jar. Moreover, the copy of commons-logging.jar must be placed very high in the class loader tree, say in the system class loader or the application server's class loader, but that is not all. There must not be other copies of commons-logging.jar in war files of web-apps. To cut a long story short, do to anything meaningful reliably, JCL is a lot more complicated to set and even when set up correctly brings no benefits when compared to static API binding as found in UGLI. I urge you run though the examples in [1] which should demonstrate to you how badly and irreparably JCL is broken. The source code is all there. Even if you don't trust my opinion, at least trust your java compiler and your JVM. [1] http://www.qos.ch/logging/classloader.jsp At 08:50 PM 2/13/2005, robert burrell donkin wrote: (i'm not sure whether i'm missing your point.) it seems to me that it matters not whether the discovery is dynamic or static: the log4j library needs to be available in the classloader. static discovery would break in a similar fashion if a required library is not present. from a practical perspective, i don't really see having to put a number of libraries together so that they are loaded by the same classloader is really a restriction. what matters is that there are ways to achieve the required results and definite instructions are available which are easy for deployers to understand. - robert -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] discovery error handling
At 05:59 PM 2/13/2005, robert burrell donkin wrote: Anyway, before camouflaging errors occurring during Logger retrieval, I'd recommend that you fix the bug exposed by Example 2 in my analysis [1]. In my opinion it cannot be fixed without a major redesign and overhaul of JCL, but maybe I am wrong... this general issued was discussed earlier. i suspect that it would be possible to improve the situation in JCL1 but richard's more sceptical and seems keener to push straight towards JCL2. i think that there's some danger that momentum is starting to slip away so i'm probably not going to look at fix the issue in the 1.0.x stream right now. Does this mean that JCL won't be fixed anytime soon? :-( - robert -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33561] New: - [logging] Need Log.close method
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=33561. 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=33561 Summary: [logging] Need Log.close method Product: Commons Version: 1.0.4 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P2 Component: Logging AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I can't see a way to tell Commons Logging to close a log. There is LogFactory.release(), but it is specified only as releasing references. This is causing me a problem when using Logging with log4j's TelnetAppender. Because I can't shut down the logging, the appender never closes down its sockets; this prevents my application from exiting 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33553] - [configuration] Cache DatabaseConfiguration values for higher performance
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=33553. 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=33553 --- Additional Comments From [EMAIL PROTECTED] 2005-02-14 15:48 --- I'm working on a refresh approach like what is done for properties. With that, then the cache will always be at most x seconds older than the database, so my hope is that the querying the cache will be sufficient. What I might do is take and refactor out the real logic of isEmpty etc to the strategey. Have one strategy which always queries the database, one strategy which uses a cache and refreshes etc. The downside there is it kinda kills my idea of having a generic reloading strategy which could be used for xml, properties files and database. Perhaps that's just a pipe dream. :-) As far as the finals go, that's something I always do with instance variables which are set in the constructor and then never change. It has two advantages: 1) compiler makes sure that I initialize the fields before use and 2) compiler can apply optimizations (inining, direct memory access etc.) Also, with the default settings for checkstyle which I've kinda gotten ingrained in me now, checkstyle recommends setting those puppies to final. :-) -- 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: [logging] discovery error handling
It means a fix will be made available as part of the next phase. ras *** Richard A. Sitze IBM WebSphere WebServices Development Ceki Gülcü [EMAIL PROTECTED] wrote on 02/14/2005 06:20:14 AM: At 05:59 PM 2/13/2005, robert burrell donkin wrote: Anyway, before camouflaging errors occurring during Logger retrieval, I'd recommend that you fix the bug exposed by Example 2 in my analysis [1]. In my opinion it cannot be fixed without a major redesign and overhaul of JCL, but maybe I am wrong... this general issued was discussed earlier. i suspect that it would be possible to improve the situation in JCL1 but richard's more sceptical and seems keener to push straight towards JCL2. i think that there's some danger that momentum is starting to slip away so i'm probably not going to look at fix the issue in the 1.0.x stream right now. Does this mean that JCL won't be fixed anytime soon? :-( - robert -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester2] Additions
On Tue, 15 Feb 2005 01:08:53 +1300, Simon Kitching [EMAIL PROTECTED] wrote: - DefaultRuleManager now returns an unmodifiable list upon getMatchingActions I'm not so sure about this one. This change means a new object is created each time getMatchingActions is called, and that is once for every xml element in the input document. And in addition, each method call is relayed by the UnmodifiableList wrapper to the underlying one, resulting in a performance hit too. Is this significant in the context of parsing an xml document? I don't know; maybe it's not measurable. However the benefits of this change are really limited only to preventing bad code in SAXHandler or RuleManager classes. Cases where users write their own versions of those will be extremely rare. And mistakes in the core digester classes are, I think, likely to be picked up by our unit tests. So my current feeling is that while the above change **is theoretically correct**, I would leave it out and return the actual list, just documenting that it should be treated as unmodifiable. Well, think of the situation where people inherit and do things like I have done on my first try. So, I would be all for keeping it in, but would not protest if you removed it. - created a new FallbackRuleManager class that only takes care about fallback actions [see my comments at end first!] Have you considered writing this class as a *decorator* rather than a subclass of DefaultRuleManager? If it was a decorator, it could then be applied to any rulemanager class, not just the default. It would be used as follows: RuleManager realrm = new DefaultRuleManager(); // or any other type RuleManager rm = new FallbackRuleManagerDecorator(realrm); Digester digester = new Digester(rm); The disadvantage would be that it would be necessary to implement each of the RuleManager methods in order to forward them to the decorated instance, together with the performance hit that would entail. [ah, if only this were Ruby] - SupplementaryRuleManager now takes account of the explicitely unmodifiable list returned by DefaultRuleManager and does a wild mixture of caching and concatenating the list returned from DefaultRuleManager and its own list of supplementary actions [see my comments at end first!] The ReadOnlyConcatList is cute. I don't think it would save any time or effort over List list = new ArrayList(l1.size() + l2.size()); list.appendAll(l1); list.appendAll(l2); but I guess the unmodifiable feature is thrown in for free. ReadOnlyConcatList certainly would be faster and have a smaller memory footprint. I've been thinking about the caching and see a mild problem. If wildcard pattern a (equivalent to */a in digester1), and a elements are scattered around in various places in the input document, then the cache is going to grow fairly large. So basically, whether caching improve things or not depends upon whether the input xml is simple and repetitive (caching wins) or reasonably unstructured (caching loses). And given we can't tell which is more likely over the set of digester users (at least I don't have a clue) I would probably prefer the simplest solution - not to cache. If the cache gets too large we can easily limit its size using LRUMap or something. I'm also thinking about the possibility that we may move to a RuleManager style that matches based on much richer state than just the current path. FOr example, if we want to support patterns like this: /foo/[EMAIL PROTECTED]'me']/baz[pos()==last()][1] then getMatchingActions will definitely not be taking a String path any more, but instead an array of w3c.dom.Element objects or similar so it has sufficient info to decide whether the pattern matches or not. That won't affect many places in the code, but would make this caching impossible to implement so we'd have to take it out then anyway. We can worry about this as soon as getMatchingActions takes anything else than a String. Right now the method signature that I implemented says it is a String, so there is no problem. You're probably going to hit me for this :-) I can't, you are too far away ;) After some thought, I think my preferred option would be to include fallback and supplementary features as standard, ie define them in the RuleManager interface, provide an implementation in the DefaultRuleManager class, and to remove the FallbackRuleManager and SupplementaryRuleManager classes completely. I've always said I'm happy for fallback features to be in DefaultRuleManager, and after thought I believe it ought to be defined as part of the main RuleManager interface. And as you're so keen for supplementary actions, I'm ok with adding them too as long as there is no performance hit for people who don't use them. Note that this would definitely be the easiest solution from the user point of view, with no special classes required in order to
Re: [validator] Most tests are failing
All of the tests pass for me after you applied the latest patch. Thanks! David --- Niall Pemberton [EMAIL PROTECTED] wrote: David, It is failing because of the changes I rolled back for Field - I didn't roll back the associated change to Arg. Sorry about that, I did think Iwas going to be applying a solution for Bug 31194 at the end of last year. I have it all ready to go (I've just attached a patch showing what I'm currently proposing to the bugzilla ticket). http://issues.apache.org/bugzilla/show_bug.cgi?id=31194 My preference is to apply the latest change I've put forward and that should resolve 31194 and the problems you're having with testing. If you don't want to or don't have time to consider this and want me to hold off - I can revert back the changes to Arg. It would be good IMO to put 31194 to bed, but let me know. Niall - Original Message - From: David Graham [EMAIL PROTECTED] Sent: Saturday, February 12, 2005 8:52 PM Thanks Niall. Once all the tests pass I can commit some minor changes I'm working on. David --- Niall Pemberton [EMAIL PROTECTED] wrote: This is may be because I rolled back the changes to Field for Bug 31194 http://issues.apache.org/bugzilla/show_bug.cgi?id=31194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[bugzilla admin] add launcher to component list
Please add launcher to component list Thanks in advance Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33554] - [launcher] Print targest instead of usage
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=33554. 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=33554 --- Additional Comments From [EMAIL PROTECTED] 2005-02-14 18:32 --- Can you provide a patch? There is not a lot of developer activety around commons-launcher so providing a patch yourself if the best way to get this implemented. Send mail to commons-dev if you want to discuss this. -- 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: [bugzilla admin] add launcher to component list
Done. -- Martin Cooper On Mon, 14 Feb 2005 18:27:50 +0100, Dirk Verbeeck [EMAIL PROTECTED] wrote: Please add launcher to component list Thanks in advance Dirk - 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 33561] - [logging] Need Log.close method
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=33561. 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=33561 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-02-14 18:52 --- This is an issue best solved by deployment code rather than application code. It is very easy to come up with scenarios where JCL closing a log would have detrimental effects. The deployer of the application has made the choice to deploy a configuration of a particular logging system which needs to be closed in a particular fashion. The deployer should therefore add the appropriate lifecycle code to shutdown the appropriate Log4J repository to the deployment. -- 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 33554] - [launcher] Print targest instead of usage
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=33554. 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=33554 [EMAIL PROTECTED] changed: What|Removed |Added Component|Sandbox |Launcher -- 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 17957] - [launcher] - on OutOfMemoryError no message
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=17957. 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=17957 [EMAIL PROTECTED] changed: What|Removed |Added Component|Sandbox |Launcher -- 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]
svn commit: r153822 - in jakarta/commons/sandbox/i18n/trunk/xdocs: navigation.xml quickstart.xml
Author: dflorey
Date: Mon Feb 14 10:22:59 2005
New Revision: 153822
URL: http://svn.apache.org/viewcvs?view=revrev=153822
Log:
Added download page generation
Modified:
jakarta/commons/sandbox/i18n/trunk/xdocs/navigation.xml
jakarta/commons/sandbox/i18n/trunk/xdocs/quickstart.xml
Modified: jakarta/commons/sandbox/i18n/trunk/xdocs/navigation.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/xdocs/navigation.xml?view=diffr1=153821r2=153822
==
--- jakarta/commons/sandbox/i18n/trunk/xdocs/navigation.xml (original)
+++ jakarta/commons/sandbox/i18n/trunk/xdocs/navigation.xml Mon Feb 14 10:22:59
2005
@@ -6,8 +6,6 @@
menu name=Commons#xA0;I18n
item name=Overview href=/index.html /
item name=Getting started
href=/quickstart.html /
-item name=API#xA0;Documentation
href=/apidocs/index.html/
-item name=Downloads href=/downloads.html/
/menu
common-menus;
/body
Modified: jakarta/commons/sandbox/i18n/trunk/xdocs/quickstart.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/xdocs/quickstart.xml?view=diffr1=153821r2=153822
==
--- jakarta/commons/sandbox/i18n/trunk/xdocs/quickstart.xml (original)
+++ jakarta/commons/sandbox/i18n/trunk/xdocs/quickstart.xml Mon Feb 14 10:22:59
2005
@@ -15,39 +15,6 @@
pTo get started you need at least the jar of this component and the
dependent codexmlio-x.x.jar/code for reading
xml documents in your classpath./p
/section
-section name=NEW: Pluggable message providers
-pSince version 0.3 of this component you can add your own custom message
providers./p
-pThis is a big plus if you already have your localized messages in a
database for example.
- You do not have to convert them into the supported XML or
property-based format, but you
- can write a simple codeMessageProvider/code by implementing a
single method and plug it in./p
-/section
-section name=NEW: ResourceBundle based message provider added
- pA new message provider made it into this component: The
codeResourceBundleMessageProvider/code.
- This one enables you to keep your property files that may
contain localized messages./p
- pYou can group entries messages by adding the key at the end of the
existing message key. The
- following example shows how a property file should look like to
work as the following XML example:/p
-pAs you know you'll need two files, each containing the messages for a
specific locale. This one might be
- the default one calld myMessages.properties:/p
- source
-welcome.text=Welcome
-usage.title=Usage
-usage.text=The application requires the following parameters:
-validationFailed.title=Parameter {0} invalid
-validationFailed.text=The given value of the parameter {0} is invalid
-validationFailed.summary=Value of parameter {0} invalid
-validationFailed.details=The given value {1} of parameter {0} is invalid.
-/source
-pThe following one would contain the corresponding german translations in a
file called myMessages_de.properties:/p
- source
-welcome.text=Willkommen
-usage.title=Benutzung
-usage.text=Die folgenden Parameter werden erwartet:
-validationFailed.title=Parametervalidierung fehlgeschlagen.
-validationFailed.text=Die Validierung des Parameters {0} ist fehlgeschlagen.
-validationFailed.summary=Validierung des Parameters {0} fehlgeschlagen.
-validationFailed.details=Der Wert {1} des Parameters {0} ist ungltig.
-/source
-/section
section name=Defining the messages in an XML file
pUsing XML based files has many advantages:/p
ul
@@ -103,7 +70,40 @@
to add as many entries to each bundle as you like. The I18n component
contains
a number of classes that simplify the access to entries of frequently
used bundles./p
/section
-section name=Initializing the messages
+section name=NEW: Pluggable message providers
+pSince version 0.3 of this component you can add your own custom message
providers./p
+pThis is a big plus if you already have your localized messages in a
database for example.
+ You do not have to convert them into the supported XML or
property-based format, but you
+ can write a simple codeMessageProvider/code by implementing a
single method and plug it in./p
+/section
+section name=NEW: ResourceBundle based message provider added
+ pA new message provider made it into this component: The
codeResourceBundleMessageProvider/code.
+ This one enables you to keep your property files that may
contain localized messages./p
+ pYou can group entries messages by adding the key at the end of the
existing message key. The
+ following example shows how a property file should look
svn commit: r153827 - jakarta/commons/sandbox/i18n/trunk/project.properties
Author: dflorey
Date: Mon Feb 14 10:45:26 2005
New Revision: 153827
URL: http://svn.apache.org/viewcvs?view=revrev=153827
Log:
Added download page generation
Modified:
jakarta/commons/sandbox/i18n/trunk/project.properties
Modified: jakarta/commons/sandbox/i18n/trunk/project.properties
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/project.properties?view=diffr1=153826r2=153827
==
--- jakarta/commons/sandbox/i18n/trunk/project.properties (original)
+++ jakarta/commons/sandbox/i18n/trunk/project.properties Mon Feb 14 10:45:26
2005
@@ -1,4 +1,4 @@
-# Copyright 2004 The Apache Software Foundation
+ 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.
@@ -21,7 +21,8 @@
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html
maven.xdoc.includeProjectDocumentation=yes
-
+maven.xdoc.distributionUrl=http://www.apache.org/dist/java-repository/commons-i18n/distributions
+maven.xdoc.distributionType=zip
#
# M A V E N J A R O V E R R I D E
#
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153828 - jakarta/commons/sandbox/i18n/trunk/project.xml
Author: dflorey Date: Mon Feb 14 10:49:08 2005 New Revision: 153828 URL: http://svn.apache.org/viewcvs?view=revrev=153828 Log: Added download page generation Modified: jakarta/commons/sandbox/i18n/trunk/project.xml Modified: jakarta/commons/sandbox/i18n/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/project.xml?view=diffr1=153827r2=153828 == --- jakarta/commons/sandbox/i18n/trunk/project.xml (original) +++ jakarta/commons/sandbox/i18n/trunk/project.xml Mon Feb 14 10:49:08 2005 @@ -34,6 +34,10 @@ currentVersion0.2/currentVersion versions + version + id1/id + name0.3/name + /version /versions branches /branches - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153829 - in jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n: LocalizedBundle.java LocalizedError.java LocalizedException.java LocalizedMessage.java LocalizedText.java MessageNotFoundException.java MessageProvider.java
Author: dflorey Date: Mon Feb 14 11:03:07 2005 New Revision: 153829 URL: http://svn.apache.org/viewcvs?view=revrev=153829 Log: Added download page generation Modified: jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedBundle.java jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedError.java jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedException.java jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedMessage.java jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedText.java jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/MessageNotFoundException.java jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/MessageProvider.java Modified: jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedBundle.java URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedBundle.java?view=diffr1=153828r2=153829 == --- jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedBundle.java (original) +++ jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedBundle.java Mon Feb 14 11:03:07 2005 @@ -1,7 +1,7 @@ /* * $Header: /home/jerenkrantz/tmp/commons/commons-convert/cvs/home/cvs/jakarta-commons-sandbox//i18n/src/java/org/apache/commons/i18n/LocalizedBundle.java,v 1.3 2004/12/29 17:03:55 dflorey Exp $ * $Revision: 1.3 $ - * $Date: 2004/12/29 17:03:55 $ + * $Date$ * * * Modified: jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedError.java URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedError.java?view=diffr1=153828r2=153829 == --- jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedError.java (original) +++ jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedError.java Mon Feb 14 11:03:07 2005 @@ -1,7 +1,7 @@ /* * $Header: /home/jerenkrantz/tmp/commons/commons-convert/cvs/home/cvs/jakarta-commons-sandbox//i18n/src/java/org/apache/commons/i18n/LocalizedError.java,v 1.1 2004/10/04 13:41:09 dflorey Exp $ * $Revision: 1.1 $ - * $Date: 2004/10/04 13:41:09 $ + * $Date$ * * * Modified: jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedException.java URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedException.java?view=diffr1=153828r2=153829 == --- jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedException.java (original) +++ jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedException.java Mon Feb 14 11:03:07 2005 @@ -1,7 +1,7 @@ /* * $Header: /home/jerenkrantz/tmp/commons/commons-convert/cvs/home/cvs/jakarta-commons-sandbox//i18n/src/java/org/apache/commons/i18n/LocalizedException.java,v 1.1 2004/10/04 13:41:09 dflorey Exp $ * $Revision: 1.1 $ - * $Date: 2004/10/04 13:41:09 $ + * $Date$ * * * Modified: jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedMessage.java URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedMessage.java?view=diffr1=153828r2=153829 == --- jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedMessage.java (original) +++ jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedMessage.java Mon Feb 14 11:03:07 2005 @@ -1,7 +1,7 @@ /* * $Header: /home/jerenkrantz/tmp/commons/commons-convert/cvs/home/cvs/jakarta-commons-sandbox//i18n/src/java/org/apache/commons/i18n/LocalizedMessage.java,v 1.1 2004/10/04 13:41:09 dflorey Exp $ * $Revision: 1.1 $ - * $Date: 2004/10/04 13:41:09 $ + * $Date$ * * * Modified: jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedText.java URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedText.java?view=diffr1=153828r2=153829 == --- jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedText.java (original) +++
svn commit: r153837 - in jakarta/commons/sandbox/javaflow/trunk: lib/commons-jci-0.1-dev.jar lib/commons-jci-r153831.jar project.properties project.xml
Author: tcurdt
Date: Mon Feb 14 11:59:23 2005
New Revision: 153837
URL: http://svn.apache.org/viewcvs?view=revrev=153837
Log:
use revision number in jar name
Added:
jakarta/commons/sandbox/javaflow/trunk/lib/commons-jci-r153831.jar (with
props)
Removed:
jakarta/commons/sandbox/javaflow/trunk/lib/commons-jci-0.1-dev.jar
Modified:
jakarta/commons/sandbox/javaflow/trunk/project.properties
jakarta/commons/sandbox/javaflow/trunk/project.xml
Added: jakarta/commons/sandbox/javaflow/trunk/lib/commons-jci-r153831.jar
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/javaflow/trunk/lib/commons-jci-r153831.jar?view=autorev=153837
==
Binary file - no diff available.
Propchange: jakarta/commons/sandbox/javaflow/trunk/lib/commons-jci-r153831.jar
--
svn:mime-type = application/octet-stream
Modified: jakarta/commons/sandbox/javaflow/trunk/project.properties
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/javaflow/trunk/project.properties?view=diffr1=153836r2=153837
==
--- jakarta/commons/sandbox/javaflow/trunk/project.properties (original)
+++ jakarta/commons/sandbox/javaflow/trunk/project.properties Mon Feb 14
11:59:23 2005
@@ -34,5 +34,5 @@
#
# Jars set explicity by path.
#
-maven.jar.commons-jci = ${basedir}/lib/commons-jci-0.1-dev.jar
+maven.jar.commons-jci = ${basedir}/lib/commons-jci-r153831.jar
maven.jar.bcel = ${basedir}/lib/jakarta-bcel-20040329.jar
Modified: jakarta/commons/sandbox/javaflow/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/javaflow/trunk/project.xml?view=diffr1=153836r2=153837
==
--- jakarta/commons/sandbox/javaflow/trunk/project.xml (original)
+++ jakarta/commons/sandbox/javaflow/trunk/project.xml Mon Feb 14 11:59:23 2005
@@ -52,8 +52,8 @@
dependency
groupIdcommons-jci/groupId
artifactIdcommons-jci/artifactId
- version0.1-dev/version
- jar${basedir}/lib/commons-jci-0.1-dev.jar/jar
+ versionr153831/version
+ jar${basedir}/lib/commons-jci-r153831.jar/jar
typejar/type
/dependency
dependency
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Jelly] Dependencies Question
I'm reviewing the jelly project to see if it is appropriate for my uses. The sample project I've created includes much fewer jars than what is posted at http://jakarta.apache.org/commons/jelly/dependencies.html. Specifically, I'm only inlcuding the following: commons-cli commons-collections commons-beanutils commons-jelly commons-jelly-tags-define commons-jexl log4j dom4j Will I run into any problems not including all the jars that are listed as dependencies in my classpath? Also are there any other users using Jelly at this point? Thanks, walshp2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Dependencies Question
On Mon, 14 Feb 2005 15:21:06 -0500, Peter Walsh [EMAIL PROTECTED] wrote: I'm reviewing the jelly project to see if it is appropriate for my uses. The sample project I've created includes much fewer jars than what is posted at http://jakarta.apache.org/commons/jelly/dependencies.html. Specifically, I'm only inlcuding the following: commons-cli commons-collections commons-beanutils commons-jelly commons-jelly-tags-define commons-jexl log4j dom4j Will I run into any problems not including all the jars that are listed as dependencies in my classpath? Some dependecies are for the command line interface only, e.g. forehead or commons-cli. If you are using the Embedded class to run Jelly scripts you may not need these dependencies. Also are there any other users using Jelly at this point? Sure, quite a few regularly post either here or to commons-user. -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Dependencies Question
As with most dependency... each jar is only for a given purpose... if you don't use that purpose you don't need it! I think maven is considering assigning roles to dependencies since long but... how do you express that dependency X is only for functionality Y in general? From your list, I think you can remove log4j, commons-collections, and commons-cli if you use the embedded jelly (do check, not sure for commons-collection). Beware that you seem to include neither xml-apis nor an xml-parser so that you are ok to rely on Crimson (some don't like it) and to require jdk 1.4 You must be doing something very small if not using jelly's xml or ant taglibs! paul Le 14 févr. 05, à 21:43, Dion Gillard a écrit : On Mon, 14 Feb 2005 15:21:06 -0500, Peter Walsh [EMAIL PROTECTED] wrote: I'm reviewing the jelly project to see if it is appropriate for my uses. The sample project I've created includes much fewer jars than what is posted at http://jakarta.apache.org/commons/jelly/dependencies.html. Specifically, I'm only inlcuding the following: commons-cli commons-collections commons-beanutils commons-jelly commons-jelly-tags-define commons-jexl log4j dom4j Will I run into any problems not including all the jars that are listed as dependencies in my classpath? Some dependecies are for the command line interface only, e.g. forehead or commons-cli. If you are using the Embedded class to run Jelly scripts you may not need these dependencies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Dependencies Question
Paul Libbrecht wrote: As with most dependency... each jar is only for a given purpose... if you don't use that purpose you don't need it! I think maven is considering assigning roles to dependencies since long but... how do you express that dependency X is only for functionality Y in general? If this is seen as an issue, you would split jelly into -core and -cli with dependencies for each. This has already been partially discussed WRT -api. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29402] - [el] ClassCastException when using commons-el.jar and standard.jar el evaluator
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=29402. 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=29402 --- Additional Comments From [EMAIL PROTECTED] 2005-02-14 22:12 --- I know that me too comments aren't very helpful, but what the hey. This is still broken in Tomcat 5.5.7, using Taglibs Standard 1.1.2. Arguably this bug could also be logged against tomcat or taglibs, since it's a result of combining these products that's causing the havoc. It doesn't seem to be getting much love here in Commons-EL :) My scenario is very similar - my custom tag calls ExpressionEvaluator.evaluate() as follows: evaluator.evaluate(expression,MyClass.class,pageContext.getVariableResolver(),null); At which point the following exception is thrown: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects at org.apache.commons.el.ImplicitObjects.getImplicitObjects(ImplicitObjects.java:123) at org.apache.commons.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:110) at org.apache.jasper.runtime.PageContextImpl.resolveVariable(PageContextImpl.java:854) at org.apache.commons.el.NamedValue.evaluate(NamedValue.java:124) at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:140) at org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:263) at org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:190) [...] -- 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: [vfs] ISO 9660 file system?
Mark Diggory wrote: Are there any interests in having a VFS that works with ISO 9660 files used to burn data CDROMs/DVDs? I could really use a means to work with building iso files in Java for a project I'm working on. Go ahead! I havent looked at the libaries now, maybe a problem could be if they handle the filesystem like a jar/tar file. Then it could be really hard to add/remove files from the filesystem. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Asking for a solution with Zip files
Stéphane Rault wrote: I've understood that i can't resolveFile like zip:file://c:/temp/toto.zip!/myFile.txt if toto.zip doesn't exist. Bad news: The ZipFileProvider does not support creating/updating zip-files. :-( The same question is available if the URL is ftp://myserver.fr/myNotCreatedDirectory/theFileIWantToPut.ext. FileObject fo = VFS.getManager().resolveFile(ftp://myserver.fr/myNotCreatedDirectory/theFileIWantToPut.ext;); fo.getParent().createFolder(); fo.createFile(); Hope this helps, though I didnt think so. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153860 - jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/CompilingClassLoader.java
Author: tcurdt
Date: Mon Feb 14 13:55:28 2005
New Revision: 153860
URL: http://svn.apache.org/viewcvs?view=revrev=153860
Log:
fix a race condition. start the monitor thread after the listener was added
Modified:
jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/CompilingClassLoader.java
Modified:
jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/CompilingClassLoader.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/CompilingClassLoader.java?view=diffr1=153859r2=153860
==
---
jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/CompilingClassLoader.java
(original)
+++
jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/CompilingClassLoader.java
Mon Feb 14 13:55:28 2005
@@ -71,10 +71,6 @@
compiler = new EclipseJavaCompiler();
fam = new AlterationMonitor(repository);
-Thread myThread = new Thread(fam);
-myThread.start();
-
-delegate = new ResourceStoreClassLoader(parent, store);
fam.addListener(new AlterationListener() {
@@ -180,7 +176,10 @@
}
});
-
+delegate = new ResourceStoreClassLoader(parent, store);
+
+Thread myThread = new Thread(fam);
+myThread.start();
}
private void reload() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCL problems
On Mon, 2005-02-14 at 12:14, Ceki Gülcü wrote: Robert, I am a bit surprised by your question. i needed to make sure that i hadn't misunderstood what you were trying to say... As the current release manager for JCL, I suppose that you are aware that LogFactoryImpl only uses the thread context class loader (TCCL) to search for classes. You were aware of that, weren't you? of course In theory, this is supposed to let a copy of commons-logging.jar placed in a parent class loader to discover another logging API, say log4j, whose classes are visible to a child class loader with the child loader also set to be the TCCL. that's untrue and a little misleading: the reason why those who wrote the classloading code relied on the context classloader is that this is the classloader that should be used by well behaved components running in J2EE containers. this is what correct isolation in a container environment means. there are many consequences which spring from this design decision. some of these are a little unfortunate. i think i agree with richard that a more pragmatic (rather than dogmatic) approach would be wiser. it would better to ensure that the configuration was appropriately isolated and then load a compatible class which satisfies the configuration. i suppose some thought would need to be put into whether there are any realistic security implementations if this approach were adopted. However, this dynamic discovery does not work. The copy of log4j.jar must be placed next to commons-logging.jar. this is a basic feature of delegating classloaders. (i even looked this one up to make sure my memory wasn't playing any tricks: http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#72007) for example, suppose class Alpha is linked to class Beta which is linked to class Gamma, that classloader C is a child of classloader P, that C defines Alpha and Gamma and P Beta but not Gamma or Alpha. (apologies that my diagrams aren't up to richard's standards) Classloader Defines --- --- PBeta ^ | CAlpha Gamma Links - Alpha - Beta - Gamma now consider what happens what Alpha is loaded by C. C defines Alpha which is linked to Beta. therefore C is used to load Beta. C delegates to P which defines Beta. Beta links to Gamma. P defines Beta and is therefore used to load Gamma. However, P cannot load Gamma and so everything blows up. a practical example occurs when jars containing Alpha and Gamma is placed as a utility library in an EJB container and a jar containing Beta is placed in the container base loader. the usual rule (when delegating classloaders are involved) is that any dependencies need to be placed together or higher in the classloader hierarchy. since commons-logging-api by default has a runtime dependency upon commons-logging and commons-logging (a slightly fuzzy one) upon log4j when commons-logging-api is placed in the root classloader, so must the other jars. this would be equally true for a static arrangement (UGLI say). all dependent jars would need to be placed together or higher in the hierarchy. so, i'm not sure how this pertains to the static-verses-dynamic debate. IMHO, from a practical perspective having to ensure that libraries are in the right places comes with the territory: it's something that anyone involved with deployer J2EE applications gets used to doing. Moreover, the copy of commons-logging.jar must be placed very high in the class loader tree, say in the system class loader or the application server's class loader, but that is not all. There must not be other copies of commons-logging.jar in war files of web-apps. i'm not sure how true that is. the stock advice arises from the fact that JCL is used very widely and has a habit of turning up unexpected high in classloader hierarchy. To cut a long story short, do to anything meaningful reliably, JCL is a lot more complicated to set and even when set up correctly brings no benefits when compared to static API binding as found in UGLI. there are several use cases when static binding is admittedly superior. (for those i would prefer byte code engineering over multiple distributions since it allows selective doping of particular components but let's keep focused on compile time solutions). however, the price of deploying a statically bound API high in the hierarchy (where JCL is expected to be able to function) is that applications can no longer be configured in isolation. so, there is price to pay. I urge you run though the examples in [1] which should demonstrate to you how badly and irreparably JCL is broken. The source code is all there. Even if you don't trust my opinion, i'm very reluctant to take anyone's opinion on trust when it comes to JCL. the gestation of JCL was very difficult and the classloading code was developed over a period by senior tomcat folks. JCL also has a huge
Re: [digester2] Additions
On Mon, 2005-02-14 at 17:24 +0100, Oliver Zeigermann wrote: On Tue, 15 Feb 2005 01:08:53 +1300, Simon Kitching [EMAIL PROTECTED] wrote: - DefaultRuleManager now returns an unmodifiable list upon getMatchingActions I'm not so sure about this one. This change means a new object is created each time getMatchingActions is called, and that is once for every xml element in the input document. And in addition, each method call is relayed by the UnmodifiableList wrapper to the underlying one, resulting in a performance hit too. Is this significant in the context of parsing an xml document? I don't know; maybe it's not measurable. However the benefits of this change are really limited only to preventing bad code in SAXHandler or RuleManager classes. Cases where users write their own versions of those will be extremely rare. And mistakes in the core digester classes are, I think, likely to be picked up by our unit tests. So my current feeling is that while the above change **is theoretically correct**, I would leave it out and return the actual list, just documenting that it should be treated as unmodifiable. Well, think of the situation where people inherit and do things like I have done on my first try. So, I would be all for keeping it in, but would not protest if you removed it. I said above: Cases where users write their own versions of those will be extremely rare. I really believe that the number of people writing their own custom RuleManager class will be about 3, worldwide, over the next decade. But the number of people who get impacted by the (admittedly small) performance hit for the proposed change is 100% of users. I guess we have a tie here: +1 from you, and -1 from me. The best thing would be if we got a third opinion from either Craig or Robert. Otherwise, we could just have a remote game of bzflag (http://bzflag.org/screenshots/bzfi0026.jpg) or something, with winner takes all :-) [snip] The ReadOnlyConcatList is cute. I don't think it would save any time or effort over List list = new ArrayList(l1.size() + l2.size()); list.appendAll(l1); list.appendAll(l2); but I guess the unmodifiable feature is thrown in for free. ReadOnlyConcatList certainly would be faster and have a smaller memory footprint. Can you describe why ReadOnlyConcatList is faster and smaller? The array list is (in c terms) just an array of pointers to Actions. To create a new one, I am sure the ArrayList constructor does: * malloc a manager object with a few ints (size, capacity) and a reference to the data block. * malloc the data block, which is capacity*sizeof(reference) * for each entry in the source list, copy reference to new list [1] [2] Once the new ArrayList has been created, access is very fast. [1] The list is likely to be 1, 2, or 3 elements. Having more than 3 Actions match a particular input xml element would be very unusual.. [2] There is even the possibility that ArrayList has been optimised to do a memcpy if its source is an ArrayList. With the ReadOnlyConcatList, the work done is: * malloc a block of data for the ReadOnlyConcatList, which contains one int and the two references to ArrayList objects. * copy 2 references and call size once And accesses are fractionally slower, because get invokes the ReadOnlyConcatList, which performs an if-statement then invokes the get method on the appropriate underlying list. So on the positive side I think that ReadOnlyConcatList is marginally smaller (it doesn't need the data block, which is typically 4-12 bytes), and slightly more efficient to create (one less malloc, a few less copies of references) On the negative, the get method is slightly slower to use. It also adds a dozen lines to the source and an extra .class file to the jar. All in all, we are debating microseconds and handfuls of bytes here. Both seem *acceptable* solutions to me, though I do prefer simple in this case. And like the Unmodifiable discussion, the easiest resolution would be if some other Digester developer (eg Robert or Craig) would give their call, then we could get on with it. I'm also thinking about the possibility that we may move to a RuleManager style that matches based on much richer state than just the current path. FOr example, if we want to support patterns like this: /foo/[EMAIL PROTECTED]'me']/baz[pos()==last()][1] then getMatchingActions will definitely not be taking a String path any more, but instead an array of w3c.dom.Element objects or similar so it has sufficient info to decide whether the pattern matches or not. That won't affect many places in the code, but would make this caching impossible to implement so we'd have to take it out then anyway. We can worry about this as soon as getMatchingActions takes anything else than a String. Right now the method signature that I implemented says it is a String, so there is no problem. It just seems a
Re: [logging] discovery error handling
that all depends on what is meant by fix :) and on what is meant by soon :) anyone (brian or dennis, maybe?) want to volunteer to take a look into improving classloading for the 1.0.x development stream? i'd be willing to make reviewing contributions a priority (but don't think that i'll be able to find the energy to do this and get some momentum back into the production of a more comprehensive solution). - robert On Mon, 2005-02-14 at 15:53, Richard Sitze wrote: It means a fix will be made available as part of the next phase. ras *** Richard A. Sitze IBM WebSphere WebServices Development Ceki Gülcü [EMAIL PROTECTED] wrote on 02/14/2005 06:20:14 AM: At 05:59 PM 2/13/2005, robert burrell donkin wrote: Anyway, before camouflaging errors occurring during Logger retrieval, I'd recommend that you fix the bug exposed by Example 2 in my analysis [1]. In my opinion it cannot be fixed without a major redesign and overhaul of JCL, but maybe I am wrong... this general issued was discussed earlier. i suspect that it would be possible to improve the situation in JCL1 but richard's more sceptical and seems keener to push straight towards JCL2. i think that there's some danger that momentum is starting to slip away so i'm probably not going to look at fix the issue in the 1.0.x stream right now. Does this mean that JCL won't be fixed anytime soon? :-( - robert -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - 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 33574] New: - unbalanced ReflectionToStringBuilder
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=33574. 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=33574 Summary: unbalanced ReflectionToStringBuilder Product: Commons Version: Nightly Builds Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Lang AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I think it should be important for calls to ToStringStyle.appendFieldStart() be balanced with calls to ToStringStyle.appendFieldEnd(). The method ReflectioinToStringBuilder.appendFieldsIn() has an appendFieldStart call, but not an appendFieldEnd call. This is very important in my situation because I am coding an XMLToStringBuilder and the field does not get closed. I will attach a patch. -- 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 33574] - unbalanced ReflectionToStringBuilder
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=33574. 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=33574 --- Additional Comments From [EMAIL PROTECTED] 2005-02-15 00:35 --- Created an attachment (id=14285) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14285action=view) Adds one line to method appendFieldsIn(). -- 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]
svn commit: r153876 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/DefaultRuleManager.java
Author: ozeigermann
Date: Mon Feb 14 16:29:48 2005
New Revision: 153876
URL: http://svn.apache.org/viewcvs?view=revrev=153876
Log:
Reverted the unmodifiable wrapper for actionList on Simon's request
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/DefaultRuleManager.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/DefaultRuleManager.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/DefaultRuleManager.java?view=diffr1=153875r2=153876
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/DefaultRuleManager.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/DefaultRuleManager.java
Mon Feb 14 16:29:48 2005
@@ -249,7 +249,7 @@
return java.util.Collections.EMPTY_LIST;
}
else {
-return Collections.unmodifiableList(actionList);
+return actionList;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester2] Additions
On Tue, 15 Feb 2005 11:27:29 +1300, Simon Kitching [EMAIL PROTECTED] wrote: On Mon, 2005-02-14 at 17:24 +0100, Oliver Zeigermann wrote: On Tue, 15 Feb 2005 01:08:53 +1300, Simon Kitching [EMAIL PROTECTED] wrote: - DefaultRuleManager now returns an unmodifiable list upon getMatchingActions I'm not so sure about this one. This change means a new object is created each time getMatchingActions is called, and that is once for every xml element in the input document. And in addition, each method call is relayed by the UnmodifiableList wrapper to the underlying one, resulting in a performance hit too. Is this significant in the context of parsing an xml document? I don't know; maybe it's not measurable. However the benefits of this change are really limited only to preventing bad code in SAXHandler or RuleManager classes. Cases where users write their own versions of those will be extremely rare. And mistakes in the core digester classes are, I think, likely to be picked up by our unit tests. So my current feeling is that while the above change **is theoretically correct**, I would leave it out and return the actual list, just documenting that it should be treated as unmodifiable. Well, think of the situation where people inherit and do things like I have done on my first try. So, I would be all for keeping it in, but would not protest if you removed it. I said above: Cases where users write their own versions of those will be extremely rare. I really believe that the number of people writing their own custom RuleManager class will be about 3, worldwide, over the next decade. But the number of people who get impacted by the (admittedly small) performance hit for the proposed change is 100% of users. I guess we have a tie here: +1 from you, and -1 from me. The best thing would be if we got a third opinion from either Craig or Robert. Otherwise, we could just have a remote game of bzflag (http://bzflag.org/screenshots/bzfi0026.jpg) or something, with winner takes all :-) I am not +1. I am +0. I have reverted that change. [snip] The ReadOnlyConcatList is cute. I don't think it would save any time or effort over List list = new ArrayList(l1.size() + l2.size()); list.appendAll(l1); list.appendAll(l2); but I guess the unmodifiable feature is thrown in for free. ReadOnlyConcatList certainly would be faster and have a smaller memory footprint. Can you describe why ReadOnlyConcatList is faster and smaller? The array list is (in c terms) just an array of pointers to Actions. To create a new one, I am sure the ArrayList constructor does: * malloc a manager object with a few ints (size, capacity) and a reference to the data block. * malloc the data block, which is capacity*sizeof(reference) * for each entry in the source list, copy reference to new list [1] [2] Once the new ArrayList has been created, access is very fast. [1] The list is likely to be 1, 2, or 3 elements. Having more than 3 Actions match a particular input xml element would be very unusual.. [2] There is even the possibility that ArrayList has been optimised to do a memcpy if its source is an ArrayList. With the ReadOnlyConcatList, the work done is: * malloc a block of data for the ReadOnlyConcatList, which contains one int and the two references to ArrayList objects. * copy 2 references and call size once And accesses are fractionally slower, because get invokes the ReadOnlyConcatList, which performs an if-statement then invokes the get method on the appropriate underlying list. So on the positive side I think that ReadOnlyConcatList is marginally smaller (it doesn't need the data block, which is typically 4-12 bytes), and slightly more efficient to create (one less malloc, a few less copies of references) On the negative, the get method is slightly slower to use. It also adds a dozen lines to the source and an extra .class file to the jar. All in all, we are debating microseconds and handfuls of bytes here. Both seem *acceptable* solutions to me, though I do prefer simple in this case. And like the Unmodifiable discussion, the easiest resolution would be if some other Digester developer (eg Robert or Craig) would give their call, then we could get on with it. No problem, really, simply replace it. If neither Robert nor Craig offer their opinion, then I'm willing to settle for the following compromise. It won't make either of us 100% happy, but I don't think there's anything we can't live with, either, and we can move forward again: * merge fallback rules into RuleManager and DefaultRuleManager, and remove FallbackRuleManager * leave SupplementaryRuleManager exactly as you wrote it, with caching and ReadOnlyConcatList (except for the changes needed due to removal of FallbackRuleManager) * remove the UnmodifiableList stuff from DefaultRuleManager
svn commit: r153881 - in jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2: AbstractRuleManagerTestCase.java DefaultRuleManagerTestCase.java
Author: skitching
Date: Mon Feb 14 19:01:36 2005
New Revision: 153881
URL: http://svn.apache.org/viewcvs?view=revrev=153881
Log:
Handle new fallback and mandatory action features of RuleManagers.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/AbstractRuleManagerTestCase.java
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/DefaultRuleManagerTestCase.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/AbstractRuleManagerTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/AbstractRuleManagerTestCase.java?view=diffr1=153880r2=153881
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/AbstractRuleManagerTestCase.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/AbstractRuleManagerTestCase.java
Mon Feb 14 19:01:36 2005
@@ -66,6 +66,22 @@
public void finishParse(Context context) throws DigestionException {
operations.add(finishParse);
}
+
+public void addFallbackAction(Action action) {
+operations.add(addFallbackAction);
+}
+
+public void addFallbackActions(List actions) {
+operations.add(addFallbackActions);
+}
+
+public void addMandatoryAction(Action action) {
+operations.add(addMandatoryAction);
+}
+
+public void addMandatoryActions(List actions) {
+operations.add(addMandatoryActions);
+}
public void addNamespace(String prefix, String uri) {
operations.add(addNamespace);
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/DefaultRuleManagerTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/DefaultRuleManagerTestCase.java?view=diffr1=153880r2=153881
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/DefaultRuleManagerTestCase.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/DefaultRuleManagerTestCase.java
Mon Feb 14 19:01:36 2005
@@ -164,12 +164,114 @@
// match one action
list = rm.getMatchingActions(/a);
assertEquals(One rule matched, 1, list.size());
-assertEquals(A rule matched, a, list.get(0).toString());
+assertSame(A rule matched, actionA, list.get(0));
// match multiple actions
list = rm.getMatchingActions(/a/b);
assertEquals(Multiple rules matched, 2, list.size());
-assertEquals(B1 rule matched, b1, list.get(0).toString());
-assertEquals(B2 rule matched, b2, list.get(1).toString());
+assertSame(B1 rule matched, actionB1, list.get(0));
+assertSame(B2 rule matched, actionB2, list.get(1));
+}
+
+public void testDefaultActions() throws Exception {
+DefaultRuleManager rm = new DefaultRuleManager();
+
+Action actionA = new DummyAction(a);
+Action actionB = new DummyAction(b);
+Action actionC = new DummyAction(c);
+
+List list = null;
+
+rm.addRule(/a, actionA);
+rm.addFallbackAction(actionB);
+rm.addFallbackAction(actionC);
+
+// verify that all actions are reported in getActions
+List allActions = rm.getActions();
+assertTrue(ActionA present, allActions.contains(actionA));
+assertTrue(ActionB present, allActions.contains(actionB));
+assertTrue(ActionC present, allActions.contains(actionC));
+
+// match one action
+list = rm.getMatchingActions(/a);
+assertEquals(One rule matched, 1, list.size());
+assertSame(A rule matched, actionA, list.get(0));
+
+// match nothing
+list = rm.getMatchingActions(/c);
+assertEquals(Action list contains fallbacks no match, 2,
list.size());
+assertSame(B rule matched, actionB, list.get(0));
+assertSame(C rule matched, actionC, list.get(1));
+}
+
+/**
+ * Test mandatory actions in absence of fallback actions
+ */
+public void testMandatoryActions1() throws Exception {
+DefaultRuleManager rm = new DefaultRuleManager();
+
+Action actionA = new DummyAction(a);
+Action actionB = new DummyAction(b);
+Action actionC = new DummyAction(c);
+
+List list = null;
+
+rm.addRule(/a, actionA);
+rm.addMandatoryAction(actionB);
+rm.addMandatoryAction(actionC);
+
+
svn commit: r153882 - in jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2: AbstractRuleManager.java DefaultRuleManager.java RuleManager.java
Author: skitching
Date: Mon Feb 14 19:08:36 2005
New Revision: 153882
URL: http://svn.apache.org/viewcvs?view=revrev=153882
Log:
Implement fallback and mandatory (aka supplementary) actions.
Also some whitespace tidyups.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/AbstractRuleManager.java
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/DefaultRuleManager.java
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/RuleManager.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/AbstractRuleManager.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/AbstractRuleManager.java?view=diffr1=153881r2=153882
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/AbstractRuleManager.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/AbstractRuleManager.java
Mon Feb 14 19:08:36 2005
@@ -1,19 +1,19 @@
/* $Id$
*
* Copyright 2001-2005 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.digester2;
@@ -24,9 +24,9 @@
* match input xml elements to lists of Actions to be executed).
* p
* Note that extending this abstract class rather than directly implementing
- * the RuleManager interface provides much better forward compatibility.
- * Digester minor releases (2.x - 2.y) guarantee not to break any classes
that
- * subclass this abstract class. However no such guarantee exists for classes
+ * the RuleManager interface provides much better forward compatibility.
+ * Digester minor releases (2.x - 2.y) guarantee not to break any classes that
+ * subclass this abstract class. However no such guarantee exists for classes
* that directly implement the RuleManager interface.
*/
@@ -35,18 +35,18 @@
/**
* Returns a new instance with the same type as the concrete object this
* method is invoked on, complete with contained Actions and patterns. Note
- * that the new RuleManager instance may contain references to the same
+ * that the new RuleManager instance may contain references to the same
* Action instances as the old one, as Action instances are expected to be
- * stateless and therefore can be safely shared between RuleManagers.
+ * stateless and therefore can be safely shared between RuleManagers.
*/
public abstract RuleManager copy();
-
+
/**
* Invoked before parsing each input document, this method gives the
* RuleManager the opportunity to do per-parse initialisation if required.
*/
public void startParse(Context context) throws DigestionException {}
-
+
/**
* Invoked after parsing each input document, this method gives the
* RuleManager and the managed Action objects the opportunity to do
@@ -55,11 +55,52 @@
public void finishParse(Context context) throws DigestionException {}
/**
+ * Defines an action that should be returned by method getMatchingActions
+ * if no rule pattern matches the specified path.
+ * p
+ * The specified action is appended to the existing list of fallback
actions.
+ */
+public abstract void addFallbackAction(Action action);
+
+/**
+ * Defines actions that should be returned by method getMatchingActions
+ * if no rule pattern matches the specified path.
+ * p
+ * The actions contained in the specified list are appended to the
+ * existing list of fallback actions.
+ */
+public abstract void addFallbackActions(List actions);
+
+/**
+ * Defines an action that should always be included in the list of actions
+ * returned by method getMatchingActions, no matter what path is provided.
+ * p
+ * if no rule pattern matches the specified path. The specified action
+ * is appended to the existing list of fallback actions.
+ * p
+ * The mandatory actions (if any) are always returned at the tail of the
+ * list of actions returned by getMatchingActions.
+ */
+public abstract void addMandatoryAction(Action action);
+
+/**
+ *
svn commit: r153883 - in jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2: FallbackRuleManager.java SupplementaryRuleManager.java
Author: skitching Date: Mon Feb 14 19:10:06 2005 New Revision: 153883 URL: http://svn.apache.org/viewcvs?view=revrev=153883 Log: Functionality merged into DefaultRuleManager class. Removed: jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/FallbackRuleManager.java jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SupplementaryRuleManager.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153884 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/SupplementaryRuleManagerTestCase.java
Author: skitching Date: Mon Feb 14 19:14:37 2005 New Revision: 153884 URL: http://svn.apache.org/viewcvs?view=revrev=153884 Log: SupplementaryRuleManager has been merged into DefaultRuleManager. The matching functionality has been moved to MatchUtils. Removed: jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/SupplementaryRuleManagerTestCase.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153885 - in jakarta/commons/proper/net/trunk/src: java/org/apache/commons/net/ftp/FTPClient.java test/org/apache/commons/net/ftp/ListingFunctionalTest.java
Author: scohen
Date: Mon Feb 14 19:42:11 2005
New Revision: 153885
URL: http://svn.apache.org/viewcvs?view=revrev=153885
Log:
Deprecate FTPClient.listFiles(String, String) to avoid confusion over new
FTPClientConfig methods
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/ListingFunctionalTest.java
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java?view=diffr1=153884r2=153885
==
---
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
(original)
+++
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
Mon Feb 14 19:42:11 2005
@@ -2077,6 +2077,9 @@
* @see org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory
* @see org.apache.commons.net.ftp.parser.FTPFileEntryParserFactory
* @see org.apache.commons.net.ftp.FTPFileEntryParser
+ * @deprecated use [EMAIL PROTECTED] #listFiles() listFiles()} or
+ * [EMAIL PROTECTED] #listFiles(String) listFiles(String)} instead and
specify the
+ * parser Key in an [EMAIL PROTECTED] #FTPClientConfig FTPClientConfig}
object instead.
*/
public FTPFile[] listFiles(String parserKey, String pathname)
throws IOException
@@ -2132,7 +2135,10 @@
throws IOException
{
String key = null;
-return listFiles(key, pathname);
+FTPListParseEngine engine =
+initiateListParsing(key, pathname);
+return engine.getFiles();
+
}
/**
* Using the default system autodetect mechanism, obtain a
Modified:
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/ListingFunctionalTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/ListingFunctionalTest.java?view=diffr1=153884r2=153885
==
---
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/ListingFunctionalTest.java
(original)
+++
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/ListingFunctionalTest.java
Mon Feb 14 19:42:11 2005
@@ -27,7 +27,7 @@
/**
* A functional test suite for checking that site listings work.
* @author a href=mailto:[EMAIL PROTECTED]Jeffrey D. Brekke/a
- * @version $Id: ListingFunctionalTest.java,v 1.6 2004/04/21 23:30:33 scohen
Exp $
+ * @version $Id$
*/
public class ListingFunctionalTest extends TestCase
{
@@ -248,7 +248,9 @@
public void testListFiles()
throws IOException
{
-List files = Arrays.asList(client.listFiles(validParserKey,
validPath));
+FTPClientConfig config = new FTPClientConfig(validParserKey);
+client.configure(config);
+List files = Arrays.asList(client.listFiles(validPath));
assertTrue(files.toString(),
findByName(files, validFilename));
@@ -271,7 +273,10 @@
public void testListFilesWithIncorrectParser()
throws IOException
{
-FTPFile[] files = client.listFiles(invalidParserKey, validPath);
+FTPClientConfig config = new FTPClientConfig(invalidParserKey);
+client.configure(config);
+
+FTPFile[] files = client.listFiles(validPath);
assertEquals(0, files.length);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153886 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SimpleMatchUtils.java
Author: skitching
Date: Mon Feb 14 19:43:01 2005
New Revision: 153886
URL: http://svn.apache.org/viewcvs?view=revrev=153886
Log:
New class containing code formerly in (deleted) class SupplementaryRuleManager.
Original author: Oliver Zeigermann
Added:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SimpleMatchUtils.java
(with props)
Added:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SimpleMatchUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SimpleMatchUtils.java?view=autorev=153886
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SimpleMatchUtils.java
(added)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SimpleMatchUtils.java
Mon Feb 14 19:43:01 2005
@@ -0,0 +1,60 @@
+/* $Id$
+ *
+ * Copyright 2005 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.digester2;
+
+/**
+ * A collection of static utility methods for matching patterns against
+ * xml element paths using simple matching functionality.
+ */
+
+public class SimpleMatchUtils {
+
+/**
+ * Returns true if the pathToMatch is an absolute path that matches
+ * the input path, or if it is a relative path that matches the last
+ * part of the specified path.
+ */
+public static boolean matches(String path, String pathToMatch) {
+if (pathToMatch.charAt(0) == '/') {
+// absolute
+return path.equals(pathToMatch);
+} else {
+// relative
+// XXX looks wrong but protects a match of
+// a/b against a path of /gotcha/b, but
+// still allows
+// a/b to match against /a/b
+return path.endsWith(/ + pathToMatch);
+}
+}
+
+/**
+ * Checks if this path matches any of the paths given. This means we
+ * iterate through codepathsToMatch/code and match every entry to
+ * this path.
+ */
+public static boolean matchsAny(String path, String[] pathsToMatch) {
+for (int i = 0; i pathsToMatch.length; i++) {
+if (matches(path, pathsToMatch[i]))
+return true;
+}
+return false;
+}
+}
+
Propchange:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SimpleMatchUtils.java
--
svn:keywords = Id
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153887 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/SimpleMatchUtilsTestCase.java
Author: skitching
Date: Mon Feb 14 19:43:56 2005
New Revision: 153887
URL: http://svn.apache.org/viewcvs?view=revrev=153887
Log:
Test case code originally in (deleted) SupplementaryRuleManagerTestCase.
Original code by Oliver Zeigermann
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/SimpleMatchUtilsTestCase.java
(with props)
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/SimpleMatchUtilsTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/SimpleMatchUtilsTestCase.java?view=autorev=153887
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/SimpleMatchUtilsTestCase.java
(added)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/SimpleMatchUtilsTestCase.java
Mon Feb 14 19:43:56 2005
@@ -0,0 +1,131 @@
+/* $Id$
+ *
+ * Copyright 2005 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.digester2;
+
+import java.io.StringReader;
+
+import junit.framework.Test;
+import junit.framework.TestCase;
+import junit.framework.TestSuite;
+
+import org.xml.sax.Attributes;
+import org.xml.sax.InputSource;
+
+/**
+ * Test Case for the SimpleMatchUtils class.
+ */
+
+public class SimpleMatchUtilsTestCase extends TestCase {
+
+private static class NullAction extends AbstractAction {
+}
+
+private static class XMLLikeAction extends AbstractAction {
+boolean rootFoundAbsolute = false;
+boolean rootFoundRelative = false;
+boolean wrongRelativeFound = false;
+boolean longAbsoluteFound = false;
+
+public void begin(Context context, String namespace, String name,
Attributes attrs) {
+String path = context.getMatchPath();
+if (SimpleMatchUtils.matches(path, /root)) {
+rootFoundAbsolute = true;
+}
+
+if (SimpleMatchUtils.matches(path, root)) {
+rootFoundRelative = true;
+}
+
+if (SimpleMatchUtils.matches(path, /root/p/em)) {
+longAbsoluteFound = true;
+}
+
+if (SimpleMatchUtils.matches(path, ot/p)) {
+wrongRelativeFound = true;
+}
+}
+};
+
+// ---
+// Constructors
+// ---
+
+/**
+ * Construct a new instance of this test case.
+ *
+ * @param name
+ *Name of the test case
+ */
+public SimpleMatchUtilsTestCase(String name) {
+super(name);
+}
+
+// --
+// Overall Test Methods
+// --
+
+/**
+ * Set up instance variables required by this test case.
+ */
+public void setUp() {
+}
+
+/**
+ * Return the tests included in this test suite.
+ */
+public static Test suite() {
+return (new TestSuite(SupplementaryRuleManagerTestCase.class));
+}
+
+/**
+ * Tear down instance variables required by this test case.
+ */
+public void tearDown() {
+}
+
+//
+// Individual Test Methods
+//
+
+/**
+ * SimpleMatchUtils is expected to be used in situations where the user
+ * has written a custom Action class that performs its own rule-matching
+ * (aka xmlio-style). So we test that here.
+ */
+public void testBasicOperation() throws Exception {
+ String inputText = rootpHi emThere/em/p/root;
+
+// xmlio-style digester
+XMLLikeAction xmlioLikeAction = new XMLLikeAction();
+
+Digester d = new Digester();
+d.getRuleManager().addMandatoryAction(xmlioLikeAction);
+d.addRule(root, new NullAction());
+
+// try twice to check caching
+for (int i = 0; i 2; i++) {
+InputSource source = new InputSource(new StringReader(inputText));
+d.parse(source);
+
+assertTrue(Root element was found absolute,
xmlioLikeAction.rootFoundAbsolute);
+
Re: [digester2] Additions
On Tue, 2005-02-15 at 01:35 +0100, Oliver Zeigermann wrote: After I have thought about it, I am +1 to do it the way you proposed initially: have it all in one class. That's not because I am frustrated or am no longer interested, but I think that's a good solution and causes the least controversy. Go ahead with it please. Ok, done. I've used the term mandatoryAction rather than supplementaryAction as it's equivalent, shorter and hopefully more familiar to non-english speakers. I've moved the path-matching functionality from SupplementaryRuleManager into a new class SimpleMatchUtils. And of course new class SimpleMatchUtilsTestCase now contains the basic xmlio demonstration adapted from the old SupplementaryRuleManagerTestCase. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153890 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
Author: skitching
Date: Mon Feb 14 19:51:25 2005
New Revision: 153890
URL: http://svn.apache.org/viewcvs?view=revrev=153890
Log:
Tweaked the peek methods to allow negative offsets, so that -1 can be used to
refer to the root element of the stack etc.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java?view=diffr1=153889r2=153890
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
Mon Feb 14 19:51:25 2005
@@ -588,23 +588,25 @@
}
/**
- * Return the n'th object down the stack, where 0 is the top element
- * and [getStackSize()-1] is the bottom element.
+ * Return the specified object on the stack. Positive offsets are distances
+ * from the top object of the stack down towards the root (0 indicates the
+ * top object). Negative offsets are distances from the root object of the
+ * stack up towards the top (-1 indicates the root object).
*
- * @param n Index of the desired element, where 0 is the top of the stack,
- * 1 is the next element down, and so on.
+ * @param n Index of the desired element.
*
* @throws EmptyStackException (a RuntimeException subclass) if the index
- * is out-of-range. Note that all the Digester.parse methods will turn this
- * into a (checked) DigestionException.
+ * is a positive number greater than the depth of the stack.
*
* @throws ArrayOutOfBoundsException (a RuntimeException subclass) if
- * index 0. Note that all the Digester.parse methods will turn this
- * into a (checked) DigestionException.
+ * index is a negative number and stack.size() + offset is less than zero.
*/
-public Object peek(int n)
+public Object peek(int offset)
throws EmptyStackException, IndexOutOfBoundsException {
-return stack.peek(n);
+if (offset 0) {
+offset = stack.size() + offset;
+}
+return stack.peek(offset);
}
/**
@@ -666,11 +668,11 @@
}
/**
- * pGets the top object from the stack with the given id.
- * This method does not remove the object from the stack./p
+ * Gets the top object from the stack with the given id.
+ * This method does not remove the object from the stack.
*
- * pstrongNote:/strong a stack is considered empty
- * if no objects have been pushed onto it yet./p
+ * strongNote:/strong a stack is considered empty
+ * if no objects have been pushed onto it yet.
*
* @param stackId identifies the stack to be peeked
* @return the top codeObject/code on the stack.
@@ -683,23 +685,23 @@
log.debug(Stack ' + stackId + ' is empty);
}
throw new EmptyStackException();
-} else {
-return stack.peek();
}
+
+return stack.peek();
}
/**
- * Returns an element from the stack with the given name. The element
- * returned is the n'th object down the stack, where 0 is the top element
- * and [getStackSize()-1] is the bottom element.
- *
- * pstrongNote:/strong a stack is considered empty
- * if no objects have been pushed onto it yet./p
+ * Returns an element from the specified stack. Positive offsets are
distances
+ * from the top object of the stack down towards the root (0 indicates the
+ * top object). Negative offsets are distances from the root object of the
+ * stack up towards the top (-1 indicates the root object).
+ * p
+ * strongNote:/strong a stack is considered empty
+ * if no objects have been pushed onto it yet.
*
* @param stackId identifies the stack to be peeked
*
- * @param n Index of the desired element, where 0 is the top of the stack,
- * 1 is the next element down, and so on.
+ * @param offset Index of the desired element
*
* @throws EmptyStackException (a RuntimeException subclass) if the index
* is out-of-range. Note that all the Digester.parse methods will turn this
@@ -709,7 +711,7 @@
* index 0. Note that all the Digester.parse methods will turn this
* into a (checked) DigestionException.
*/
-public Object peek(StackId stackId, int n)
+public Object peek(StackId stackId, int offset)
throws EmptyStackException, IndexOutOfBoundsException {
ArrayStack stack = (ArrayStack) scratchStacks.get(stackId);
if (stack == null ) {
@@ -717,14
svn commit: r153891 - in jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2: actions/LinkObjectsAction.java actions/SetNextAction.java factory/ActionFactory.java
Author: skitching
Date: Mon Feb 14 19:56:01 2005
New Revision: 153891
URL: http://svn.apache.org/viewcvs?view=revrev=153891
Log:
Class LinkObjectsAction now provides the functionality of the
digester1.x classes SetNextRule, SetTopRule, SetRootRule.
Added:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/LinkObjectsAction.java
(contents, props changed)
- copied, changed from r153753,
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetNextAction.java
Removed:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetNextAction.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/factory/ActionFactory.java
Copied:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/LinkObjectsAction.java
(from r153753,
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetNextAction.java)
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/LinkObjectsAction.java?view=diffrev=153891p1=jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetNextAction.javar1=153753p2=jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/LinkObjectsAction.javar2=153891
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetNextAction.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/LinkObjectsAction.java
Mon Feb 14 19:56:01 2005
@@ -1,6 +1,6 @@
-/* $Id: $
+/* $Id$
*
- * Copyright 2001-2004 The Apache Software Foundation.
+ * Copyright 2001-2005 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.
@@ -26,18 +26,44 @@
import org.apache.commons.digester2.ParseException;
/**
- * pAn Action that calls a method on the (top-1) (parent) object, passing
- * the top object (child) as an argument. It is commonly used to establish
- * parent-child relationships between objects on the digester stack./p
+ * An Action that builds relationships between objects on the digester
+ * object stack, usually parent/child relationships.
+ * p
+ * The default behaviour calls a method on the parent (top-1) object, passing
+ * the child (top) object as an argument. The parent object is then expected
+ * to store a reference to that child object for later use.
+ * p
+ * Providing non-default values for sourceOffset and targetOffset to the
+ * constructor of this class produce actions that can (for example):
+ * ul
+ * li pass the parent (top-1) object to a method on the child (top) object,
or
+ * li pass the child (top) object to a method on the object at the root of
+ * the digester object stack.
+ * /ul
+ * p
+ * For users of the Digester 1.x series, this action is equivalent to the
+ * SetNextRule, SetTopRule and SetRootRule classes.
*/
-public class SetNextAction extends AbstractAction {
+public class LinkObjectsAction extends AbstractAction {
// -
// Instance Variables
// -
/**
+ * The offset on the digester object stack of the object that will be
+ * passed as a parameter.
+ */
+protected int sourceOffset;
+
+/**
+ * The offset on the digester object stack of the object on which the
+ * method will be invoked.
+ */
+protected int targetOffset;
+
+/**
* The method name to call on the parent object.
*/
protected String methodName = null;
@@ -54,24 +80,69 @@
// ---
/**
- * Construct an action which invokes the specified method name.
+ * Construct an action which invokes the specified method name on the
+ * parent (top-1) object, passing the child (top) object.
*
* @param methodName Method name of the parent method to call
*/
-public SetNextAction(String methodName) {
-this(methodName, null);
+public LinkObjectsAction(String methodName) {
+this(0, 1, methodName, null);
}
/**
- * Construct a set next rule with the specified method name.
+ * Construct an action which invokes the specified method name on the
+ * parent (top-1) object, passing the child (top) object, and that
+ * the standard type-conversion facilities should be applied to the
+ * child object first.
+ * p
+ * Note that when type-conversion is applied,
svn commit: r153892 - in jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions: CreateObjectActionTestCase.java CreateObjectWithFactoryActionTestCase.java LinkObjectsActionTestCase.java SetNextActionTestCase.java
Author: skitching
Date: Mon Feb 14 19:56:57 2005
New Revision: 153892
URL: http://svn.apache.org/viewcvs?view=revrev=153892
Log:
LinkObjectsAction now provides all the functionality of
digester1.x SetNextRule, SetTopRule and SetRootRule.
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/LinkObjectsActionTestCase.java
- copied, changed from r153753,
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.java
Removed:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectWithFactoryActionTestCase.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java?view=diffr1=153891r2=153892
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java
Mon Feb 14 19:56:57 2005
@@ -98,7 +98,7 @@
Digester d = new Digester();
d.addRule(/root/item, new CreateObjectAction(Item.class));
-d.addRule(/root/item, new SetNextAction(addItem));
+d.addRule(/root/item, new LinkObjectsAction(addItem));
TestObject testObject = new TestObject();
d.setInitialObject(testObject);
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectWithFactoryActionTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectWithFactoryActionTestCase.java?view=diffr1=153891r2=153892
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectWithFactoryActionTestCase.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectWithFactoryActionTestCase.java
Mon Feb 14 19:56:57 2005
@@ -121,7 +121,7 @@
Digester d = new Digester();
d.setInitialObject(root);
d.addRule(/root/int, new CreateObjectWithFactoryAction(factory));
-d.addRule(/root/int, new SetNextAction(addInteger));
+d.addRule(/root/int, new LinkObjectsAction(addInteger));
d.parse(source);
@@ -153,7 +153,7 @@
Digester d = new Digester();
d.setInitialObject(root);
d.addRule(/root/int, new
CreateObjectWithFactoryAction(IntegerFactory.class));
-d.addRule(/root/int, new SetNextAction(addInteger));
+d.addRule(/root/int, new LinkObjectsAction(addInteger));
d.parse(source);
Copied:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/LinkObjectsActionTestCase.java
(from r153753,
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.java)
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/LinkObjectsActionTestCase.java?view=diffrev=153892p1=jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.javar1=153753p2=jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/LinkObjectsActionTestCase.javar2=153892
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/LinkObjectsActionTestCase.java
Mon Feb 14 19:56:57 2005
@@ -30,10 +30,10 @@
import org.apache.commons.digester2.Digester;
/**
- * pTest Cases for the SetNextAction class./p
+ * pTest Cases for the LinkObjectsAction class./p
*/
-public class SetNextActionTestCase extends TestCase {
+public class LinkObjectsActionTestCase extends TestCase {
public static class Item {
}
@@ -54,7 +54,7 @@
*
* @param name Name of the test case
*/
-
a commons-lang patch.
I just added a Bugzilla entry which includes a patch. What do I need to do to persuade someone to look at the bug and apply the patch? http://issues.apache.org/bugzilla/show_bug.cgi?id=33574 -Trav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
