Re: [collections][lang] Functors, pre-vote
it appears that [functor] will need to depend on [lang] for exception nesting. hopefully, lang will not need to depend on functor. if it does, then maybe it shows that the factoring has gone a bit wrong and we need to think about it again. No, I don't agree. Functors would be very useful within [lang]. /O -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][lang] Functors, pre-vote
Does it matter if [functor] and [lang] have circular dependencies? Not that they will. Ola: Yes, that does matter. The thing is: should [functor] contain the util classes with default implementations etc. If so, I am compelled to say that it should go into [lang]. There is no real requirement for [functor] to depend on [lang]. If it were just my choice, then I would favour larger packages, and leave functors in [lang]. However, there seems to be more of a consensus for smaller packages. Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14591] - Serialization problem with org.apache.commons.validator.ValidatorResult$ResultStatus
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14591. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14591 Serialization problem with org.apache.commons.validator.ValidatorResult$ResultStatus --- Additional Comments From [EMAIL PROTECTED] 2002-12-12 10:48 --- I have no objections. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DBCP tracking stale connections?
On Tue, 10 Dec 2002, Martin van Dijken wrote: BasicDataSource currently doesn't expose testWhileIdle, although if you look at how the other props are dealt with, it wouldn't be difficult to expose it (a small change to BasicDataSourceFactory and BasicDataSource is all that is required). I'd be happy to commit the patch if you test it first. Ok, in what form can I expect the patch? See http://jakarta.apache.org/site/source.html#Patches -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - commons-jelly
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2002-12-12/commons-jelly.html
Buildfile: build.xml
init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/jelly/lib
get-deps:
compile:
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/target/classes
[javac] Compiling 342 source files to
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/target/classes
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/HttpTagSupport.java:68:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: package httpclient
[javac] import org.apache.commons.httpclient.HttpMultiClient;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:64:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: package httpclient
[javac] import org.apache.commons.httpclient.HttpMultiClient;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:89:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] private HttpMultiClient _httpClient;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:118:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] public HttpMultiClient getHttpClient() {
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:127:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] public void setHttpClient(HttpMultiClient httpClient) {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/HttpTagSupport.java:234:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.HttpTagSupport
[javac] private HttpMultiClient getHttpClient() {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/HttpTagSupport.java:236:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.HttpTagSupport
[javac] HttpMultiClient client = null;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/HttpTagSupport.java:241:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.HttpTagSupport
[javac] client = new HttpMultiClient();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:105:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] _httpClient = new HttpMultiClient(getProxyHost(),
getProxyPort());
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:107:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] _httpClient = new HttpMultiClient();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/MethodSupportTag.java:185:
org.apache.commons.httpclient.HttpConnectionManager is abstract; cannot be
instantiated
[javac] connectionManager = new HttpConnectionManager();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/MethodSupportTag.java:232:
cannot resolve symbol
[javac] symbol : method getConnection (java.lang.String)
[javac] location: interface org.apache.commons.httpclient.HttpConnectionManager
[javac] return getConnectionManager().getConnection( getUrl() );
[javac]
[GUMP] Build Failure - commons-email
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2002-12-12/commons-email.html Buildfile: build-gump.xml jar: [mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/email/target/classes [javac] Compiling 7 source files to /home/rubys/jakarta/jakarta-commons-sandbox/email/target/classes [javac] /home/rubys/jakarta/jakarta-commons-sandbox/email/src/java/org/apache/commons/mail/HtmlEmail.java:66: cannot resolve symbol [javac] symbol : class GenerateUniqueId [javac] location: package util [javac] import org.apache.commons.util.GenerateUniqueId; [javac]^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/email/src/java/org/apache/commons/mail/HtmlEmail.java:208: cannot resolve symbol [javac] symbol : class GenerateUniqueId [javac] location: package util [javac] String cid = org.apache.commons.util.GenerateUniqueId.getIdentifier(); [javac] ^ [javac] 2 errors BUILD FAILED file:///home/rubys/jakarta/jakarta-commons-sandbox/email/build-gump.xml:22: Compile failed; see the compiler error output for details. Total time: 1 second -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][patch] ClassFilterIterator
Wouldn't it be more generic to expose your (private inner) ClassPredicate as a public Predicate, say InstanceOfPredicate? That way one could easily create ClassFilterIterator, as you have, but could also use the Predicate in the various CollectionUtils methods, etc. Also, I wonder if the ClassPredicate constructor should default to Object.class when the given Class is null. new ClassPredicate(null) or new ClassFilterIterator(null) seems like a rather confusing way to create a NotNullPredicate or a NotNullIterator. I wonder if simply throwing IllegalArgumentException or NullPointerException from the constructor would be cleaner? On Tue, 10 Dec 2002, Emmanuel Bourg wrote: Hi, here is a suggested addition to the collections component. This is a trivial FilterIterator which only returns objects of a given class. I attached the class with its associated test case. Emmanuel Bourg -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] switch/case
Given this and the other replies on this thread, I guess I'll just leave well enough alone for now. On Tue, 10 Dec 2002, bob mcwhirter wrote: I think most folks tend to use 'break' with their switch/case statements, and probably have been bitten in the ass a lot due to a missing break. I'd vote for defaultly not falling through, but if you wanted to, add an explicit fall-through/ tag that'd set a fall-through flag to true and execute the following case and reset it back to false. Else, maybe a global attr on the switch fall-through=true or similar? -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[DBCP] Building the DBCP jarfile
Hey guys, I wanted to try and change some stuff in dbcp. (for now just for test purposes) In order to do that I checked out the entire commons module and built the collections, pool and lang packages. I then saved dbcp\build.properties.sample to dbcp\build.properties and changed the locations of the jarfiles to the proper locations. However I still get a few compiler errors. Ones which I can't see through easily. [javac] F:\Downloads\Code\jakarta-commons\dbcp\dist\src\org\apache\commons\dbcp\jdbc2pool\Jdbc2PoolDataSource.java:85: cannot resolve symbol [javac] symbol : class FastHashMap [javac] location: package collections [javac] import org.apache.commons.collections.FastHashMap; [javac] ^ I checked the collections jarfile and the FastHashMap.class file is present there. Anybody got a clue what's going wrong? Martin van Dijken -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task JellyTask.java
mvdb2002/12/12 07:40:37
Modified:jelly/src/java/org/apache/commons/jelly/task JellyTask.java
Log:
Now using getLocation and getProject instead of directly referencing the protected
instance. This instance will be deprecated in the next ant release, that's why it
caught my eye.
Revision ChangesPath
1.11 +4 -4
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task/JellyTask.java
Index: JellyTask.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task/JellyTask.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JellyTask.java11 Dec 2002 12:41:00 - 1.10
+++ JellyTask.java12 Dec 2002 15:40:37 - 1.11
@@ -70,12 +70,12 @@
Script script = compileScript();
JellyContext context = getJellyContext();
-context.setVariable( project, project );
+context.setVariable( project, getProject() );
script.run( context, getXMLOutput() );
getXMLOutput().flush();
}
catch (Exception e) {
-throw new BuildException(e, location);
+throw new BuildException(e, getLocation() );
}
}
@@ -156,7 +156,7 @@
int idx = text.lastIndexOf('/');
text = text.substring(0, idx + 1);
JellyContext parentContext = new JellyContext(getRootContext(), new
URL(text));
-context = new AntJellyContext(project, parentContext);
+context = new AntJellyContext(getProject() , parentContext);
// register the Ant tag library
context.registerTagLibrary( jelly:ant, new AntTagLibrary() );
@@ -186,7 +186,7 @@
* @return the URL for the relative file name or absolute URL
*/
protected URL resolveURL(String name) throws MalformedURLException {
- File file = project.resolveFile(name);
+ File file = getProject().resolveFile(name);
if (file.exists()) {
return file.toURL();
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [DBCP] Building the DBCP jarfile
On Thu, 12 Dec 2002, Martin van Dijken wrote: I checked the collections jarfile and the FastHashMap.class file is present there. Anybody got a clue what's going wrong? No. That's odd. I'll guess that commons-collections isn't really in your compile-time classpath. That particular class is probably one of the few collections classes needed at compile-time, most the dependency on collections comes in at runtime via commons-pool. Gump was able to build it all from scratch recently http://cvs.apache.org/builds/gump/latest/, which also suggets a local environment issue. You can use the -verbose option (or is it -debug?) to Ant to have it spell out the javac classpath, which may help you to diagnose the problem. It looks like DBCP has a maven buildfile as well, if you want to go that route. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task JellyTask.java
From: [EMAIL PROTECTED]
mvdb2002/12/12 07:40:37
Modified:jelly/src/java/org/apache/commons/jelly/task JellyTask.java
Log:
Now using getLocation and getProject instead of directly referencing the
protected instance. This instance will be deprecated in the next ant
release, that's why it caught my eye.
Cool, thanks!
James
---
http://radio.weblogs.com/0112098/
Revision ChangesPath
1.11 +4 -4
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task/JellyTa
sk.java
Index: JellyTask.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/ta
sk/JellyTask.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JellyTask.java 11 Dec 2002 12:41:00 - 1.10
+++ JellyTask.java 12 Dec 2002 15:40:37 - 1.11
@@ -70,12 +70,12 @@
Script script = compileScript();
JellyContext context = getJellyContext();
-context.setVariable( project, project );
+context.setVariable( project, getProject() );
script.run( context, getXMLOutput() );
getXMLOutput().flush();
}
catch (Exception e) {
-throw new BuildException(e, location);
+throw new BuildException(e, getLocation() );
}
}
@@ -156,7 +156,7 @@
int idx = text.lastIndexOf('/');
text = text.substring(0, idx + 1);
JellyContext parentContext = new
JellyContext(getRootContext(), new URL(text));
-context = new AntJellyContext(project, parentContext);
+context = new AntJellyContext(getProject() ,
parentContext);
// register the Ant tag library
context.registerTagLibrary( jelly:ant, new
AntTagLibrary() );
@@ -186,7 +186,7 @@
* @return the URL for the relative file name or absolute URL
*/
protected URL resolveURL(String name) throws MalformedURLException
{
- File file = project.resolveFile(name);
+ File file = getProject().resolveFile(name);
if (file.exists()) {
return file.toURL();
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][lang] Functors, pre-vote
On Thu, 12 Dec 2002, Ola Berg wrote: The thing is: should [functor] contain the util classes with default implementations etc. If so, I am compelled to say that it should go into [lang]. In my opinion, yes [functor] should contain the most basic and common Functor implementations. You're only gonna want common Functor implementations if you're using Functor (common reuse) and if something changes in the basic Functor interfaces, then these common implmentations will likely also need to change (common change). This does not necessarily imply that both the Functor interfaces and the basic Functor implementations would need to go into the same JAR or cvs directory. It is possible to separate the interface classes from the implementations, even to have distinct dependencies for the two. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] switch/case
FWIW I also think the current behaviour is nice and concise. I wrote a fairly large Jelly switch statement, and it was nice to not have to write all those break tags. --- Rodney Waldhoff [EMAIL PROTECTED] wrote: Given this and the other replies on this thread, I guess I'll just leave well enough alone for now. On Tue, 10 Dec 2002, bob mcwhirter wrote: I think most folks tend to use 'break' with their switch/case statements, and probably have been bitten in the ass a lot due to a missing break. I'd vote for defaultly not falling through, but if you wanted to, add an explicit fall-through/ tag that'd set a fall-through flag to true and execute the following case and reset it back to false. Else, maybe a global attr on the switch fall-through=true or similar? -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/taskJellyTask.java
Your welcome ;)
My first commit for jelly afaik (although I already seem to be a
contributor)
I'm probably also going to jelliefy nyx :)
Mvgr,
Martin
On Thu, 2002-12-12 at 17:25, James Strachan wrote:
From: [EMAIL PROTECTED]
mvdb2002/12/12 07:40:37
Modified:jelly/src/java/org/apache/commons/jelly/task JellyTask.java
Log:
Now using getLocation and getProject instead of directly referencing the
protected instance. This instance will be deprecated in the next ant
release, that's why it caught my eye.
Cool, thanks!
James
---
http://radio.weblogs.com/0112098/
Revision ChangesPath
1.11 +4 -4
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task/JellyTa
sk.java
Index: JellyTask.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/ta
sk/JellyTask.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JellyTask.java 11 Dec 2002 12:41:00 - 1.10
+++ JellyTask.java 12 Dec 2002 15:40:37 - 1.11
@@ -70,12 +70,12 @@
Script script = compileScript();
JellyContext context = getJellyContext();
-context.setVariable( project, project );
+context.setVariable( project, getProject() );
script.run( context, getXMLOutput() );
getXMLOutput().flush();
}
catch (Exception e) {
-throw new BuildException(e, location);
+throw new BuildException(e, getLocation() );
}
}
@@ -156,7 +156,7 @@
int idx = text.lastIndexOf('/');
text = text.substring(0, idx + 1);
JellyContext parentContext = new
JellyContext(getRootContext(), new URL(text));
-context = new AntJellyContext(project, parentContext);
+context = new AntJellyContext(getProject() ,
parentContext);
// register the Ant tag library
context.registerTagLibrary( jelly:ant, new
AntTagLibrary() );
@@ -186,7 +186,7 @@
* @return the URL for the relative file name or absolute URL
*/
protected URL resolveURL(String name) throws MalformedURLException
{
- File file = project.resolveFile(name);
+ File file = getProject().resolveFile(name);
if (file.exists()) {
return file.toURL();
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [DBCP] Building the DBCP jarfile
I checked the collections jarfile and the FastHashMap.class file is present there. Anybody got a clue what's going wrong? No. That's odd. Sure was. Sorry, fucked something up. Everything works peachy now, except for 13 deprecated warnings:) It looks like DBCP has a maven buildfile as well, if you want to go that route. Heh, we use ant here internally and I know it pretty well. Maven I've never even heard of. Thanks for the help, I'll continue plowing through the code. Martin van Dijken -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[digester] i'd like to contribute - here's my new feature idea
Greetings, I have been using the great software developed by the jakarta team for some time now. I have found it very useful and I would like to contribute something. I'd like to start with the commons digester and I have a specific idea. Let me know if people would like to see this implemented. I think sending an email to this list is the right way to get started but I appologize in advance if its not. Here is a generic example of the problem I was trying to solve with digester and an explanation of how the current code did not completely meet my needs (although I just got started with digester so I may have overlooked something). The example is building a GUI client for a program where the components used to build the client are dynamically configured through an XML file. For simplicity I will not address the possibility of components containing other components. Here is the xml: client component classname=ComponentA/ component classname=ComponentB property name=SomeProperty value=some value/ /component /client Now I'd like the digester to create a Client object when it encounters the client tag. OK so far, I'll just use the standard ObjectCreateRule. The problem then becomes that I know I will be encountering the client/component pattern but I don't know what types of objects they are until runtime. I'd like to be able to specify the classname somehow instead of hardcoding it in the rule setup (or dynamically creating the rule). Also, each component may have zero or more properties to set but I don't know the name of the properties in advance. I have a specific solution in mind if the team is interested in hearing it (actually a few possible solutions). If its determined that we don't want to do it there will be no hard feelings. I definitely want to contribute something and all of the mailling lists just say go ahead and jump in. If this is a no go then I'd be happy to help in another capacity. TIA for your feedback on this and keep up the good work! - sean -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [DBCP] Building the DBCP jarfile
On Thu, 12 Dec 2002, Martin van Dijken wrote:
Everything works peachy now, except for 13 deprecated warnings:)
The DelegatingXXX classes in DBCP override also delegate the deprecated
methods of XXX, for example:
class DelegatingPreparedStatement extends PreparedStatement {
/** @deprecated */
public void setUnicodeStream(int parameterIndex,
InputStream in,
int length) throws SQLException {
checkOpen();
_stmt.setUnicodeStream(parameterIndex,in,length);
}
The overridden method is also deprecatd (thats one kind of warning) but we
still invoke the delegate's setUnicodeStream, which should be the kinds
of warnings you're seeing.
These warnings are annoying, but I think we've got the right approach.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDI based selection
Costin Manolache wrote: One comment: application isolation is not a voluntary thing. If we want to isolate the loggers you can't allow the application to specify what logger it wants in web.xml and hope they'll not use the same name. OK, the solution I presented solves the VOLUNTATRY separation of logging problem. It can be further refined to address the MANDATORY separation of logging problem Costin mentions. Costin suggested the use of string prefixes to enforce mandatory separation which is quite a nice idea. One possible approach is to have the string values stored in JNDI to be prefixed by the host name if requested to so by the host element within the server.xml file. Thus, the log4j repository selector can provide a host specific logger hierarchy for the hosts that request the service. Moreover, the host specific logger hierarchy cannot be spoofed by other hosts living in the same container. Looks like we have got a solution to the mandatory logging separation problem. Now, this solution requires that the Container directly provide support for log4j. Will Tomcat do that? Probably not, at least not until all the other containers do. How ironic would that be? -- Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [codec] Re: DoubleMetaphone
formatting looks close enough to me :) (whoever commits should probably go through the code and correct any small problems anyway.) since this is a (reasonably) significant donation of code for which versions with other copyright already exist, we should probably check with the foundation to make sure that all the legal t's are crossed and the i's dotted (so to speak) be committing anything, shouldn't we? - robert On Thursday, December 12, 2002, at 02:55 AM, Kyle R . Burton wrote: One last annoyance...I put the new classes in a sub-directory of the old ones: http://www.bgw.org/projects/java/phonetic/jakarta-commons-codec/ They already have changed package names for org.apache.commons.codec. Thanks again, Kyle R. Burton -- -- Wisdom and Compassion are inseparable. -- Christmas Humphreys [EMAIL PROTECTED] http://www.voicenet.com/~mortis -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDI based selection
Ceki Gülcü wrote: OK, the solution I presented solves the VOLUNTATRY separation of logging problem. It can be further refined to address the MANDATORY separation of logging problem Costin mentions. Costin suggested the use of string prefixes to enforce mandatory separation which is quite a nice idea. One possible approach is to have the string values stored in JNDI to be prefixed by the host name if requested to so by the host element within the server.xml file. Thus, the log4j repository selector can provide a host specific logger hierarchy for the hosts that request the service. Moreover, the host specific logger hierarchy cannot be spoofed by other hosts living in the same container. Looks like we have got a solution to the mandatory logging separation problem. The prefix should be set by container - and it should probably be the canonical name of the application. One remaining issue is if we allow apps to open loggers of a different app. getLog() needs to check if a prefix is already present - and if so do a permission check ( that would need JDK1.2 - but can be implemented in a LogFactoryImpl ). Now, this solution requires that the Container directly provide support for log4j. Will Tomcat do that? Probably not, at least not until all the other containers do. How ironic would that be? This has nothing to do with other containers. If we add the jndi stuff to commons-logging, tomcat will set the prefix env and it can also set other jndi properties that are needed. Both log4j and commons-logging could use this info. And of course, if LogFactory implements this lookup, then it'll separate the loggers regardless of implementation ( we may have a problem if both c-l and log4j are adding the prefix :-) We already include commons-logging-api and we're in process of migrating all the internal logging to c-l, and separating the loggers is an important issue. I think it would be a good idea to include log4j and log4j specific hooks in tomcat5 - but that's an issue for tomcat-dev. There are already some discussions about the content of the 5.0 release and increased modularity ( and a better hook system and support for JMX ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Adding jndi java:env support
sounds like a good plan. this sounds (to me) like a change big enough to call for a new (major?) version. (i'm not a cvs expert) but from what i can see there have been some small changes since the last release. maybe a quick bugfix 1.0.3 release would be a good idea before adding making this change. - robert On Thursday, December 12, 2002, at 03:29 AM, Costin Manolache wrote: Based on Ceki's email - I think it would be a good idea to add this mechanism in the default logging factory. My proposal is to insert a lookup for java:comp/env/CommonsLoggingFactory at the top of the discovery chain. If such a factory exists, it'll be used to create the logger. If not, we'll continue with the normal mechanism. The big downsize is that we'll add a compile dependency on JNDI ( the code can catch ClassNotFound - and run even if JNDI is not present ). This will allow containers using commons-logging to better enforce isolation between apps. In addition, I think we should add an optional domain name prefix. If such a prefix is set ( for example in java:comp/env/CommonsLoggingDomain) then it'll be added in front of every log name that is created. For example, if the container will set myHost:8080/myApp/ as a prefix, logs created in that app will be named: myHost:8080/myApp/org.apache. As a note, web.xml allows you to define and set a number of jndi entries. This could also be used to allow user-based tuning, but in general the container settings should be able to take preference . Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging/impl SimpleLog.java
rsitze 2002/12/12 11:23:34
Modified:logging/src/java/org/apache/commons/logging/impl
SimpleLog.java
Log:
1. Wrapped System.getProperties with doPrivileged.
2. Moved catch. If System properties cannot be loaded,
then don't abandon effort, but go on to loading
properties file.
Revision ChangesPath
1.6 +61 -54
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/SimpleLog.java
Index: SimpleLog.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/SimpleLog.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- SimpleLog.java19 Oct 2002 17:19:05 - 1.5
+++ SimpleLog.java12 Dec 2002 19:23:34 - 1.6
@@ -65,6 +65,8 @@
import java.io.InputStream;
import java.lang.reflect.Method;
import java.security.AccessControlException;
+import java.security.AccessController;
+import java.security.PrivilegedAction;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
@@ -160,71 +162,76 @@
try {
// add all system props that start with the specified prefix
-Enumeration enum = System.getProperties().propertyNames();
+Enumeration enum = (Enumeration)AccessController.doPrivileged(
+new PrivilegedAction() {
+public Object run() {
+return System.getProperties().propertyNames();
+}
+});
while(enum.hasMoreElements()) {
String name = (String)(enum.nextElement());
if(null != name name.startsWith(systemPrefix)) {
simpleLogProps.setProperty(name,System.getProperty(name));
}
}
+}
+catch (AccessControlException e) {
+// ignore access control exceptions when trying to check system
properties
+}
-// identify the class loader to attempt resource loading with
-ClassLoader classLoader = null;
+// identify the class loader to attempt resource loading with
+ClassLoader classLoader = null;
+try {
+Method method =
+Thread.class.getMethod(getContextClassLoader, null);
+classLoader = (ClassLoader)
+method.invoke(Thread.currentThread(), null);
+} catch (Exception e) {
+; // Ignored (security exception or JDK 1.1)
+}
+if (classLoader == null) {
+classLoader = SimpleLog.class.getClassLoader();
+}
+
+// add props from the resource simplelog.properties
+InputStream in =
+classLoader.getResourceAsStream(simplelog.properties);
+if(null != in) {
try {
-Method method =
-Thread.class.getMethod(getContextClassLoader, null);
-classLoader = (ClassLoader)
-method.invoke(Thread.currentThread(), null);
-} catch (Exception e) {
-; // Ignored (security exception or JDK 1.1)
-}
-if (classLoader == null) {
-classLoader = SimpleLog.class.getClassLoader();
+simpleLogProps.load(in);
+in.close();
+} catch(java.io.IOException e) {
+// ignored
}
+}
-// add props from the resource simplelog.properties
-InputStream in =
-classLoader.getResourceAsStream(simplelog.properties);
-if(null != in) {
-try {
-simpleLogProps.load(in);
-in.close();
-} catch(java.io.IOException e) {
-// ignored
-}
-}
+/* That's a strange way to set properties. If the property
+ is not set, we'll override the default
-/* That's a strange way to set properties. If the property
- is not set, we'll override the default
+showLogName = true.equalsIgnoreCase(
+simpleLogProps.getProperty(
+systemPrefix + showlogname,true));
+*/
-showLogName = true.equalsIgnoreCase(
-simpleLogProps.getProperty(
-systemPrefix + showlogname,true));
-*/
-
-String prop=simpleLogProps.getProperty( systemPrefix + showlogname);
-
-if( prop!= null )
-showLogName = true.equalsIgnoreCase(prop);
-
-prop=simpleLogProps.getProperty(
DO NOT REPLY [Bug 15331] New: - getResourceAsStream access permissions in J2EE environs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15331. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15331 getResourceAsStream access permissions in J2EE environs Summary: getResourceAsStream access permissions in J2EE environs Product: Commons Version: 1.0 Beta 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Logging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Security exceptions (file io) when using getResourceAsStream() in J2EE. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging/impl SimpleLog.java
rsitze 2002/12/12 12:29:16
Modified:logging/src/java/org/apache/commons/logging LogFactory.java
logging/src/java/org/apache/commons/logging/impl
SimpleLog.java
Log:
Fix getResourceAsStream security violations with doPriv.
Revision ChangesPath
1.16 +24 -10
jakarta-commons/logging/src/java/org/apache/commons/logging/LogFactory.java
Index: LogFactory.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/LogFactory.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- LogFactory.java 19 Oct 2002 17:38:06 - 1.15
+++ LogFactory.java 12 Dec 2002 20:29:16 - 1.16
@@ -278,9 +278,9 @@
Properties props=null;
try {
-InputStream stream = (contextClassLoader == null
- ? ClassLoader.getSystemResourceAsStream(
FACTORY_PROPERTIES )
- : contextClassLoader.getResourceAsStream(
FACTORY_PROPERTIES ));
+InputStream stream = getResourceAsStream(contextClassLoader,
+ FACTORY_PROPERTIES);
+
if (stream != null) {
props = new Properties();
props.load(stream);
@@ -310,9 +310,8 @@
if (factory == null) {
try {
-InputStream is = (contextClassLoader == null
- ? ClassLoader.getSystemResourceAsStream(
SERVICE_ID )
- : contextClassLoader.getResourceAsStream(
SERVICE_ID ));
+InputStream is = getResourceAsStream(contextClassLoader,
+ SERVICE_ID);
if( is != null ) {
// This code is needed by EBCDIC and other strange systems.
@@ -574,5 +573,20 @@
} catch (Exception e) {
throw new LogConfigurationException(e);
}
+}
+
+private static InputStream getResourceAsStream(final ClassLoader loader,
+ final String name)
+{
+return (InputStream)AccessController.doPrivileged(
+new PrivilegedAction() {
+public Object run() {
+if (loader != null) {
+return loader.getResourceAsStream(name);
+} else {
+return ClassLoader.getSystemResourceAsStream(name);
+}
+}
+});
}
}
1.8 +88 -23
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/SimpleLog.java
Index: SimpleLog.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/SimpleLog.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- SimpleLog.java12 Dec 2002 19:49:30 - 1.7
+++ SimpleLog.java12 Dec 2002 20:29:16 - 1.8
@@ -63,17 +63,17 @@
package org.apache.commons.logging.impl;
import java.io.InputStream;
+import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
-import java.security.AccessControlException;
import java.security.AccessController;
import java.security.PrivilegedAction;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
-import java.util.Enumeration;
import java.util.Properties;
import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogConfigurationException;
/**
* pSimple implementation of Log that sends all enabled log messages,
@@ -177,24 +177,8 @@
// load properties file, if found.
// override with system properties.
static {
-
-// identify the class loader to attempt resource loading with
-ClassLoader classLoader = null;
-try {
-Method method =
-Thread.class.getMethod(getContextClassLoader, null);
-classLoader = (ClassLoader)
-method.invoke(Thread.currentThread(), null);
-} catch (Exception e) {
-; // Ignored (security exception or JDK 1.1)
-}
-if (classLoader == null) {
-classLoader = SimpleLog.class.getClassLoader();
-}
-
// add props from the resource simplelog.properties
-InputStream in =
-classLoader.getResourceAsStream(simplelog.properties);
+InputStream in = getResourceAsStream(simplelog.properties);
if(null != in) {
try {
simpleLogProps.load(in);
@@
DO NOT REPLY [Bug 15331] - getResourceAsStream access permissions in J2EE environs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15331. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15331 getResourceAsStream access permissions in J2EE environs [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-12 20:31 --- Wrap with doPriv. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Adding jndi java:env support
I'll wait for the formal call to vote before I start voting, BUT I support the following: + release a 1.0.3 before any major code changes + JNDI - NO API changes - NO new runtime dependencies, and I'd like to be able to build, even if I cannot test it. ras *** Richard A. Sitze sounds like a good plan. this sounds (to me) like a change big enough to call for a new (major?) version. (i'm not a cvs expert) but from what i can see there have been some small changes since the last release. maybe a quick bugfix 1.0.3 release would be a good idea before adding making this change. - robert On Thursday, December 12, 2002, at 03:29 AM, Costin Manolache wrote: Based on Ceki's email - I think it would be a good idea to add this mechanism in the default logging factory. My proposal is to insert a lookup for java:comp/env/CommonsLoggingFactory at the top of the discovery chain. If such a factory exists, it'll be used to create the logger. If not, we'll continue with the normal mechanism. The big downsize is that we'll add a compile dependency on JNDI ( the code can catch ClassNotFound - and run even if JNDI is not present ). This will allow containers using commons-logging to better enforce isolation between apps. In addition, I think we should add an optional domain name prefix. If such a prefix is set ( for example in java:comp/env/CommonsLoggingDomain) then it'll be added in front of every log name that is created. For example, if the container will set myHost:8080/myApp/ as a prefix, logs created in that app will be named: myHost:8080/myApp/org.apache. As a note, web.xml allows you to define and set a number of jndi entries. This could also be used to allow user-based tuning, but in general the container settings should be able to take preference . Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] . org For additional commands, e-mail: mailto:[EMAIL PROTECTED] . org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [digester] i'd like to contribute - here's my new feature idea
On Thursday, December 12, 2002, at 07:59 PM, Sean Schofield wrote: snip All, Is this the correct newsgroup (just in case this wasn't a typo and that you weren't aware of the point - this is really a mailing list. some helpful people elsewhere mirror it into news.) for me to be raising these kinds of issues or should I have started in user first (so others could benefit from the answers) and then move it off to dev once we agree to work on it? we're usually pretty relaxed about user-list verses dev-list issues here. (we started out with just one mailing list - the user list was created to help users who didn't want to cope with the high volumes on dev.) - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [digester] i'd like to contribute - here's my new feature idea
So what if I wrote a patch to deal with this limitation (I described such a patch in an earlier reply but it didn't seem to make it to the list). The patch would be as follows: - Add a no-argument constructor to ObjectCreateRule - Modify the begin() method of ObjectCreateRule so that if there is no classname and no name for an attribute for the classname (as would be the case if you used the no-arg constructor), then use the first attribute (if available) as the classname. If that's not available then just continue on and let the existing exception handling take over. - Modify Digester by adding an 'addObjectCreate(String pattern)' method that would create the rule using the new no-arg constructor for ObjectCreateRule What do you guys think? I'd like to write the patch if it sounds agreeable to the group. Regards, Sean hi sean (if i've understood you right) then i think that this functionality exists already (or very nearly does). take a look at the ObjectCreateRule(String classname, String attributeName) . this will create an object who class name is given in an attribute of the xml. at the moment, you have to specify a class name (which is used as a default class to construct if the attribute isn't present) but it should be very easy to create a patch which eases this restriction. but don't let that put you off if you think you have a better solution. [... snip ...] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Adding jndi java:env support
Craig R. McClanahan wrote: On Wed, 11 Dec 2002, Costin Manolache wrote: The big downsize is that we'll add a compile dependency on JNDI ( the code can catch ClassNotFound - and run even if JNDI is not present ). Why couldn't we use reflection to avoid the compile-time dependency as well? After all, you like that pattern everywhere else :-). That's not necesarily true - I usually like a hook that plugs a class with the dependency, and conditional compilation. ( like in jdk11 compat package in tomcat ). Since JNDI is included in JDK1.3 and available for 1.1 - and it can be detected at runtime - I would rather use it directly and keep the code simpler. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Adding jndi java:env support
The big issue is the behavior. My proposal was: if java:env/comp/LoggingDomain is set ( as a String ), it'll be used as a prefix in all loggers ( that don't have a prefix ). The syntax for the logger names will become: DOMAIN:LOGGER And all loggers will have to be configured with this name ( if running in a container env with LoggingDomain support ). This is very important - and I would like to see more opinions. Maybe we should use the domain as a suffix instead of prefix ? Then you would have: org.apache.foo:host:8080/examples as the log name, but you can set org.apache.foo.* to debug and enable the loggers in all apps. The prefix is cleaner, but the suffix may be easier to configure. For implementation - I'm in no hurry ( I would like to have it before tomcat5 is released - but that's not very close ). And I can use reflecion or a hook, if needed. Costin Richard Sitze wrote: I'll wait for the formal call to vote before I start voting, BUT I support the following: + release a 1.0.3 before any major code changes + JNDI - NO API changes - NO new runtime dependencies, and I'd like to be able to build, even if I cannot test it. ras *** Richard A. Sitze sounds like a good plan. this sounds (to me) like a change big enough to call for a new (major?) version. (i'm not a cvs expert) but from what i can see there have been some small changes since the last release. maybe a quick bugfix 1.0.3 release would be a good idea before adding making this change. - robert On Thursday, December 12, 2002, at 03:29 AM, Costin Manolache wrote: Based on Ceki's email - I think it would be a good idea to add this mechanism in the default logging factory. My proposal is to insert a lookup for java:comp/env/CommonsLoggingFactory at the top of the discovery chain. If such a factory exists, it'll be used to create the logger. If not, we'll continue with the normal mechanism. The big downsize is that we'll add a compile dependency on JNDI ( the code can catch ClassNotFound - and run even if JNDI is not present ). This will allow containers using commons-logging to better enforce isolation between apps. In addition, I think we should add an optional domain name prefix. If such a prefix is set ( for example in java:comp/env/CommonsLoggingDomain) then it'll be added in front of every log name that is created. For example, if the container will set myHost:8080/myApp/ as a prefix, logs created in that app will be named: myHost:8080/myApp/org.apache. As a note, web.xml allows you to define and set a number of jndi entries. This could also be used to allow user-based tuning, but in general the container settings should be able to take preference . Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] . org For additional commands, e-mail: mailto:[EMAIL PROTECTED] . org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/discovery/src/testAlt2 - New directory
rsitze 2002/12/12 14:35:36 jakarta-commons/discovery/src/testAlt2 - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/discovery/src/test testResource
rsitze 2002/12/12 14:35:40
Modified:discovery/src/test/org/apache/commons/discovery/test
TestAll.java
discovery build.xml
discovery/sandbox/java/org/apache/commons/discovery/jdk
JDK11Hooks.java JDK12Hooks.java
discovery/src/java/org/apache/commons/discovery/jdk
JDK12Hooks.java JDK11Hooks.java
Added: discovery/src/testAlt2 testResource
discovery/src/testAlt1 testResource
discovery/src/test testResource
Log:
ClassLoader.getResources() is declared final in all current JDK specs.
ClassLoaders that change expected behavior by searching parents
last, instead of first, (as with some J2EE environments/settings) will then
return a different result for the FIRST value of getResources() versus
a call to getResource(). This can cause unexpected (and difficult to
debug) behavior if the discovery mechanism is used to find ONE resource.
Discovery abstracts the classloader behavior, so we use that abstraction
to force the first value returned by 'getResources' to be the value
returned by 'getResource'.
Revision ChangesPath
1.6 +56 -4
jakarta-commons/discovery/src/test/org/apache/commons/discovery/test/TestAll.java
Index: TestAll.java
===
RCS file:
/home/cvs/jakarta-commons/discovery/src/test/org/apache/commons/discovery/test/TestAll.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TestAll.java 12 Oct 2002 17:26:08 - 1.5
+++ TestAll.java 12 Dec 2002 22:35:39 - 1.6
@@ -63,22 +63,27 @@
package org.apache.commons.discovery.test;
+import java.net.URL;
import java.util.Properties;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
+import org.apache.commons.discovery.Resource;
import org.apache.commons.discovery.ResourceClass;
import org.apache.commons.discovery.ResourceClassIterator;
+import org.apache.commons.discovery.ResourceIterator;
+import org.apache.commons.discovery.jdk.JDKHooks;
+import org.apache.commons.discovery.resource.ClassLoaders;
+import org.apache.commons.discovery.resource.DiscoverResources;
+import org.apache.commons.discovery.resource.classes.DiscoverClasses;
import org.apache.commons.discovery.tools.DefaultClassHolder;
import org.apache.commons.discovery.tools.DiscoverClass;
import org.apache.commons.discovery.tools.DiscoverSingleton;
import org.apache.commons.discovery.tools.ManagedProperties;
import org.apache.commons.discovery.tools.PropertiesHolder;
import org.apache.commons.discovery.tools.SPInterface;
-import org.apache.commons.discovery.resource.ClassLoaders;
-import org.apache.commons.discovery.resource.classes.DiscoverClasses;
/**
@@ -88,6 +93,7 @@
public class TestAll extends TestCase {
private static final int logLevel =
org.apache.commons.discovery.log.SimpleLog.LOG_LEVEL_INFO;
+//org.apache.commons.discovery.log.SimpleLog.LOG_LEVEL_DEBUG;
public TestAll(String testName) {
@@ -243,7 +249,6 @@
}
public void testFindServiceFileDefault() {
-//
org.apache.commons.discovery.log.SimpleLog.setLevel(org.apache.commons.discovery.log.SimpleLog.LOG_LEVEL_DEBUG);
org.apache.commons.discovery.log.SimpleLog.setLevel(logLevel);
TestInterface2 ti = null;
@@ -262,6 +267,8 @@
}
public void testLowLevelFind() {
+org.apache.commons.discovery.log.SimpleLog.setLevel(logLevel);
+
ClassLoaders loaders = ClassLoaders.getAppLoaders(TestInterface2.class,
getClass(), false);
String name = org.apache.commons.discovery.test.TestImpl2_1;
@@ -280,11 +287,56 @@
fail(Could not load service: + resource );
}
}
-fail(failed to load resource: + name);
+fail(failed to load class resource: + name);
+}
+
+public void testFindResources() {
+org.apache.commons.discovery.log.SimpleLog.setLevel(logLevel);
+
+ClassLoaders loaders = new ClassLoaders();
+
+/**
+ * To many class loaders when searching for multiple
+ * resources means that we can find the same (same URL)
+ * resource for each loader...
+ * let's keep this to a minimum.
+ */
+ClassLoader cl = getClass().getClassLoader();
+if (cl != null)
+loaders.put(getClass().getClassLoader(), true);
+else
+loaders.put(JDKHooks.getJDKHooks().getSystemClassLoader(), true);
+
+
+String name = testResource;
+
+String partialPaths[] = { /test/, /testAlt1/, /testAlt2/ };
+
cvs commit: jakarta-commons/discovery/src/testAlt1 - New directory
rsitze 2002/12/12 14:35:36 jakarta-commons/discovery/src/testAlt1 - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [digester] i'd like to contribute - here's my new feature idea
hi sean by all means, submit a patch. but i'd prefer an attribute name to be passed in rather than using the first attribute. (i have a feeling that the order of attributes can be parser dependent.) when the attribute name isn't present, then just don't create anything. since ObjectCreateRule already has a constructor taking a string, then maybe i'd add a factory method that pass a null classname in the two string constructor. you'll need to add a test for null's into the body method. add the digester method as you said. also, please supply a unit test for this new feature. we use junit (http://www.junit.org). our existing test cases live in src/test. good luck! - robert On Thursday, December 12, 2002, at 09:27 PM, Sean Schofield wrote: So what if I wrote a patch to deal with this limitation (I described such a patch in an earlier reply but it didn't seem to make it to the list). The patch would be as follows: - Add a no-argument constructor to ObjectCreateRule - Modify the begin() method of ObjectCreateRule so that if there is no classname and no name for an attribute for the classname (as would be the case if you used the no-arg constructor), then use the first attribute (if available) as the classname. If that's not available then just continue on and let the existing exception handling take over. - Modify Digester by adding an 'addObjectCreate(String pattern)' method that would create the rule using the new no-arg constructor for ObjectCreateRule What do you guys think? I'd like to write the patch if it sounds agreeable to the group. Regards, Sean hi sean (if i've understood you right) then i think that this functionality exists already (or very nearly does). take a look at the ObjectCreateRule(String classname, String attributeName) . this will create an object who class name is given in an attribute of the xml. at the moment, you have to specify a class name (which is used as a default class to construct if the attribute isn't present) but it should be very easy to create a patch which eases this restriction. but don't let that put you off if you think you have a better solution. [... snip ...] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15339] New: - StackObjectPool needs to ensure available objects in pool are unique
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15339.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15339
StackObjectPool needs to ensure available objects in pool are unique
Summary: StackObjectPool needs to ensure available objects in
pool are unique
Product: Commons
Version: 1.0.1 Final
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Pool
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
java.util.Stack is not a Set and thus does not guarantee a unique set of objects
to be available in the pool. In the unfortunate circumstance that returnObject
is called twice on the same object, this will make two references to the same
resource available in the pool. My simple work-around is shown in the diff
below.
--- StackObjectPool.javaWed May 1 02:02:34 2002
+++
/home/edecosta/work/komodo/src/org/apache/commons/pool/impl/StackObjectPool.java
Thu Dec 12 17:50:17 2002
@@ -191,6 +191,8 @@
if(_pool.size() = _maxSleeping) {
shouldDestroy = true;
} else if(success) {
+if (_pool.contains(obj))
+throw new IllegalStateException(Pool already contains this
object!);
_pool.push(obj);
}
notifyAll(); // _numActive has changed
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [digester] i'd like to contribute - here's my new feature idea
by all means, submit a patch.
but i'd prefer an attribute name to be passed in rather than using
the first attribute. (i have a feeling that the order of attributes
can be parser dependent.) when the attribute name isn't present,
then just don't create anything. since ObjectCreateRule already has
a constructor taking a string, then maybe i'd add a factory method
that pass a null classname in the two string constructor. you'll
need to add a test for null's into the body method.
I don't want to squash Sean's enthusiasm, but I don't yet understand
the need for this modification.
Robert's concern about the attribute is correct, because nothing
anywhere in XML guarantees the order of attributes for an element.
They're just a soup of names and values. So then if you require the
attribute name to be passed in, how is this substantially different
than indicating a base class in the rule. Couldn't Sean achieve his
goals with the existing code and using java.lang.Object as the base
class?
While it's great to encourage participation, it's worth while to
exercise restraint with APIs.
Ultimately, if Sean really doesn't like the ObjectCreateRule, I would
suggest that in this case he should just write his own rule
implementation that behaves the way he needs it to.
Sean, can you help me understand why the existing API can't be used
to serve your needs?
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14982] - GenericObjectPool does not work with null factory.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14982. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14982 GenericObjectPool does not work with null factory. [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14981] - getNumActive() count is wrong when returnObject() is used to pre-populate StackObjectPool
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14981. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14981 getNumActive() count is wrong when returnObject() is used to pre-populate StackObjectPool --- Additional Comments From [EMAIL PROTECTED] 2002-12-12 23:56 --- Clearly a genuine bug. Should probably be considered along with http://issues.apache.org/bugzilla/show_bug.cgi?id=14983 (i.e., more direct and robust prepopulate or manual populate functionality.) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [digester] i'd like to contribute - here's my new feature idea
I don't want to squash Sean's enthusiasm, but I don't yet understand the need for this modification. Don't worry about my enthusiasm. I'm just throwing this out as an idea. I can take thoughtful criticism. If we nix this idea, I have some other ideas that I could contribute (eventually folks will like one of them and that will be where I start). Robert's concern about the attribute is correct, because nothing anywhere in XML guarantees the order of attributes for an element. They're just a soup of names and values. I was only thinking of grabbing the first attribute because I was making the assumption that in that case it would be the only one (so order wouldn't be an issue.) I wasn't entirely comfortable with that idea, but that's why I threw it out there. Couldn't Sean achieve his goals with the existing code and using java.lang.Object as the base class? I hadn't thought of that! I think that would work nicely and it would be fairly obvious to somone studying my code what I was trying to do there. While it's great to encourage participation, it's worth while to exercise restraint with APIs. Couldn't agree more. We don't want to bloat these great Commons APIs with custom features for one or two programmers. I thought my problem was general enough (and it is) its just that everything I need is already there (although hard to find without a lot of documentation or examples). Ultimately, if Sean really doesn't like the ObjectCreateRule, I would suggest that in this case he should just write his own rule implementation that behaves the way he needs it to. Now that I've pieced together how to do this with current code I agree with Joe that the patch isn't really necessary. Believe me, I did look over the existing code before charging in with a feature request. Perhaps I can make a contribution in the area of improved documentation (perhaps example programs) when the time comes for that? I've actually got a few other ideas I'm mulling over. I'll submit them to the group for consideration when they're a little more flushed out. Thanks for the help and feedback. Sean -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [collections][lang] Functors, pre-vote
I think we agree on just about everything, excepting dependancies between [functor] and [lang]. I'm not very familiar with the scope of [lang] so take my comments with a grain of salt. My point is that [functor] (defined as having no dependancies on any other apache project) represents a set of concepts that are completely orthogonal to the other packages. All other packages should be free to use [functor] w/out having to worry about circular dependencies. As long as [functor] is scoped with this minimalist view, then this is easily achievable. Implementations of [functor] interfaces that require [lang] should be placed in [lang]. Implementations depending on [beanutils] belong in [beanutils]. -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 12, 2002 11:55 AM To: Jakarta Commons Developers List Subject: RE: [collections][lang] Functors, pre-vote On Thu, 12 Dec 2002, Tom Drake wrote: Has anyone considered that all functor implementations do not belong in [functor]. I actually don't see any reasons yet why all functor implementations don't belong in functor [or the place where the interfaces/core impls are], apart from release issues, in which case the implementation can just be private in the other lib. Any implementations of functor which are only dependent on functor should be in functor. An implementation such as in [io] now definitely belongs in [io] as it is to do with FileFilters. If [functor] contains the functor interfaces, as well as selected dependency-free implementation and utility classes. Then, if [lang], [collections], or [foo] wants to use them they are free to, without worrying about dependency hell. If [lang] has a need to create a [lang]-specific Predicate or Transformer, then they should go right ahead and create it somewhere under [lang], introducing a dependancy on [functor]. Lang depending on functor should raise alarm bells. Let's take JDK as an example: java.lang is pretty core right? java.util is also pretty common. java.util obviously depends on java.lang. Does java.lang depend in anyway on java.util??? I wouldn't rule the chance out. So circular dependency. Now look at Lang. It's do do with java.lang things. Everyone uses java.lang things, so there's no package which could not have a desire to be dependent on Lang. Thus: Functor dependent on Lang is a concept which must be protected. Now, we're saying that Functor things are these really standard interfaces that any code which matches the code signature will probably want to consider having. If Lang happens to have such things, then bang. That's our circular dependency. So the hope is that something like Lang does not have a dependency on Functor. Collections doesn't care, it'll depend on both libraries. Same for IO and other things out there. [Equally, assuming it's okay for Commons Lang to use java.util.Vector etc, why can't Commons Lang depend on Commons Collection? Except that I've already declared that every library should protect the possibility of a Lang dependency] By way of example, I submitted a BeanPropertyTransformer class (as part of a large submission) a week or so ago. This class implements Transformer, but uses PropertyUtils to transform the Object into a 'named' bean property. Such an implementation class probably doesn't belong in [collections] or [functor], but perhaps belongs with [beanutils]. However, adding it to [beanutils] creates a dependancy on [functor]. This isn't a functor implementation in my view. Maybe I'm belabouring a point. It's a Bean implementation which fits the functor standard. The same way that BeanComparator is in BeanUtils and not in Collections. Your class should be in BeanUtils, and as Functor is a higher-priority package in dependency terms [i need to define the concept of priority here somehow] then BeanUtils should depend on Functor. So, I guess I'm saying that the charter for [functor] should stipulate that no external dependancies may be present. This being the case, everything that needs a functor interface, or one of it's basic implementation classes, it simply depends on [functor]. If it needs a functor implementation that exists in some other package (like [lang]) then it must depend on that other package. I claim that Functor should depend on Lang. In fact, Lang should not depend on anything else ;) Such a stipulation guarantees, to some extent, that [functor] will always be fairly compact, since it may not contain any dependencies on any other org.apache package. *nod* Except functor isn't unique in its specialness. Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Adding jndi java:env support
On Thu, 12 Dec 2002, Costin Manolache wrote: Date: Thu, 12 Dec 2002 13:29:51 -0800 From: Costin Manolache [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [logging] Adding jndi java:env support The big issue is the behavior. My proposal was: if java:env/comp/LoggingDomain is set ( as a String ), it'll be used as a prefix in all loggers ( that don't have a prefix ). The syntax for the logger names will become: DOMAIN:LOGGER And all loggers will have to be configured with this name ( if running in a container env with LoggingDomain support ). This is very important - and I would like to see more opinions. Maybe we should use the domain as a suffix instead of prefix ? Then you would have: org.apache.foo:host:8080/examples as the log name, but you can set org.apache.foo.* to debug and enable the loggers in all apps. The prefix is cleaner, but the suffix may be easier to configure. For implementation - I'm in no hurry ( I would like to have it before tomcat5 is released - but that's not very close ). And I can use reflecion or a hook, if needed. I'm neutral on prefix versus suffix (although prefix feels a little more in keeping with the hierarchical naming I tend to use for logging). But that raises an important consideration -- do the underlying logging implementations we support deal gracefully with a : syntax in a logger name? In particlar, could I configure a logger for DOMAIN: and have it apply to all loggers in that domain? I'm wondering if we might want to use a period (.) as the connector instead. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [latka] Plugin for Maven
This is pretty cool. I assume it uses the latest,
Jelly-driven version of Latka? The new code seems
pretty stable, but it could use more testing.
On a side note, the old Latka implementation
automatically checked to make sure all variables were
defined. We can't do that in quite the same way now
that our variables have been replaced by JEXL
expressions. Any suggestions on what to replace it
with? I suppose we could write a new tag that could
verify the existence of variables...
- Morgan
--- [EMAIL PROTECTED] wrote:
I've added the beginnings of a Latka plugin to
Maven.
See
http://jakarta.apache.org/turbine/maven/reference/plugins/latka/
for
the home page.
Currently all the plugin does is execute any scripts
found in
${maven.latka.src.dir} which defaults to
src/test/latka that have the file
suffix .latka.
I've had to patch Latka to get this going, and the
Latka snapshot has been
deployed to the ibiblio repository.
Any changes, fixes and enhancements are encouraged.
--
dIon Gillard, Multitask Consulting
Blog:
http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15345] New: - Validator not formsets by locale
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15345.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15345
Validator not formsets by locale
Summary: Validator not formsets by locale
Product: Commons
Version: Nightly Builds
Platform: All
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Validator
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
org.apache.commons.validator.ValidatorResources:get(String, String, String,
Object)
This method seems to be searching the hFormSet entries incorrectly for finding
a form with the given key, using a formset with the given locale.
The method bails out straight away if it does not find a formset with the
language + country + variant passed in, rather than trying
1) language + country + variant
2) language + country
3) language
4) default locale
The following diffs seem to fix it up, but I could be misunderstanding the
problem.
--- ValidatorResources.java Wed Dec 4 02:27:36 2002
+++ /home/gf06866/projects/webATLAS/src/java/org/apache/commons/validator/Valida
torResources.java Fri Dec 13 11:06:01 2002
@@ -244,63 +244,61 @@
* /ol
*/
public Form get(String language, String country, String variant, Object
formKey) {
- FormSet fs = null;
Form f = null;
- String key = null;
- Object o = null;
-
- key = ((language != null language.length() 0) ? language : ) +
-((country != null country.length() 0) ? _ + country : ) +
-((variant != null variant.length() 0) ? _ + variant : );
-
- Vector v = (Vector) hFormSets.get(key);
+ String localeKey = null;
- if (v == null) return f;
-
- Enumeration formsets = v.elements();
- while (formsets.hasMoreElements()) {
- o = formsets.nextElement();
- if (o != null) {
- fs = (FormSet)o;
- if ((fs != null) (fs.getForm(formKey) != null)) {
- return fs.getForm(formKey);
+ // Try language + country + variant
+ if (!GenericValidator.isBlankOrNull(language)
+ !GenericValidator.isBlankOrNull(country)
+ !GenericValidator.isBlankOrNull(variant)) {
+ localeKey = language + _ + country + _ + variant;
+ f = getForm(localeKey, formKey);
+ if (f != null) {
+ if (log.isDebugEnabled()) {
+ log.debug(Form with key + formKey + found
in formset with locale + localeKey);
}
+ return f;
}
}
- key = ((language != null language.length() 0) ? language : ) +
- ((country != null country.length() 0) ? _ + country : );
- formsets = v.elements();
- while (formsets.hasMoreElements()) {
- o = formsets.nextElement();
- if (o != null) {
- fs = (FormSet)o;
- if ((fs != null) (fs.getForm(formKey) != null)) {
- return fs.getForm(formKey);
+ // Try language + country
+ if (!GenericValidator.isBlankOrNull(language)
+ !GenericValidator.isBlankOrNull(country)) {
+ localeKey = language + _ + country;
+ f = getForm(localeKey, formKey);
+ if (f != null) {
+ if (log.isDebugEnabled()) {
+ log.debug(Form with key + formKey + found
in formset with locale + localeKey);
}
+ return f;
}
}
- key = ((language != null language.length() 0) ? language : );
- formsets = v.elements();
- while (formsets.hasMoreElements()) {
- o = formsets.nextElement();
- if (o != null) {
- fs = (FormSet)o;
- if ((fs != null) (fs.getForm(formKey) != null)) {
- return fs.getForm(formKey);
+
+ // Try language only
+ if (!GenericValidator.isBlankOrNull(language)) {
+ localeKey = language;
+ f = getForm(localeKey, formKey);
+ if (f != null) {
+ if (log.isDebugEnabled()) {
+ log.debug(Form with key + formKey + found
in formset with locale + localeKey);
}
+ return f;
}
}
- key = defaultLocale.toString();
- formsets = v.elements();
- while (formsets.hasMoreElements()) {
- o = formsets.nextElement();
- if (o != null) {
- fs = (FormSet)o;
- if ((fs != null) (fs.getForm(formKey) !=
DO NOT REPLY [Bug 15345] - Validator incorrectly searching formsets by locale
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15345. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15345 Validator incorrectly searching formsets by locale [EMAIL PROTECTED] changed: What|Removed |Added Summary|Validator not formsets by |Validator incorrectly |locale |searching formsets by locale --- Additional Comments From [EMAIL PROTECTED] 2002-12-13 03:53 --- Sorry to much caffeine not enough sleep, so I've changed to summary to something that actually makes sense :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15257] - Hierarchy support in ToStringBuilder.reflectionToString()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15257. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15257 Hierarchy support in ToStringBuilder.reflectionToString() --- Additional Comments From [EMAIL PROTECTED] 2002-12-13 04:22 --- Created an attachment (id=4154) Patch to version 1.9 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15257] - Hierarchy support in ToStringBuilder.reflectionToString()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15257. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15257 Hierarchy support in ToStringBuilder.reflectionToString() --- Additional Comments From [EMAIL PROTECTED] 2002-12-13 04:23 --- Created an attachment (id=4155) Patch to version 1.2 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14384] - ValidatorResources.get-method not working properly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14384. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14384 ValidatorResources.get-method not working properly [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-12-13 04:24 --- *** Bug 15345 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Adding jndi java:env support
Craig R. McClanahan wrote: I'm neutral on prefix versus suffix (although prefix feels a little more in keeping with the hierarchical naming I tend to use for logging). But that raises an important consideration -- do the underlying logging implementations we support deal gracefully with a : syntax in a logger name? In particlar, could I configure a logger for DOMAIN: and have it apply to all loggers in that domain? I'm wondering if we might want to use a period (.) as the connector instead. I don't know - that's why I ask :-) We should certainly use a syntax that is compatible with both jdk1.4 and log4j. We could encode the name - but it needs to be easy to type ( I hate %xx ). The only reason for suffix is easier configuration - but I'm not even sure it's easier :-) Can log4j or jdk14 support *.org.apache.commons.level=DEBUG ? The use case of setting the log level on a component in multiple applications seems more common. We can leave the log name unchanged and try to play some tricks with the logger config. Changing the log name seemed like the easiest solution. We can associate the application name with the hierarchy - but again I don't know how this would work from a config perspective. Ceki - any idea ? The use case I have in mind is a container ( like tomcat ), with several applications, a JMX-based config tool and some centralised config file ( eventually managed by the JMX tool or editor or some other UI ). The apps shouldn't have to do anything - they should just see the normal log patterns as a standalone app today. ( of course - this should also work for jdk14 or other loggers - even if log4j is the best :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] [latka] Plugin for Maven
Morgan Delagrange [EMAIL PROTECTED] wrote on 13/12/2002 03:44:26 AM: This is pretty cool. I assume it uses the latest, Jelly-driven version of Latka? The new code seems pretty stable, but it could use more testing. :) Yep, using a snapshot of Latka I built when I made the plugin. There were a couple of assumptions the old code made, but it is still pretty solid. I'll be giving it a good hammering in the next couple of weeks. We're going to be using it solidly on a dev project. On a side note, the old Latka implementation automatically checked to make sure all variables were defined. We can't do that in quite the same way now that our variables have been replaced by JEXL expressions. Any suggestions on what to replace it with? I suppose we could write a new tag that could verify the existence of variables... empty() is supposed to do it, but jexl has some problems with dotted variables. It'd be nice if jexl were fixed :) I think James Strachan wrote a test case to show the broken bits. James? -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator ValidatorResult.java
martinc 2002/12/12 23:54:10
Modified:validator/src/share/org/apache/commons/validator
ValidatorResult.java
Log:
Make ValidatorResult$ResultStatus serializable. The onus is therefore on
the Validator client to ensure that result classes are serializable.
Revision ChangesPath
1.4 +5 -5
jakarta-commons/validator/src/share/org/apache/commons/validator/ValidatorResult.java
Index: ValidatorResult.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/ValidatorResult.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ValidatorResult.java 3 Dec 2002 05:31:02 - 1.3
+++ ValidatorResult.java 13 Dec 2002 07:54:10 - 1.4
@@ -129,7 +129,7 @@
/**
* Contains the status of the validation.
*/
- protected class ResultStatus {
+ protected class ResultStatus implements Serializable {
private boolean valid = false;
private Object result = null;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
