[jira] Commented: (JXPATH-89) Cannot compare pointers that do not belong to the same tree
[ https://issues.apache.org/jira/browse/JXPATH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510087 ] Sergey Vladimirov commented on JXPATH-89: - Let me try to implement my idea and discuss this later :) > Cannot compare pointers that do not belong to the same tree > --- > > Key: JXPATH-89 > URL: https://issues.apache.org/jira/browse/JXPATH-89 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: Nightly Builds, 1.2 Final > Environment: codebase: 1.2 or latest version from SVN, JDK 1.4 >Reporter: Sergey Vladimirov > Fix For: 1.3 > > Attachments: VariablePointerTestCase.java > > > For XPath "$var | /MAIN/A" exception is thrown: > org.apache.commons.jxpath.JXPathException: Cannot compare pointers that do > not belong to the same tree: '$var' and '' > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:665) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareTo(NodePointer.java:639) > at java.util.Arrays.mergeSort(Arrays.java:1152) > at java.util.Arrays.sort(Arrays.java:1079) > at java.util.Collections.sort(Collections.java:113) > at > org.apache.commons.jxpath.ri.EvalContext.constructIterator(EvalContext.java:176) > at > org.apache.commons.jxpath.ri.EvalContext.hasNext(EvalContext.java:100) > at > org.apache.commons.jxpath.JXPathContext.selectNodes(JXPathContext.java:648) > at > org.apache.commons.jxpath.ri.model.VariablePointerTestCase.testUnionOfVariableAndNode(VariablePointerTestCase.java:76) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Fileupload 1.3 or 2.0?
On 7/4/07, Martin Cooper <[EMAIL PROTECTED]> wrote: * We were already starting to clone classes from what was originally HttpClient and is now HttpComponents. One example is the ParameterParser class. When I saw HttpComponents being born, saw a lot of other stuff in there that FileUpload was doing, it looked like it would make a lot of sense to build FileUpload on top of HttpComponents, thus dramatically cutting down the amount of code necessary to build a FileUpload package. I agree with you on that it might make sense to reuse components from outside, if possible. Unfortunately HttpComponents (in the person of Oleg Kalnichevski) has repeatedly declared that he has no interest in adding a multipart parser to httpcomponents, which would be (IMO) the most important part. Instead he suggested to add such a parser to Commons Codec. I personally believe, that this extends the scope of Commons Codec. But yes, if possible, I'd still be interested to reuse another multipart parser. Do you know of any ASL licensed? Also, it would still be good to have a much more clear distinction between what is supposed to be public and what is not. (For example, recall the MultipartStream threads from not so long ago.) Agreed. I was surprised to hear that the multipart parser *is* being reused. Oh, and I'm definitely in favour of going for a 2.0 release and cleaning up some crud along the way. I just don't think I'll be in a position to help any time soon, I'm afraid. As expected, but sad to hear anyways. :-) Thanks, Jochen -- "Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-89) Cannot compare pointers that do not belong to the same tree
[ https://issues.apache.org/jira/browse/JXPATH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510064 ] Matt Benson commented on JXPATH-89: --- I'm afraid I still don't follow you. The variables exist as an externally-injected dataset to use in conjunction with the JXPathContext. If in your own code you know that the variable's value is somewhere in the graph accessible from a given parent object, you may be able to do some custom work to search it out. My current opinion is that the route by which a value is reached _defines_ its location, because multiple routes may lead to the same object. This means that a variable rightly has no contextual information by which it can correctly be compared to true path nodes. > Cannot compare pointers that do not belong to the same tree > --- > > Key: JXPATH-89 > URL: https://issues.apache.org/jira/browse/JXPATH-89 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: Nightly Builds, 1.2 Final > Environment: codebase: 1.2 or latest version from SVN, JDK 1.4 >Reporter: Sergey Vladimirov > Fix For: 1.3 > > Attachments: VariablePointerTestCase.java > > > For XPath "$var | /MAIN/A" exception is thrown: > org.apache.commons.jxpath.JXPathException: Cannot compare pointers that do > not belong to the same tree: '$var' and '' > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:665) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareTo(NodePointer.java:639) > at java.util.Arrays.mergeSort(Arrays.java:1152) > at java.util.Arrays.sort(Arrays.java:1079) > at java.util.Collections.sort(Collections.java:113) > at > org.apache.commons.jxpath.ri.EvalContext.constructIterator(EvalContext.java:176) > at > org.apache.commons.jxpath.ri.EvalContext.hasNext(EvalContext.java:100) > at > org.apache.commons.jxpath.JXPathContext.selectNodes(JXPathContext.java:648) > at > org.apache.commons.jxpath.ri.model.VariablePointerTestCase.testUnionOfVariableAndNode(VariablePointerTestCase.java:76) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-89) Cannot compare pointers that do not belong to the same tree
[ https://issues.apache.org/jira/browse/JXPATH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510059 ] Sergey Vladimirov commented on JXPATH-89: - For example, Variables interface should allow to return not the object itself, but node pointer, so value will be part of original tree. Then at "sorting stage" variable is unpacked and original node pointer (if such exists) is used. > Cannot compare pointers that do not belong to the same tree > --- > > Key: JXPATH-89 > URL: https://issues.apache.org/jira/browse/JXPATH-89 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: Nightly Builds, 1.2 Final > Environment: codebase: 1.2 or latest version from SVN, JDK 1.4 >Reporter: Sergey Vladimirov > Fix For: 1.3 > > Attachments: VariablePointerTestCase.java > > > For XPath "$var | /MAIN/A" exception is thrown: > org.apache.commons.jxpath.JXPathException: Cannot compare pointers that do > not belong to the same tree: '$var' and '' > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:665) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareTo(NodePointer.java:639) > at java.util.Arrays.mergeSort(Arrays.java:1152) > at java.util.Arrays.sort(Arrays.java:1079) > at java.util.Collections.sort(Collections.java:113) > at > org.apache.commons.jxpath.ri.EvalContext.constructIterator(EvalContext.java:176) > at > org.apache.commons.jxpath.ri.EvalContext.hasNext(EvalContext.java:100) > at > org.apache.commons.jxpath.JXPathContext.selectNodes(JXPathContext.java:648) > at > org.apache.commons.jxpath.ri.model.VariablePointerTestCase.testUnionOfVariableAndNode(VariablePointerTestCase.java:76) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Fileupload 1.3 or 2.0?
On 7/3/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, when applying the fixes for IO-99 to commons-fileupload, I was originally under the impression, that this would be easily possible without any or at least with fully upward compliant API changes. Until I detected that for reasons, which absolutely escape me, someone made FileItem to implement the Serializable interface. Ah, history... Commons FileUpload originated as part of the Turbine framework long, long ago. When it first came to Commons, FileItem extended javax.activation.DataSource, I believe to allow Turbine to directly e-mail uploaded files using JavaMail. In one of my early clean-up sprees, and after some discussion with Turbine folks, I removed the extension of DataSource but left the methods that are defined on DataSource, so that creating a FileItem extension that implemented DataSource was a trivial task. About 6 months after that, a patch supplied by Jon Stevens (of Turbine) was applied that added the extension of Serializable. This was presumably for Turbine compatibility, but I wasn't the person who committed the change, the log message from the person who did was a somewhat unhelpful "PATH ( :) ) from Jon Scott Stevens", my memory isn't good enough to recall an associated thread (this was in 2002), and I'm too lazy to trawl the archives right now to find out if it was discussed at the time. ;-) I can only guess, that someone had the idea to put a FileItem into the HttpSession. But resource tracking within a persistent HttpSession, seems to me to be clearly outside the scope of commons-fileupload. At least, this doesn't fit into the default implementation, which assumes temporary files, for good reasons. At first, I have attempted to fix the problem by making the FileCleaner serializable, but Rahul has rightly pointed out, that I am doing nonsense. See http://www.nabble.com/Re%3A--io--fileupload--svn-commit%3A-r518770---in--jakarta-commons-proper-io-trunk-src%3A-java-org-apache-commons-io-FileCleaningTracker.java-test-org-apache-commons-io-FileUtilsCleanDirectoryTestCase.java-p9520876.html for details. I have reverted the changes in commons-io and rethought my approach. The longer I thought about it, the more I came to the conclusion, that the only clean solution is to accept API changes. In particular, let FileItem no longer implement the Serializable interface. While we are at it, we could as well dissolve the the FileItemFactory and the multipart parser. Remove the whole bunch of deprecated methods. In other words, I propose to resolve FILEUPLOAD-120.or FILEUPLOAD-125 finally by dropping binary compatibilty and declaring the next version as commons-fileupload 2.0, not 1.3. I know that others (in particular Martin) had bigger plans for 2.0: Reimplement the thing based on httpcomponents, or commons-codec, or whatever, and stuff like that. Unfortunately I see noone who'd be ready to do that. In particular, not me. Yeah, I did, and no, I'm not likely to be jumping in at this particular point in time. My original thoughts, to the extent that I can remember them (it was quite a while ago!), were: * We were already starting to clone classes from what was originally HttpClient and is now HttpComponents. One example is the ParameterParser class. When I saw HttpComponents being born, saw a lot of other stuff in there that FileUpload was doing, it looked like it would make a lot of sense to build FileUpload on top of HttpComponents, thus dramatically cutting down the amount of code necessary to build a FileUpload package. * I wanted to reorganise the package structure, for a variety of reasons. The interfaces needed separating from implementations, and we needed to allow for multiple implementations, of different types. Yes, I know we have most of that now. We didn't, originally, and I ended up dealing with it while more or less retaining the original structure and just adding more structure on top of that. There's still a bunch of "litter" lying around that could do with cleaning up (il.e. removing) in a 2.0 release, though. Also, it would still be good to have a much more clear distinction between what is supposed to be public and what is not. (For example, recall the MultipartStream threads from not so long ago.) * I wanted to add a servlet filter along with multiple associated configuration implementations, so that we could provide much more of a drop-in capability, rather than requiring so much explicit integration into most consumer applications and frameworks. I actually went quite far down that path, and might even still have the code lying around somewhere, if anyone wanted to pick that up and finish it. That's about all I can think of right now, although I suspect there was more. I'll post again if I remember anything else. Oh, and I'm definitely in favour of going for a 2.0 release and cleaning up some crud along the way. I just don't think I'll be in a position to help any time soon, I'm afraid. -- Mar
Fwd: [DBCP] Managed Connection support
Forwarding to Commons Dev...
-- Forwarded message --
From: Dain Sundstrom <[EMAIL PROTECTED]>
Date: Jul 4, 2007 2:21 AM
Subject: [DBCP] Managed Connection support
To: Jakarta General List <[EMAIL PROTECTED]>
I just posted a patch JIRA which adds support for container managed
connections to DBCP. In an environment where you have an accessible
transaction manger such as Tomcat (when installed), Geronimo or
OpenEJB, this patch allows adds support for pooling managed
connections to an XA or non-XA data base.
There are many libraries that use DBCP for non-managed environments,
but when additional resources such as a JMS provider are added to the
mix, they have to replace DBCP with something else. If you search
google for XA and DBCP, you will loads of painful direction on how to
replace DBCP with something else. I personally want to use DBCP in
Tomcat with ActiveMQ.
Anyways, enough with motivation
To use the new code, you need access to a TranactionManager (this
code just creates a new Geronimo one).
transactionManager = new TransactionManagerImpl();
Then you either create an XADataSource and
DataSourceXAConectionFactory or as this code does, create a normal
DBCP ConnectionFactory and wrap it with a LocalXAConectionFactory
Properties properties = new Properties();
properties.setProperty("user", "username");
properties.setProperty("password", "password");
ConnectionFactory connectionFactory = new
DriverConnectionFactory(
new TesterDriver(),
"jdbc:apache:commons:testdriver", properties);
// wrap it with a LocalXAConnectionFactory
XAConnectionFactory xaConnectionFactory = new
LocalXAConnectionFactory(
transactionManager,
connectionFactory);
Now you create a pool as normal (full reuse here).
pool = new GenericObjectPool();
pool.setMaxActive(getMaxActive());
pool.setMaxWait(getMaxWait());
// create the pool object factory
PoolableConnectionFactory factory = new
PoolableConnectionFactory(
xaConnectionFactory,
pool,
null,
"SELECT DUMMY FROM DUAL",
true,
true);
pool.setFactory(factory);
Finally, you create a special ManagedDataSource using the pool above
and the special TransactionRegistry object obtained from the
XAConnectionFactory.
ds = new ManagedDataSource(pool,
xaConnectionFactory.getTransactionRegistry());
ds.setAccessToUnderlyingConnectionAllowed(true);
That's it. The data source and connections work as normal until you
start a transaction using the TransactionManager. When you use a
connection while the transaction is active, the connection is
enlisted in the transaction. When the transaction is complete, the
connection is committed (or rolledback) and the connection returns to
normal.
Most of the new code extends existing classes or uses existing
classes without modification. The key to this reuse is the
TransactionRegistry abstraction which maintains a map from the
Connection to the XAResource for that connection. The XAResource is
needed to enlist a connection in a transaction. The
TransactionRegistry and associated TransationContext class
encapsulate all interactions with the TransactionManager leaving the
Connection implementation relatively simple (making reuse easier).
For now the code is contained in the org.apache.commons.dbcp.managed
package, but I would suspect we may want to spread it out amongst the
existing packages instead of creating a feature specific package.
I'm also not sure what additional interfaces people may want such as
equivalents of the BasicDataSource or BasicDataSourceFactory.
The code has tests and has javadoc, but it needs real world testing
and some real docs. I'm going try hooking it into OpenEJB and
running it's massive test suite with a couple of opensource DBs.
Anyways, I hope you all like it and accept the patch. I'm around to
help with changes or whatever. I also ran into a few bugs while
working on this that are already reported in JIRA (like the close
bugs) and am willing to help with those also.
-dain
-
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]
[jira] Created: (DBCP-228) [dbcp] Managed Connection support
[dbcp] Managed Connection support - Key: DBCP-228 URL: https://issues.apache.org/jira/browse/DBCP-228 Project: Commons Dbcp Issue Type: New Feature Reporter: Dain Sundstrom Attachments: ManagedConnection.patch This patch adds support for pooling of ManagedConnections. A managed connection is responsible for managing a database connection in a transactional environment (typically called "Container Managed"). A managed connection opperates like any other connection when no gloabal transaction (a.k.a. XA transaction or JTA Transaction) is in progress. When a global transaction is active a single physical connection to the database is used by all ManagedConnections accessed in the scope of the transaction. Connection sharing means that all data access during a transaction has a consistent view of the database. When the global transaction is committed or rolled back the enlisted connections are committed or rolled back. This patch supports full XADataSources and non-XA data sources using local transaction semantics. non-XA data sources commit and rollback as part of the transaction but are not recoverable in the case of an error because they do not implement the two-phase commit protocol. The patch includes test cases and javadoc comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-228) [dbcp] Managed Connection support
[ https://issues.apache.org/jira/browse/DBCP-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-228: Attachment: ManagedConnection.patch > [dbcp] Managed Connection support > - > > Key: DBCP-228 > URL: https://issues.apache.org/jira/browse/DBCP-228 > Project: Commons Dbcp > Issue Type: New Feature >Reporter: Dain Sundstrom > Attachments: ManagedConnection.patch > > > This patch adds support for pooling of ManagedConnections. A managed > connection is responsible for managing a database connection in a > transactional environment (typically called "Container Managed"). A managed > connection opperates like any other connection when no gloabal transaction > (a.k.a. XA transaction or JTA Transaction) is in progress. When a global > transaction is active a single physical connection to the database is used by > all ManagedConnections accessed in the scope of the transaction. Connection > sharing means that all data access during a transaction has a consistent view > of the database. When the global transaction is committed or rolled back the > enlisted connections are committed or rolled back. > This patch supports full XADataSources and non-XA data sources using local > transaction semantics. non-XA data sources commit and rollback as part of > the transaction but are not recoverable in the case of an error because they > do not implement the two-phase commit protocol. > The patch includes test cases and javadoc comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-183) Compress should allow for writing to Zip Files
[ https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Pugh updated SANDBOX-183: -- I fixed the style concerns, but did not fix the allocation size issue yet. Should not be hard to do, and it should be done. I'm not sure how you plan to modify a zip file, whether you do it the "temp file" way or the "change in place" way, where a process crash would not create a corrupted version of the file. Traditionally, you would do this by creating a temporary zip file, and doing a "mv" on it, so the name changed to the new name, but no data needed to be moved. I'm not sure you can do this in Java, unless you had planned on shelling out the OS (and detecting different OSes to do this). There were two main reasons I wanted to do this in memory: 1) So you would not need any type of temp directory 2) The performance differences can be VAST in some cases. Imagine dealing with large XML or text files, or anything where the compression is significant. If you do the temp file approach, you need to uncompress everything, and write it to a file. Then, re-open all those files and re-compress them. This is not only a lot more CPU time in compressing and uncompressing, but also a lot more data-movement using the disk drive. > Compress should allow for writing to Zip Files > -- > > Key: SANDBOX-183 > URL: https://issues.apache.org/jira/browse/SANDBOX-183 > Project: Commons Sandbox > Issue Type: New Feature > Components: Compress >Affects Versions: Nightly Builds >Reporter: Will Pugh > Attachments: myzip.zip, myzip2.zip > > > Compress should be able to modify existing ZipFiles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-183) Compress should allow for writing to Zip Files
[ https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Pugh updated SANDBOX-183: -- Attachment: myzip2.zip Fixed most of Mario's style concerns. Did not address the memory issue yet. > Compress should allow for writing to Zip Files > -- > > Key: SANDBOX-183 > URL: https://issues.apache.org/jira/browse/SANDBOX-183 > Project: Commons Sandbox > Issue Type: New Feature > Components: Compress >Affects Versions: Nightly Builds >Reporter: Will Pugh > Attachments: myzip.zip, myzip2.zip > > > Compress should be able to modify existing ZipFiles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jexl] linebreaks in jexl expressions
hi,
I tried using the apache-cocoon JX generator (it uses jexl for it's
expressions within the template) to convert linebreak from strings to
elements.
I ran into some problem with searches for linebreaks, like:
${value.indexOf('\n')}
or
${value.indexOf('
')}
The first throws NullPointerException in java reflection classes, the
second throws a Jexl Lexical Exception in the parser.
Was anybody successful to get the index of a linebreak within a string?
Any ideas?
regards,
Christoph
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r553012 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
Author: ggregory
Date: Tue Jul 3 16:01:07 2007
New Revision: 553012
URL: http://svn.apache.org/viewvc?view=rev&rev=553012
Log:
Javadoc: Missing tag for return type.
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java?view=diff&rev=553012&r1=553011&r2=553012
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
Tue Jul 3 16:01:07 2007
@@ -145,6 +145,8 @@
* This is mainly useful for code, which wants to support the new
* [EMAIL PROTECTED] FileCleaningTracker} class while maintain
compatibility with the
* deprecated [EMAIL PROTECTED] FileCleaner}.
+ *
+ * @return the singleton instance
*/
public static FileCleaningTracker getInstance() {
return theInstance;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue for TLP move
Issue created https://issues.apache.org/jira/browse/INFRA-1283 cheers -- Torsten On 04.07.2007, at 00:12, Torsten Curdt wrote: On 03.07.2007, at 23:33, Rahul Akolkar wrote: On 7/3/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: Hope I captured all the input. So if no one objects I will submit the following issue to infrastructure cheers -- Torsten (ii) remote moderators ... I. [EMAIL PROTECTED] moderators are [EMAIL PROTECTED] DOT org Could you please subscribe me using my gmail address (the one this message is sent from) to the private list and also use my gmail address as the moderator? The latter is the more important one -- its much more tedious to use the apache address (I basically forward that to gmail anyway, and need to do a lot more mangling of the reply-to's etc. for that to work well). Thanks. Sure, no problem cheers -- Torsten - 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]
[jira] Created: (JCI-51) Configuration is ignored
Configuration is ignored
Key: JCI-51
URL: https://issues.apache.org/jira/browse/JCI-51
Project: Commons JCI
Issue Type: Bug
Components: compiler eclipse
Affects Versions: 1.0, 1.0RC2, 1.0RC1
Reporter: Torsten Curdt
Assignee: Torsten Curdt
Fix For: 1.0.1
JavaCompilerSettings does nothing for eclipse
{code}
public Map getMap() {
final Map map = new HashMap( defaultEclipseSettings );
map.put( CompilerOptions.OPTION_ReportDeprecation,
CompilerOptions.GENERATE );
map.put( CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_4 );
map.put( CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_4 );
map.put( CompilerOptions.OPTION_Encoding,
"UTF-8" );
return map;
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue for TLP move
On 03.07.2007, at 23:33, Rahul Akolkar wrote: On 7/3/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: Hope I captured all the input. So if no one objects I will submit the following issue to infrastructure cheers -- Torsten (ii) remote moderators ... I. [EMAIL PROTECTED] moderators are [EMAIL PROTECTED] DOT org Could you please subscribe me using my gmail address (the one this message is sent from) to the private list and also use my gmail address as the moderator? The latter is the more important one -- its much more tedious to use the apache address (I basically forward that to gmail anyway, and need to do a lot more mangling of the reply-to's etc. for that to work well). Thanks. Sure, no problem cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moderators for [EMAIL PROTECTED]
On 7/3/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: On Mon, 2007-07-02 at 15:13 -0400, Rahul Akolkar wrote: > On 7/2/07, Matt Benson <[EMAIL PROTECTED]> wrote: > > How arduous a task is it? > > > > > Most I've spent is ~5 minutes in one day. "Requirement" would be > people who generally check email atleast once a day. one of my JAMES TODOs is to create a collaborative email moderation application with web interface but since i haven't even finished fixing the IMAP implementation yet, it seems a long way off... I suspect that would reach a similar level of popularity here as RAT has :-) -Rahul - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-117) Missing unit tests using ant and maven
[ https://issues.apache.org/jira/browse/DIGESTER-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510005 ] Henri Yandell commented on DIGESTER-117: Either run 'maven ant', or replace the existing test stuff with: Which should we do? > Missing unit tests using ant and maven > -- > > Key: DIGESTER-117 > URL: https://issues.apache.org/jira/browse/DIGESTER-117 > Project: Commons Digester > Issue Type: Bug >Affects Versions: 1.8 >Reporter: Gail Badner > > Currently, 136 unit tests are run using maven and 149 unit tests are run > using ant. > The maven build uses the file patterns: > **/*Test.java > **/*TestCase.java > which misses the following tests: > **/plugins/TestAll.java > **/TestFactoryCreate.java > After the missing tests are added to the maven build, 157 tests are executed. > The ant build does not execute the following tests: > LocationTrackerTestCase > NamespaceSnapshotTestCase > OverlappingCallMethodRuleTestCase > After the missing tests to the ant build, 157 tests are executed. > I'm not sure how this should be fixed; should test cases that don't end in > "Test" or "TestCase" be renamed? > When this is fixed, it would be nice if the junit ant task were used to run > the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue for TLP move
On 7/3/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: Hope I captured all the input. So if no one objects I will submit the following issue to infrastructure cheers -- Torsten (ii) remote moderators ... I. [EMAIL PROTECTED] moderators are [EMAIL PROTECTED] DOT org Could you please subscribe me using my gmail address (the one this message is sent from) to the private list and also use my gmail address as the moderator? The latter is the more important one -- its much more tedious to use the apache address (I basically forward that to gmail anyway, and need to do a lot more mangling of the reply-to's etc. for that to work well). Thanks. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moderators for [EMAIL PROTECTED]
On Mon, 2007-07-02 at 15:13 -0400, Rahul Akolkar wrote: > On 7/2/07, Matt Benson <[EMAIL PROTECTED]> wrote: > > How arduous a task is it? > > > > > Most I've spent is ~5 minutes in one day. "Requirement" would be > people who generally check email atleast once a day. one of my JAMES TODOs is to create a collaborative email moderation application with web interface but since i haven't even finished fixing the IMAP implementation yet, it seems a long way off... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] RFC: Fileupload 1.3 or 2.0?
On 7/3/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote: I've read the JIRA's and I don't understand why FileItem/Serializable is relevant. As such I'm struggling to understand this thread :-) It's a design problem. When the DiskFileItem is instantiated, the File isn't necessarily created yet. In other words, the DiskFileItem needs an internal reference to the FileCleaningTracker, which is unfortunately not Serializable. We could continue with ideas like making the FileCleaningTracker transient, but that would violate the contract that the library takes care of removing the temporary files. If there is a minor incompatible change, like making FileItem no longer implement Serializable, then IMO that can be a v2.0 with the same package name. (Minor means that it has no effect on the vast majority of users. In addition, deprecated methods and classes can be removed. If there are larger changes that involve design changes, especially changes to user code (backwards imcompatible) then that should be a v2.0 with a different package name. If you choose the latter option, I would personally prefer to see [fileupload] move to Java 1.5 at the same time. I think, what I intend would be closer to the first scenario. However, I am open for a package name change. I am also open for a move to Java 1.5 sources, because my experiences with retrotranslator are good. Jochen -- "Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r552965 - in /jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/util: BasicTypeConverter.java TypeUtils.java
Author: mbenson
Date: Tue Jul 3 13:07:11 2007
New Revision: 552965
URL: http://svn.apache.org/viewvc?view=rev&rev=552965
Log:
simplify BasicTypeConverter code; add support for untreated Number types +
AtomicBoolean
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/util/BasicTypeConverter.java
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/util/TypeUtils.java
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/util/BasicTypeConverter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/util/BasicTypeConverter.java?view=diff&rev=552965&r1=552964&r2=552965
==
---
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/util/BasicTypeConverter.java
(original)
+++
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/util/BasicTypeConverter.java
Tue Jul 3 13:07:11 2007
@@ -18,6 +18,8 @@
import java.lang.reflect.Array;
import java.lang.reflect.Modifier;
+import java.math.BigDecimal;
+import java.math.BigInteger;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
@@ -46,64 +48,49 @@
* Returns true if it can convert the supplied
* object to the specified class.
*/
-public boolean canConvert(Object object, Class toType) {
+public boolean canConvert(Object object, final Class toType) {
if (object == null) {
return true;
}
-
-if (toType == Object.class) {
-return true;
-}
-
+final Class useType = TypeUtils.wrapPrimitive(toType);
Class fromType = object.getClass();
-if (fromType.equals(toType)) {
-return true;
-}
-if (toType.isAssignableFrom(fromType)) {
+if (useType.isAssignableFrom(fromType)) {
return true;
}
-if (toType == String.class) {
+if (useType == String.class) {
return true;
}
if (object instanceof Boolean) {
-if (toType == boolean.class
-|| Number.class.isAssignableFrom(toType)) {
+if (Number.class.isAssignableFrom(useType)
+|| "java.util.concurrent.atomic.AtomicBoolean"
+.equals(useType.getName())) {
return true;
}
}
if (object instanceof Number) {
-if (toType.isPrimitive()
-|| Number.class.isAssignableFrom(toType)) {
-return true;
-}
-}
-if (object instanceof Character) {
-if (toType == char.class) {
+if (Number.class.isAssignableFrom(useType) || useType ==
Boolean.class) {
return true;
}
}
if (object instanceof String) {
-if (toType.isPrimitive()) {
-return true;
-}
-if (toType == Boolean.class
-|| toType == Character.class
-|| toType == Byte.class
-|| toType == Short.class
-|| toType == Integer.class
-|| toType == Long.class
-|| toType == Float.class
-|| toType == Double.class) {
+if (useType == Boolean.class
+|| useType == Character.class
+|| useType == Byte.class
+|| useType == Short.class
+|| useType == Integer.class
+|| useType == Long.class
+|| useType == Float.class
+|| useType == Double.class) {
return true;
}
}
if (fromType.isArray()) {
// Collection -> array
-if (toType.isArray()) {
-Class cType = toType.getComponentType();
+if (useType.isArray()) {
+Class cType = useType.getComponentType();
int length = Array.getLength(object);
for (int i = 0; i < length; i++) {
Object value = Array.get(object, i);
@@ -113,19 +100,19 @@
}
return true;
}
-if (Collection.class.isAssignableFrom(toType)) {
-return canCreateCollection(toType);
+if (Collection.class.isAssignableFrom(useType)) {
+return canCreateCollection(useType);
}
if (Array.getLength(object) > 0) {
Object value = Array.get(object, 0);
-return canConvert(value, toType);
+return canConvert(value, useType);
}
-return canConvert("", toType);
+return canConvert("", useType);
}
if (object instanceof Collection) {
// Collection -> array
-if (toType.
Re: [fileupload] RFC: Fileupload 1.3 or 2.0?
Jochen Wiedmann wrote: when applying the fixes for IO-99 to commons-fileupload, I was originally under the impression, that this would be easily possible without any or at least with fully upward compliant API changes. Until I detected that for reasons, which absolutely escape me, someone made FileItem to implement the Serializable interface. I've read the JIRA's and I don't understand why FileItem/Serializable is relevant. As such I'm struggling to understand this thread :-) The longer I thought about it, the more I came to the conclusion, that the only clean solution is to accept API changes. In particular, let FileItem no longer implement the Serializable interface. While we are at it, we could as well dissolve the the FileItemFactory and the multipart parser. Remove the whole bunch of deprecated methods. In other words, I propose to resolve FILEUPLOAD-120.or FILEUPLOAD-125 finally by dropping binary compatibilty and declaring the next version as commons-fileupload 2.0, not 1.3. OK, here is my view on this (I'll get in early this time). If there is a minor incompatible change, like making FileItem no longer implement Serializable, then IMO that can be a v2.0 with the same package name. (Minor means that it has no effect on the vast majority of users. In addition, deprecated methods and classes can be removed. If there are larger changes that involve design changes, especially changes to user code (backwards imcompatible) then that should be a v2.0 with a different package name. If you choose the latter option, I would personally prefer to see [fileupload] move to Java 1.5 at the same time. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Fileupload 1.3 or 2.0?
+1. Removing deprecations is a worthy cause for a major release in and of itself. In fact, I'd suggest that removing deprecated and/or obviously wrong code is a necessary precursor to a redesign. Plus redesigns always scare me, since you never seem to get what you were expecting. :) On 7/3/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, when applying the fixes for IO-99 to commons-fileupload, I was originally under the impression, that this would be easily possible without any or at least with fully upward compliant API changes. Until I detected that for reasons, which absolutely escape me, someone made FileItem to implement the Serializable interface. I can only guess, that someone had the idea to put a FileItem into the HttpSession. But resource tracking within a persistent HttpSession, seems to me to be clearly outside the scope of commons-fileupload. At least, this doesn't fit into the default implementation, which assumes temporary files, for good reasons. At first, I have attempted to fix the problem by making the FileCleaner serializable, but Rahul has rightly pointed out, that I am doing nonsense. See http://www.nabble.com/Re%3A--io--fileupload--svn-commit%3A-r518770---in--jakarta-commons-proper-io-trunk-src%3A-java-org-apache-commons-io-FileCleaningTracker.java-test-org-apache-commons-io-FileUtilsCleanDirectoryTestCase.java-p9520876.html for details. I have reverted the changes in commons-io and rethought my approach. The longer I thought about it, the more I came to the conclusion, that the only clean solution is to accept API changes. In particular, let FileItem no longer implement the Serializable interface. While we are at it, we could as well dissolve the the FileItemFactory and the multipart parser. Remove the whole bunch of deprecated methods. In other words, I propose to resolve FILEUPLOAD-120.or FILEUPLOAD-125 finally by dropping binary compatibilty and declaring the next version as commons-fileupload 2.0, not 1.3. I know that others (in particular Martin) had bigger plans for 2.0: Reimplement the thing based on httpcomponents, or commons-codec, or whatever, and stuff like that. Unfortunately I see noone who'd be ready to do that. In particular, not me. Thoughts? Jochen -- "Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RFC: Fileupload 1.3 or 2.0?
Hi, when applying the fixes for IO-99 to commons-fileupload, I was originally under the impression, that this would be easily possible without any or at least with fully upward compliant API changes. Until I detected that for reasons, which absolutely escape me, someone made FileItem to implement the Serializable interface. I can only guess, that someone had the idea to put a FileItem into the HttpSession. But resource tracking within a persistent HttpSession, seems to me to be clearly outside the scope of commons-fileupload. At least, this doesn't fit into the default implementation, which assumes temporary files, for good reasons. At first, I have attempted to fix the problem by making the FileCleaner serializable, but Rahul has rightly pointed out, that I am doing nonsense. See http://www.nabble.com/Re%3A--io--fileupload--svn-commit%3A-r518770---in--jakarta-commons-proper-io-trunk-src%3A-java-org-apache-commons-io-FileCleaningTracker.java-test-org-apache-commons-io-FileUtilsCleanDirectoryTestCase.java-p9520876.html for details. I have reverted the changes in commons-io and rethought my approach. The longer I thought about it, the more I came to the conclusion, that the only clean solution is to accept API changes. In particular, let FileItem no longer implement the Serializable interface. While we are at it, we could as well dissolve the the FileItemFactory and the multipart parser. Remove the whole bunch of deprecated methods. In other words, I propose to resolve FILEUPLOAD-120.or FILEUPLOAD-125 finally by dropping binary compatibilty and declaring the next version as commons-fileupload 2.0, not 1.3. I know that others (in particular Martin) had bigger plans for 2.0: Reimplement the thing based on httpcomponents, or commons-codec, or whatever, and stuff like that. Unfortunately I see noone who'd be ready to do that. In particular, not me. Thoughts? Jochen -- "Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 4th attempt: Release commons-io 1.3.2
On 7/3/07, Gary Gregory <[EMAIL PROTECTED]> wrote: It seems odd that the site (http://jakarta.apache.org/commons/io/) is live but not [announce]'d and the links point to 1.3.1 downloads but are labeled 1.3.2. To the best of my knowledge, it is common to wait 24 hours before announcing, so that the mirrors can catch up. Jochen -- "Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RESULT] 4th attempt: Release commons-io 1.3.2
It seems odd that the site (http://jakarta.apache.org/commons/io/) is live but not [announce]'d and the links point to 1.3.1 downloads but are labeled 1.3.2. Thank you, Gary > -Original Message- > From: Jochen Wiedmann [mailto:[EMAIL PROTECTED] > Sent: Monday, July 02, 2007 12:14 PM > To: Jakarta Commons Developers List > Subject: [RESULT] 4th attempt: Release commons-io 1.3.2 > > Thanks god, this vote has passed: > > +1: Stephen, Dion, Oliver, Phil, Rahul, Myself > > I am ignoring sebb's posting for this release. I'll pick up his > comments for the new web site. Hope that suits anyone. > > Thanks, > > Jochen > > > -- > "Besides, manipulating elections is under penalty of law, resulting in > a preventative effect against manipulating elections. > > The german government justifying the use of electronic voting machines > and obviously believing that we don't need a police, because all > illegal actions are forbidden. > > http://dip.bundestag.de/btd/16/051/1605194.pdf > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compess] any objections to me jumping in?
I know there was also a lot of work done by a contributor a little while back (was that applied to SVN already?) That was Christian ...yes, I applied that. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-287) Missing unit tests using ant and unit test errors using maven
[ https://issues.apache.org/jira/browse/BEANUTILS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509964 ] Niall Pemberton commented on BEANUTILS-287: --- -1 to generating the build.xml using "maven ant" - IMO it creates a right mess and theres no point ruining a working ant build.xml > Missing unit tests using ant and unit test errors using maven > -- > > Key: BEANUTILS-287 > URL: https://issues.apache.org/jira/browse/BEANUTILS-287 > Project: Commons BeanUtils > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Gail Badner > > When running unit tests with ant, 402 tests are executed and all are > successful. > The following test cases are are not executed with ant: >ConstructorUtilsTestCase >FileConverterTestCase >URLConverterTestCase > When running unit tests with maven, 413 tests are executed, but 2 fail: >BeanificationTestCase.testMemoryTestMethodology >LocaleBeanificationTestCase.testMemoryTestMethodology > Both errors are due to java.lang.ClassNotFoundException: > org.apache.commons.beanutils.BetaBean > When this is fixed, it would be nice if the junit ant task were used to run > the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-287) Missing unit tests using ant and unit test errors using maven
[ https://issues.apache.org/jira/browse/BEANUTILS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509962 ] Henri Yandell commented on BEANUTILS-287: - Either we should 'maven ant' it, or replace all the test bits with: > Missing unit tests using ant and unit test errors using maven > -- > > Key: BEANUTILS-287 > URL: https://issues.apache.org/jira/browse/BEANUTILS-287 > Project: Commons BeanUtils > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Gail Badner > > When running unit tests with ant, 402 tests are executed and all are > successful. > The following test cases are are not executed with ant: >ConstructorUtilsTestCase >FileConverterTestCase >URLConverterTestCase > When running unit tests with maven, 413 tests are executed, but 2 fail: >BeanificationTestCase.testMemoryTestMethodology >LocaleBeanificationTestCase.testMemoryTestMethodology > Both errors are due to java.lang.ClassNotFoundException: > org.apache.commons.beanutils.BetaBean > When this is fixed, it would be nice if the junit ant task were used to run > the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-89) Cannot compare pointers that do not belong to the same tree
[ https://issues.apache.org/jira/browse/JXPATH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509960 ] Matt Benson commented on JXPATH-89: --- But that's just the problem: a variable isn't part of the object graph represented by the JXPathContext; it exists parallel to that graph. So how would you expect the results of such a query to sort? > Cannot compare pointers that do not belong to the same tree > --- > > Key: JXPATH-89 > URL: https://issues.apache.org/jira/browse/JXPATH-89 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: Nightly Builds, 1.2 Final > Environment: codebase: 1.2 or latest version from SVN, JDK 1.4 >Reporter: Sergey Vladimirov > Fix For: 1.3 > > Attachments: VariablePointerTestCase.java > > > For XPath "$var | /MAIN/A" exception is thrown: > org.apache.commons.jxpath.JXPathException: Cannot compare pointers that do > not belong to the same tree: '$var' and '' > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:665) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareTo(NodePointer.java:639) > at java.util.Arrays.mergeSort(Arrays.java:1152) > at java.util.Arrays.sort(Arrays.java:1079) > at java.util.Collections.sort(Collections.java:113) > at > org.apache.commons.jxpath.ri.EvalContext.constructIterator(EvalContext.java:176) > at > org.apache.commons.jxpath.ri.EvalContext.hasNext(EvalContext.java:100) > at > org.apache.commons.jxpath.JXPathContext.selectNodes(JXPathContext.java:648) > at > org.apache.commons.jxpath.ri.model.VariablePointerTestCase.testUnionOfVariableAndNode(VariablePointerTestCase.java:76) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-89) Cannot compare pointers that do not belong to the same tree
[ https://issues.apache.org/jira/browse/JXPATH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509956 ] Sergey Vladimirov commented on JXPATH-89: - Matt, The example is in original test case. I extract several variables from original tree and want to select them (and sort) in one XPath expression. I can't do this right now, because variables are from different trees... but is it possible to "remember" that variables are from original tree? > Cannot compare pointers that do not belong to the same tree > --- > > Key: JXPATH-89 > URL: https://issues.apache.org/jira/browse/JXPATH-89 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: Nightly Builds, 1.2 Final > Environment: codebase: 1.2 or latest version from SVN, JDK 1.4 >Reporter: Sergey Vladimirov > Fix For: 1.3 > > Attachments: VariablePointerTestCase.java > > > For XPath "$var | /MAIN/A" exception is thrown: > org.apache.commons.jxpath.JXPathException: Cannot compare pointers that do > not belong to the same tree: '$var' and '' > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:665) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareTo(NodePointer.java:639) > at java.util.Arrays.mergeSort(Arrays.java:1152) > at java.util.Arrays.sort(Arrays.java:1079) > at java.util.Collections.sort(Collections.java:113) > at > org.apache.commons.jxpath.ri.EvalContext.constructIterator(EvalContext.java:176) > at > org.apache.commons.jxpath.ri.EvalContext.hasNext(EvalContext.java:100) > at > org.apache.commons.jxpath.JXPathContext.selectNodes(JXPathContext.java:648) > at > org.apache.commons.jxpath.ri.model.VariablePointerTestCase.testUnionOfVariableAndNode(VariablePointerTestCase.java:76) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue for TLP move
+1 Looks good to me :) Niall On 7/3/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: Hope I captured all the input. So if no one objects I will submit the following issue to infrastructure cheers -- Torsten - The board has agreed to create the Commons project. (Please note that there has been a previous commons TLP) To aid in the process, would the Infrastructure team please do the following: #=== [1] Root Tasks Create unix group "commons". If it already exists remove previous members. Add following usernames to group "commons": antoine bayard billbarker bodewig brentworden brett bspeakmon craigmcc dennisl dflorey dfs dims dion dlr dmitri ebourg epugh felipeal fredrik germuska ggregory hchar henning hgilde imario jcarman jfclere jkeyes jmitchell jochen joehni joerg knut kohsuke leosutic luc martinc mbecke mbenson mrdon mturk mvdb ngn niallp nuttycom oglueck oheger olegk ozeigermann pietsch polx proyal psteitz rahul rdonkin rolandw roxspring rwinston sandymac scohen scolebourne sebb sgoeschl skitching stevencaswell sullis tcurdt tobrien trygvis vgritsenko yonik Verify that domain "commons.apache.org" is correctly setup. #=== [1] Mailing List (i) addresses I. [EMAIL PROTECTED] * Henri Yandell<[EMAIL PROTECTED]> * Jochen Wiedmann <[EMAIL PROTECTED]> * Mario Ivankovits <[EMAIL PROTECTED]> * Stephen Colebourne <[EMAIL PROTECTED]> * Dennis Lundberg <[EMAIL PROTECTED]> * Niall Pemberton <[EMAIL PROTECTED]> * Martin van den Bemt <[EMAIL PROTECTED]> * Oliver Zeigermann<[EMAIL PROTECTED]> * Jörg Schaible<[EMAIL PROTECTED]> * Oliver Heger <[EMAIL PROTECTED]> * Matt Benson <[EMAIL PROTECTED]> * Martin Cooper<[EMAIL PROTECTED]> * Phil Steitz <[EMAIL PROTECTED]> * Torsten Curdt<[EMAIL PROTECTED]> * Daniel Savarese <[EMAIL PROTECTED]> * Rory Winston <[EMAIL PROTECTED]> * Luc Maisonobe<[EMAIL PROTECTED]> * Joerg Pietschmann<[EMAIL PROTECTED]> * Dion Gillard <[EMAIL PROTECTED]> * Brent Worden <[EMAIL PROTECTED]> * Simon Kitching <[EMAIL PROTECTED]> * Rahul Akolkar<[EMAIL PROTECTED]> II. [EMAIL PROTECTED] subscribers from commons- [EMAIL PROTECTED] III. [EMAIL PROTECTED] subscribers from commons- [EMAIL PROTECTED] IV. [EMAIL PROTECTED] subscribers from commons- [EMAIL PROTECTED] V. [EMAIL PROTECTED]subscribers from commons- [EMAIL PROTECTED] (ii) remote moderators ... I. [EMAIL PROTECTED] moderators are [EMAIL PROTECTED],[EMAIL PROTECTED] II. [EMAIL PROTECTED] moderators from commons- [EMAIL PROTECTED] III. [EMAIL PROTECTED] moderators from commons- [EMAIL PROTECTED] IV. [EMAIL PROTECTED] moderators from commons- [EMAIL PROTECTED] V. [EMAIL PROTECTED]moderators from commons- [EMAIL PROTECTED] (iii) archives I. [EMAIL PROTECTED] to be archived in the private area. II. http://commons.apache.org/mail/commons/user/MM.gz III. http://commons.apache.org/mail/commons/dev/MM.gz IV. http://commons.apache.org/mail/commons/commits/MM.gz V. http://commons.apache.org/mail/commons/issues/MM.gz (iv) options I. Reply-To: Header [X] yes [ ] no II. Message Trailer [X] yes [ ] no #=== [2] Source Control (i) Subversion Move the existing jakarta/commons tree to TLP (ii) Authorization Commit access should be granted to all members of the commons group [1] #=== [3] Wiki (i) Wiki pages need to be migrated http://wiki.apache.org/jakarta-commons/FrontPage This is/will be done by the community itself. #=== [4] Bug tracking (i) Project URLs need to be migrated This is/will be done by the community itself. - 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 PROTECTE
Issue for TLP move
Hope I captured all the input. So if no one objects I will submit the following issue to infrastructure cheers -- Torsten - The board has agreed to create the Commons project. (Please note that there has been a previous commons TLP) To aid in the process, would the Infrastructure team please do the following: #=== [1] Root Tasks Create unix group "commons". If it already exists remove previous members. Add following usernames to group "commons": antoine bayard billbarker bodewig brentworden brett bspeakmon craigmcc dennisl dflorey dfs dims dion dlr dmitri ebourg epugh felipeal fredrik germuska ggregory hchar henning hgilde imario jcarman jfclere jkeyes jmitchell jochen joehni joerg knut kohsuke leosutic luc martinc mbecke mbenson mrdon mturk mvdb ngn niallp nuttycom oglueck oheger olegk ozeigermann pietsch polx proyal psteitz rahul rdonkin rolandw roxspring rwinston sandymac scohen scolebourne sebb sgoeschl skitching stevencaswell sullis tcurdt tobrien trygvis vgritsenko yonik Verify that domain "commons.apache.org" is correctly setup. #=== [1] Mailing List (i) addresses I. [EMAIL PROTECTED] * Henri Yandell<[EMAIL PROTECTED]> * Jochen Wiedmann <[EMAIL PROTECTED]> * Mario Ivankovits <[EMAIL PROTECTED]> * Stephen Colebourne <[EMAIL PROTECTED]> * Dennis Lundberg <[EMAIL PROTECTED]> * Niall Pemberton <[EMAIL PROTECTED]> * Martin van den Bemt <[EMAIL PROTECTED]> * Oliver Zeigermann<[EMAIL PROTECTED]> * Jörg Schaible<[EMAIL PROTECTED]> * Oliver Heger <[EMAIL PROTECTED]> * Matt Benson <[EMAIL PROTECTED]> * Martin Cooper<[EMAIL PROTECTED]> * Phil Steitz <[EMAIL PROTECTED]> * Torsten Curdt<[EMAIL PROTECTED]> * Daniel Savarese <[EMAIL PROTECTED]> * Rory Winston <[EMAIL PROTECTED]> * Luc Maisonobe<[EMAIL PROTECTED]> * Joerg Pietschmann<[EMAIL PROTECTED]> * Dion Gillard <[EMAIL PROTECTED]> * Brent Worden <[EMAIL PROTECTED]> * Simon Kitching <[EMAIL PROTECTED]> * Rahul Akolkar<[EMAIL PROTECTED]> II. [EMAIL PROTECTED] subscribers from commons- [EMAIL PROTECTED] III. [EMAIL PROTECTED] subscribers from commons- [EMAIL PROTECTED] IV. [EMAIL PROTECTED] subscribers from commons- [EMAIL PROTECTED] V. [EMAIL PROTECTED]subscribers from commons- [EMAIL PROTECTED] (ii) remote moderators ... I. [EMAIL PROTECTED] moderators are [EMAIL PROTECTED],[EMAIL PROTECTED] II. [EMAIL PROTECTED] moderators from commons- [EMAIL PROTECTED] III. [EMAIL PROTECTED] moderators from commons- [EMAIL PROTECTED] IV. [EMAIL PROTECTED] moderators from commons- [EMAIL PROTECTED] V. [EMAIL PROTECTED]moderators from commons- [EMAIL PROTECTED] (iii) archives I. [EMAIL PROTECTED] to be archived in the private area. II. http://commons.apache.org/mail/commons/user/MM.gz III. http://commons.apache.org/mail/commons/dev/MM.gz IV. http://commons.apache.org/mail/commons/commits/MM.gz V. http://commons.apache.org/mail/commons/issues/MM.gz (iv) options I. Reply-To: Header [X] yes [ ] no II. Message Trailer [X] yes [ ] no #=== [2] Source Control (i) Subversion Move the existing jakarta/commons tree to TLP (ii) Authorization Commit access should be granted to all members of the commons group [1] #=== [3] Wiki (i) Wiki pages need to be migrated http://wiki.apache.org/jakarta-commons/FrontPage This is/will be done by the community itself. #=== [4] Bug tracking (i) Project URLs need to be migrated This is/will be done by the community itself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-227) Some unit tests are run using maven, but not ant
[ https://issues.apache.org/jira/browse/DBCP-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DBCP-227: --- Attachment: DBCP-227.patch Attachment: Tests added in, uses junit, fixes commons logging property. Alternatively, could use 'maven ant', I'm not sure at first glance if dbcp is maintaining the custom ant on purpose (ie for the jdbc2/3 support). > Some unit tests are run using maven, but not ant > > > Key: DBCP-227 > URL: https://issues.apache.org/jira/browse/DBCP-227 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.2.2 >Reporter: Gail Badner > Attachments: DBCP-227.patch > > > The following unit tests run using maven, but not ant: > TestJOCLContentHandler > TestPoolingDataSource > TestJndi > When this is fixed, it would be nice if the junit ant task were used to run > the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r552889 - /jakarta/commons/proper/jxpath/trunk/rat.xml
Author: mbenson Date: Tue Jul 3 08:58:29 2007 New Revision: 552889 URL: http://svn.apache.org/viewvc?view=rev&rev=552889 Log: add Ant buildfile to run RAT Added: jakarta/commons/proper/jxpath/trunk/rat.xml (with props) Added: jakarta/commons/proper/jxpath/trunk/rat.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/rat.xml?view=auto&rev=552889 == --- jakarta/commons/proper/jxpath/trunk/rat.xml (added) +++ jakarta/commons/proper/jxpath/trunk/rat.xml Tue Jul 3 08:58:29 2007 @@ -0,0 +1,11 @@ + + + + + + + + + + + Propchange: jakarta/commons/proper/jxpath/trunk/rat.xml -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JXPath setting values with predicates
--- Dustin Whitney <[EMAIL PROTECTED]> wrote: > Well, I quit the job where I was going to use that. > However, it would be > awesome if what I described worked :) I remember > searching through the code > and making a few changes, but not really getting > anywhere. Seems kind of strange now that I read it carefully. There is code in the RI that disallows this, probably because it's a PITA. :) That said, there would be no reason you couldn't extend the RI to allow this, in theory. I'll leave it at that. Thanks, Matt > > -Dustin > > On 7/3/07, Matt Benson <[EMAIL PROTECTED]> wrote: > > > > Was just going through my flagged mail and > realized > > I'd never followed up here. What's your current > > status, Dustin? > > > > -Matt > > > > --- Dustin Whitney <[EMAIL PROTECTED]> > wrote: > > > > > Hello, > > > > > > I like JXPath, but I'd like to make a change > to > > > the source, and I'm > > > hoping for some advice here. When using the > > > JXPathContext.createPathAndSetValue() method on > some > > > Java beans, I get an > > > exception if something like: > > > > > > /[EMAIL PROTECTED] = 'Rental > Reimbursement' > > > and @detailName = > > > 'Number']/detail > > > > > > results in the predicate returning an null > value. > > > But, using the same > > > createPathAndSetValue() method with that XPath > when > > > the predicate does not > > > result in null, works just fine. I could easily > > > turn my predicate into an > > > object if I were dumped into my > > > AbstractFactory.createObject() method. Can > > > anyone suggest what I might change to make that > > > happen, or give a good > > > explanation as to why I should not do that? > > > > > > Thanks, > > > Dustin > > > > > > > > > > > > > > > > Shape Yahoo! in your own image. Join our Network > Research Panel today! > > > http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > > > > > Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] commons.apache.org initial list of committers
You are in that list, Dims ;) On 03.07.2007, at 13:21, Davanum Srinivas wrote: I'd like to keep mine. thanks, dims On 7/3/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: As you know we are preparing for the infrastructure work to go TLP. Part of that is to compile a the initial list of committers. The idea was to do a little spring cleaning. So all committers that have been active in the past 2 years will get moved automatically. For everyone else: if you want to get your commit rights transfered straight away - please tell us now. If you don't - no problem. You will NOT LOOSE YOUR COMMIT RIGHTS. Any original committer can just ask and will get his commit access back. Please check the list for your name. antoine bayard billbarker bodewig brentworden brett bspeakmon craigmcc dennisl dflorey dfs dims dion dlr dmitri ebourg epugh felipeal fredrik germuska ggregory hchar henning hgilde imario jcarman jfclere jkeyes jmitchell jochen joehni joerg knut kohsuke leosutic luc martinc mbecke mbenson mrdon mturk mvdb ngn niallp nuttycom oglueck oheger olegk ozeigermann pietsch polx proyal psteitz rahul rdonkin rolandw roxspring rwinston sandymac scohen scolebourne sebb sgoeschl skitching stevencaswell sullis tcurdt tobrien trygvis vgritsenko yonik cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - 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]
[jira] Commented: (JXPATH-89) Cannot compare pointers that do not belong to the same tree
[ https://issues.apache.org/jira/browse/JXPATH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509884 ] Matt Benson commented on JXPATH-89: --- Pretending a variable is a child of some random parent seems like the workaround to me. I removed the exception because I saw the problem differently: if two nodes have no common parents, then their comparison is undefined and thus irrelevant. I'm not sure what you're referring to when you say sorting is not working. The existing testcases that relied on the sort did not break, so I can only assume you're talking about sorting things that formerly broke in the manner of your original report. Can you provide an example and explain what expectations you have that are not being met? > Cannot compare pointers that do not belong to the same tree > --- > > Key: JXPATH-89 > URL: https://issues.apache.org/jira/browse/JXPATH-89 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: Nightly Builds, 1.2 Final > Environment: codebase: 1.2 or latest version from SVN, JDK 1.4 >Reporter: Sergey Vladimirov > Fix For: 1.3 > > Attachments: VariablePointerTestCase.java > > > For XPath "$var | /MAIN/A" exception is thrown: > org.apache.commons.jxpath.JXPathException: Cannot compare pointers that do > not belong to the same tree: '$var' and '' > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:665) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareNodePointers(NodePointer.java:649) > at > org.apache.commons.jxpath.ri.model.NodePointer.compareTo(NodePointer.java:639) > at java.util.Arrays.mergeSort(Arrays.java:1152) > at java.util.Arrays.sort(Arrays.java:1079) > at java.util.Collections.sort(Collections.java:113) > at > org.apache.commons.jxpath.ri.EvalContext.constructIterator(EvalContext.java:176) > at > org.apache.commons.jxpath.ri.EvalContext.hasNext(EvalContext.java:100) > at > org.apache.commons.jxpath.JXPathContext.selectNodes(JXPathContext.java:648) > at > org.apache.commons.jxpath.ri.model.VariablePointerTestCase.testUnionOfVariableAndNode(VariablePointerTestCase.java:76) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JXPath setting values with predicates
Was just going through my flagged mail and realized I'd never followed up here. What's your current status, Dustin? -Matt --- Dustin Whitney <[EMAIL PROTECTED]> wrote: > Hello, > > I like JXPath, but I'd like to make a change to > the source, and I'm > hoping for some advice here. When using the > JXPathContext.createPathAndSetValue() method on some > Java beans, I get an > exception if something like: > > /[EMAIL PROTECTED] = 'Rental Reimbursement' > and @detailName = > 'Number']/detail > > results in the predicate returning an null value. > But, using the same > createPathAndSetValue() method with that XPath when > the predicate does not > result in null, works just fine. I could easily > turn my predicate into an > object if I were dumped into my > AbstractFactory.createObject() method. Can > anyone suggest what I might change to make that > happen, or give a good > explanation as to why I should not do that? > > Thanks, > Dustin > Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-124) fix website permissions
[ https://issues.apache.org/jira/browse/IO-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann closed IO-124. -- Resolution: Fixed Seems there has been a syncing issue. Both URL's are now shown as expected. > fix website permissions > --- > > Key: IO-124 > URL: https://issues.apache.org/jira/browse/IO-124 > Project: Commons IO > Issue Type: Bug >Reporter: Godmar Back > > http://jakarta.apache.org/commons/io/api-release/index.html > says: > Forbidden > You don't have permission to access /commons/io/api-release/index.html on > this server. > Apache/2.3.0-dev (Unix) Server at jakarta.apache.org Port 80 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] commons.apache.org initial list of committers
I'd like to keep mine. thanks, dims On 7/3/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: As you know we are preparing for the infrastructure work to go TLP. Part of that is to compile a the initial list of committers. The idea was to do a little spring cleaning. So all committers that have been active in the past 2 years will get moved automatically. For everyone else: if you want to get your commit rights transfered straight away - please tell us now. If you don't - no problem. You will NOT LOOSE YOUR COMMIT RIGHTS. Any original committer can just ask and will get his commit access back. Please check the list for your name. antoine bayard billbarker bodewig brentworden brett bspeakmon craigmcc dennisl dflorey dfs dims dion dlr dmitri ebourg epugh felipeal fredrik germuska ggregory hchar henning hgilde imario jcarman jfclere jkeyes jmitchell jochen joehni joerg knut kohsuke leosutic luc martinc mbecke mbenson mrdon mturk mvdb ngn niallp nuttycom oglueck oheger olegk ozeigermann pietsch polx proyal psteitz rahul rdonkin rolandw roxspring rwinston sandymac scohen scolebourne sebb sgoeschl skitching stevencaswell sullis tcurdt tobrien trygvis vgritsenko yonik cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-161) Minimize using of LIST command in the FTP provider
[ https://issues.apache.org/jira/browse/VFS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits updated VFS-161: - Priority: Major (was: Minor) > Minimize using of LIST command in the FTP provider > -- > > Key: VFS-161 > URL: https://issues.apache.org/jira/browse/VFS-161 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Alex Crane > > I have a big bis storage of files (about 10 TBytes). > Path to file looks like > /storage/storage1/node1/76423fds7g78df6gdf7hdfh/2384dg7sdfg8dfh.dat > Existance checking and deleteing of files takes very long time > because of LIST command: > LIST /storage > ... > LIST /storage/storage1 > ... > LIST /storage/storage1/node1 > > LIST /storage/storage1/node1/76423fds7g78df6gdf7hdfh > and so on. > For example, there is no need to perform LIST command to delete file. I`m > using FTPClients from commons.net and it works 1000x faster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (VFS-161) Minimize using of LIST command in the FTP provider
[ https://issues.apache.org/jira/browse/VFS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509808 ] Sebastian Skoglund edited comment on VFS-161 at 7/3/07 2:53 AM: This is a major performance problem when handling many tasks in a "batch-job". If I for instance want to create a numerous of files, rename and delete some others it can take several minutes for a fairly small amount of operations. I have done some testing and measurments regarding this matter and if I want to create, rename and delete only 22 files (with a total size of ~300kB) it takes as long as 72 seconds, which is unacceptable in my opinion. FYI.. the same job takes 2 seconds using SFTP. was: This is a major performance problem when handling many tasks in a "batch-job". If I for instance want to create a numerous of files, rename and delete some others it can take several minutes for a fairly small amount of operations. I have done some testing and measurments regarding this matter and if I want to create, rename and delete only 22 files (with a total size of ~300kB) it takes as long as 72 seconds, which is unacceptable in my opinion. > Minimize using of LIST command in the FTP provider > -- > > Key: VFS-161 > URL: https://issues.apache.org/jira/browse/VFS-161 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Alex Crane >Priority: Minor > > I have a big bis storage of files (about 10 TBytes). > Path to file looks like > /storage/storage1/node1/76423fds7g78df6gdf7hdfh/2384dg7sdfg8dfh.dat > Existance checking and deleteing of files takes very long time > because of LIST command: > LIST /storage > ... > LIST /storage/storage1 > ... > LIST /storage/storage1/node1 > > LIST /storage/storage1/node1/76423fds7g78df6gdf7hdfh > and so on. > For example, there is no need to perform LIST command to delete file. I`m > using FTPClients from commons.net and it works 1000x faster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VALIDATOR-231) Missing unit tests using maven
[ https://issues.apache.org/jira/browse/VALIDATOR-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved VALIDATOR-231. --- Resolution: Invalid MultipleTests has already been renamed to MultipleTest in January (revision 493905) > Missing unit tests using maven > -- > > Key: VALIDATOR-231 > URL: https://issues.apache.org/jira/browse/VALIDATOR-231 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.3.1 Release >Reporter: Gail Badner > > The maven build uses the file pattern "**/*Test.java", so it misses > org.apache.commons.validator.MultipleTests. This test is run when using ant. > MultipleTests should probably be renamed to MultipleTest. > When this is fixed, it would be nice if the junit ant task were used to run > the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-161) Minimize using of LIST command in the FTP provider
[ https://issues.apache.org/jira/browse/VFS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509808 ] Sebastian Skoglund commented on VFS-161: This is a major performance problem when handling many tasks in a "batch-job". If I for instance want to create a numerous of files, rename and delete some others it can take several minutes for a fairly small amount of operations. I have done some testing and measurments regarding this matter and if I want to create, rename and delete only 22 files (with a total size of ~300kB) it takes as long as 72 seconds, which is unacceptable in my opinion. > Minimize using of LIST command in the FTP provider > -- > > Key: VFS-161 > URL: https://issues.apache.org/jira/browse/VFS-161 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Alex Crane >Priority: Minor > > I have a big bis storage of files (about 10 TBytes). > Path to file looks like > /storage/storage1/node1/76423fds7g78df6gdf7hdfh/2384dg7sdfg8dfh.dat > Existance checking and deleteing of files takes very long time > because of LIST command: > LIST /storage > ... > LIST /storage/storage1 > ... > LIST /storage/storage1/node1 > > LIST /storage/storage1/node1/76423fds7g78df6gdf7hdfh > and so on. > For example, there is no need to perform LIST command to delete file. I`m > using FTPClients from commons.net and it works 1000x faster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] commons.apache.org initial list of committers
As you know we are preparing for the infrastructure work to go TLP. Part of that is to compile a the initial list of committers. The idea was to do a little spring cleaning. So all committers that have been active in the past 2 years will get moved automatically. For everyone else: if you want to get your commit rights transfered straight away - please tell us now. If you don't - no problem. You will NOT LOOSE YOUR COMMIT RIGHTS. Any original committer can just ask and will get his commit access back. Please check the list for your name. antoine bayard billbarker bodewig brentworden brett bspeakmon craigmcc dennisl dflorey dfs dims dion dlr dmitri ebourg epugh felipeal fredrik germuska ggregory hchar henning hgilde imario jcarman jfclere jkeyes jmitchell jochen joehni joerg knut kohsuke leosutic luc martinc mbecke mbenson mrdon mturk mvdb ngn niallp nuttycom oglueck oheger olegk ozeigermann pietsch polx proyal psteitz rahul rdonkin rolandw roxspring rwinston sandymac scohen scolebourne sebb sgoeschl skitching stevencaswell sullis tcurdt tobrien trygvis vgritsenko yonik cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-124) fix website permissions
[
https://issues.apache.org/jira/browse/IO-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509769
]
Jochen Wiedmann commented on IO-124:
Anybody got an explanation? I have just repeated what I already did yesterday:
[EMAIL PROTECTED] /www/jakarta.apache.org/commons/io]$ find . -type d -exec
chmod 775 {} \;
[EMAIL PROTECTED] /www/jakarta.apache.org/commons/io]$ find . -type f -exec
chmod 664 {} \;
[EMAIL PROTECTED] /www/jakarta.apache.org/commons/io]$ chgrp -R jakarta .
No effect. Apart from that, the problem also seems to impact the site, because
http://jakarta.apache.org/commons/io/
and
http://people.apache.org/~jochen/commons-io/site/
look drastically different.
> fix website permissions
> ---
>
> Key: IO-124
> URL: https://issues.apache.org/jira/browse/IO-124
> Project: Commons IO
> Issue Type: Bug
>Reporter: Godmar Back
>
> http://jakarta.apache.org/commons/io/api-release/index.html
> says:
> Forbidden
> You don't have permission to access /commons/io/api-release/index.html on
> this server.
> Apache/2.3.0-dev (Unix) Server at jakarta.apache.org Port 80
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VALIDATOR-231) Missing unit tests using maven
Missing unit tests using maven -- Key: VALIDATOR-231 URL: https://issues.apache.org/jira/browse/VALIDATOR-231 Project: Commons Validator Issue Type: Bug Affects Versions: 1.3.1 Release Reporter: Gail Badner The maven build uses the file pattern "**/*Test.java", so it misses org.apache.commons.validator.MultipleTests. This test is run when using ant. MultipleTests should probably be renamed to MultipleTest. When this is fixed, it would be nice if the junit ant task were used to run the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BEANUTILS-287) Missing unit tests using ant and unit test errors using maven
Missing unit tests using ant and unit test errors using maven -- Key: BEANUTILS-287 URL: https://issues.apache.org/jira/browse/BEANUTILS-287 Project: Commons BeanUtils Issue Type: Bug Affects Versions: 1.7.0 Reporter: Gail Badner When running unit tests with ant, 402 tests are executed and all are successful. The following test cases are are not executed with ant: ConstructorUtilsTestCase FileConverterTestCase URLConverterTestCase When running unit tests with maven, 413 tests are executed, but 2 fail: BeanificationTestCase.testMemoryTestMethodology LocaleBeanificationTestCase.testMemoryTestMethodology Both errors are due to java.lang.ClassNotFoundException: org.apache.commons.beanutils.BetaBean When this is fixed, it would be nice if the junit ant task were used to run the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
