Re: [GUMP] Build Failure - commons-betwixt
On 22 Mar 2003, James Strachan [EMAIL PROTECTED] wrote: BUILD FAILED file:///home/rubys/jakarta/jakarta-commons/betwixt/build.xml:87: There were test failures. Is there anything I could do to resolve this? Like creating testreports on my own Gump setup and sending them here/anywhere else? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build Failure - commons-jelly-tags-html
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-03-24/commons-jelly-tags-html.html Buildfile: build.xml init: [mkdir] Created dir: /home/rubys/jakarta/jelly-tags/html/target/lib get-deps: compile: [mkdir] Created dir: /home/rubys/jakarta/jelly-tags/html/target/classes [javac] Compiling 2 source files to /home/rubys/jakarta/jelly-tags/html/target/classes [copy] Copying 5 files to /home/rubys/jakarta/jelly-tags/html/target/test-classes compile-tests: [javac] Compiling 1 source file to /home/rubys/jakarta/jelly-tags/html/target/test-classes internal-test: [mkdir] Created dir: /home/rubys/jakarta/jelly-tags/html/target/test-reports [junit] Running org.apache.commons.jelly.html.TestJelly [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.328 sec [junit] Testsuite: org.apache.commons.jelly.html.TestJelly [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.328 sec [junit] Testcase: testSimpleParse took 0.194 sec [junit] Caused an ERROR [junit] file:/home/rubys/jakarta/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:9:46: html:parse null Nested exception: null [junit] org.apache.commons.jelly.JellyTagException: file:/home/rubys/jakarta/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:9:46: html:parse null Nested exception: null [junit] at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSupport.java:232) [junit] at org.apache.commons.jelly.tags.html.ParseTag.doTag(ParseTag.java:116) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:105) [junit] Caused by: org.dom4j.DocumentException: null Nested exception: null [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:358) [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:233) [junit] at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSupport.java:211) [junit] ... 13 more [junit] Root cause [junit] org.dom4j.DocumentException: null Nested exception: null [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:358) [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:233) [junit] at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSupport.java:211) [junit] at org.apache.commons.jelly.tags.html.ParseTag.doTag(ParseTag.java:116) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:105) [junit] Nested exception: [junit] java.lang.NullPointerException [junit] at org.apache.xerces.parsers.AbstractSAXParser.startNamespaceMapping(Unknown Source) [junit] at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) [junit] at org.cyberneko.html.HTMLTagBalancer.startElement(Unknown Source) [junit] at org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(Unknown Source) [junit] at org.cyberneko.html.HTMLScanner$ContentScanner.scan(Unknown Source) [junit] at org.cyberneko.html.HTMLScanner.scanDocument(Unknown Source) [junit] at org.cyberneko.html.HTMLConfiguration.parse(Unknown Source) [junit] at org.cyberneko.html.HTMLConfiguration.parse(Unknown Source) [junit] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) [junit] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:339) [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:233) [junit] at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSupport.java:211) [junit] at org.apache.commons.jelly.tags.html.ParseTag.doTag(ParseTag.java:116) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:105) [junit] Testcase: testSimpleParse BUILD FAILED file:///home/rubys/jakarta/jelly-tags/html/build.xml:95: Test org.apache.commons.jelly.html.TestJelly failed Total time: 6 seconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] scope for version 2
Henri == Henri Yandell [EMAIL PROTECTED] writes: Henri Been a while since the last one of these, so I expect a few Henri bits to be missing. Feel free to chime in on things I've Henri missed: Henri Next release will be Lang 2.0. Henri Lang 2.0 scope: Henri org.apache.commons.lang.functor.* HenriThere is obviously a clash with Collections here, which HenriLang seeks to Henri resolve. Also there is a clash with Rodney's [Functor] Henri package. From what I understand, despite the similar naming, Henri [Functor] goes a lot further into the concepts than .functor Henri does, with .functor being a simpler setup etc. I'm going on Henri hearsay though, not having looked at the code yet. Dear All, my opinion on lang.functor probably comes too late to have any impact on the course of the release of Lang. But still feel the urge to express my feeling that something goes into the wrong direction with lang.functor. In my opinion lang.functor should not enter 2.0 in the current state: The major issue which I have is the naming of the interfaces. While names like UnaryFunction or BinaryProcedure may sound a bit esoteric for the unaccustomed ear, these names do however expose the real nature of the interface or their implementations. - Executor is the interface for something which is executed not as the name suggests something that executes. If renamed to UnaryProcedure, I would be able to grasp the nature of this interface and its associated Utils class without refering to the javadoc. - While the notion of Factory is widely known and the nature of this interface is well exposed by the class name, one may wonder why a creational pattern like Factory is found in generic functor package. The name Factory suggests that this interface should only be used in Factory contexts. IMHO, Function (in the context its of Unary and Binary counterparts.) is more general and allows for the same purposes originally intended. The user programmer may then class WidgetFactory implements Function or class WidgetFactory implements UnaryFunction if the Widget creation should be parameterized with one argument. How would we proceed in the future if the names are not changed and we would like to introduce parameterized Factories? UnaryFactory? - Predicate is fine as a name. - Transformer does imply an argument. But does it imply as well that there is a result? Furthermore, the name somehow suggests that it is to be used to 'transform' objects, which is in my experience never the case: The argment object is usually left unchanged while a result is calculated as function of the argument object. Wouldn't UnaryFunction not be a more indicative name for this interface? I believe that the names where chosen with the intent to gradually remove the counterparts in Collections. However, currently there is no dependence of Collections on Lang.functor, so renaming the interfaces would not do any harm. Of course I aggree that the migration of Collections to lang.functor would be quite smooth. However, in the longterm Collections will have to live with the same naming problems as I have described above. I suggest to do the following renamings in for Lang 2.0: - Executor-- UnaryProcedure - Executor.execute(..)-- UnaryProcedure.run(..) - Factory -- Function - Factory.create() -- Function.apply() - Transformer -- UnaryFunction - Transformer.transform() -- UnaryFunction.apply(..) - rename all the Utils classes accordingly - possibly complement with missing interfaces: - Procedure - UnaryPredicate - possibly add BinaryPredicate, BinaryProcedure, BinaryFunction Then in the future the functor component (currently in Sandbox) may grow up as a place for more advanced functor stuff (also to complement collections) based on the interfaces provided in lang.functor. Of course, these proposals look like major changes right before a release. And performing major changes right before a release is very risky and should be avoided. However, while the changes seem major, they are only renaming refactorings which could be implemented quickly without changing any algorithms or functionality. If the lang.functor is not improved now before the Lang2.0 it may never be improved and collections will always rely on questionably named interfaces and probably Collections will never live up to its opportunities. Cheers, Arnd. PS: Please have a look at commons-sandbox-functor. Further, if you have some time at hand to get inspired about functors read http://c2.com/cgi/wiki?BlocksInJava . PPS: Please excuse if I have tripped over some jakarta rules and regulations. I have only been following jakarta commons for a several months and may not be well accustomed to jakarta release interaction protocols. PPP: I would of course volounteer to implement the suggested changes myself, I they were generally aggreed upon.
Re: Adding TERMINAL-TYPE option to TelnetClient
Hi, I added yet another functionality to TelnetClient, which is very handy to debug: You can spy what's going on in the TelnetClient session by registering to it an OutputStream. TelnetClient will copy all the session activity on the registered outputstream. - TelnetClient: added two new methods (registerSpyStream(), stopSpyStream()) - Telnet: Added new methods to manage the spy stream - TelneInputStream: calls a Telnet's method to copy the received chars on the output stream - TelnetClientExample3: It is a new example showing the use of registerSpyStream() an stopSpyStream(). It opens a telnet connection to a server, then listen to port . Just connect to port with an external telnet, then type SPY on the TelnetClientExample3 terminal and you will see all the TelnetClient traffic copied on the telnet connection to port . UNSPY will stop spying the connection. I enclose another patch which includes all the preceeding + the new spy stream functionality (sources + JUnit tests). Again, sorry for sending so many versions of this patch, I'm just adding the functions I need one at a time when I have got some free time to do that. If you ave some comments or need some explanation, please contact me. Bruno commons-net-openoption-patch4.ZIP Description: Zip compressed data commons-net-openoption-patch4-test.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Silly Build question
On Saturday 22 March 2003 4:45 pm, Gary Gregory wrote: Hello, I the various commons project, we have project/src/conf/manifest.mf. What does conf stand for? Why not use ant's manifest? Thanks, Gary conf stands for 'configuration'. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] Functor debate [was re: [lang] scope for version 2]
from:Arnd Kohrs [EMAIL PROTECTED] I suggest to do the following renamings in for Lang 2.0: - Executor-- UnaryProcedure - Executor.execute(..)-- UnaryProcedure.run(..) - Factory -- Function - Factory.create() -- Function.apply() - Transformer -- UnaryFunction - Transformer.transform() -- UnaryFunction.apply(..) - rename all the Utils classes accordingly - possibly complement with missing interfaces: - Procedure - UnaryPredicate - possibly add BinaryPredicate, BinaryProcedure, BinaryFunction You are correct in your evaluation that the names chosen do not allow for other later functions, such as Binary or no-argument forms. They are instead chosen to be simple. My rule of thumb is [lang] simple, other project ([functor] in this case) higher level/more complex. You're never going to convince me that 'BinaryPredicate' is simple in concept even if it is the formal computer science solution. Then in the future the functor component (currently in Sandbox) may grow up as a place for more advanced functor stuff (also to complement collections) based on the interfaces provided in lang.functor. Of course, these proposals look like major changes right before a release. And performing major changes right before a release is very risky and should be avoided. However, while the changes seem major, they are only renaming refactorings which could be implemented quickly without changing any algorithms or functionality. If the lang.functor is not improved now before the Lang2.0 it may never be improved and collections will always rely on questionably named interfaces and probably Collections will never live up to its opportunities. [functor] appears to be adding this kind of functionality, and as such should also add the corresponding collections utilities. PS: Please have a look at commons-sandbox-functor. Further, if you have some time at hand to get inspired about functors read http://c2.com/cgi/wiki?BlocksInJava . Yes I've taken a look before, and the concepts seem sound. However, it requires you to invest more effort in learning the framework and its intracies - it is more complex. As such I know that I would not choose to use the complex functors. Whereas I find those in [lang] simpler, if less flexible. Everythings a tradeoff ;-) Stephen PPS: Please excuse if I have tripped over some jakarta rules and regulations. I have only been following jakarta commons for a several months and may not be well accustomed to jakarta release interaction protocols. PPP: I would of course volounteer to implement the suggested changes myself, I they were generally aggreed upon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17677] - Pooled connection architecture vulnerable to double use
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=17677. 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=17677 Pooled connection architecture vulnerable to double use --- Additional Comments From [EMAIL PROTECTED] 2003-03-24 15:27 --- Because the same wrapper class instance is handed out multiple times, it makes it possible for inadvertent sharing to occur. This is exactly the way a pool should work so I don't believe this is an architectural flaw. Client code using the pool is responsible for not sharing objects retrieved from the pool and returning them to the pool ASAP. Creating new wrapper objects on each request would lead to performance degredation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17911] - Problem with getConnection() and Informix
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=17911. 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=17911 Problem with getConnection() and Informix --- Additional Comments From [EMAIL PROTECTED] 2003-03-24 15:34 --- Is it DBCP's responsibility to correct the behavior of all broken drivers? Going down this path seems dangerous to me. If someone is using a driver that is apparently broken, they can simply not call the broken method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17894] - Unable to configure commons-logging SimpleLog for a webapp
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=17894. 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=17894 Unable to configure commons-logging SimpleLog for a webapp [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|struts- |commons- |[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|REOPENED|NEW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Functor debate
Stephen == scolebourne [EMAIL PROTECTED] writes: from: Arnd Kohrs [EMAIL PROTECTED] I suggest to do the following renamings in for Lang 2.0: - Executor -- UnaryProcedure - Executor.execute(..) -- UnaryProcedure.run(..) - Factory -- Function - Factory.create() -- Function.apply() - Transformer -- UnaryFunction - Transformer.transform() -- UnaryFunction.apply(..) - rename all the Utils classes accordingly - possibly complement with missing interfaces: - Procedure - UnaryPredicate - possibly add BinaryPredicate, BinaryProcedure, BinaryFunction Stephen You are correct in your evaluation that the names chosen do Stephen not allow for other later functions, such as Binary or Stephen no-argument forms. They are instead chosen to be simple. I don't agree that the current names chosen in lang.functor are simple, and provided arguments for it in my first post (which you dit not respond to). I do not make this up: When I read about a lang.functor package to be included in 2.0, I checked it out, and was as confused when I browsed over the class names, as people would be about the other functors when first encountering. I needed to look-up for example Factory and then mapped it in my mind to no-arg function. Factory by itself does not sufficiently explain its nature. To put it differently, I suggest a renaming refactoring because the current naming is not indicative enough nor coherent. Stephen My rule of thumb is [lang] simple, other project ([functor] Stephen in this case) higher level/more complex. You're never going Stephen to convince me that 'BinaryPredicate' is simple in concept Stephen even if it is the formal computer science solution. IMHO it does not serve a rational evaluation of my proposal to choose 'BinaryPredicate' as an example - which I did not suggest to be added to lang.functor (only as a possibility). The addiction of binary functors to lang is not important now. - and which does not have a lang.functor counterpart in the current lang.functor package: Obviously it is not as simple as a NON-existing concept. PS: Please have a look at commons-sandbox-functor. Further, if you have some time at hand to get inspired about functors read http://c2.com/cgi/wiki?BlocksInJava . Stephen Yes I've taken a look before, and the concepts seem Stephen sound. However, it requires you to invest more effort in Stephen learning the framework and its intracies - it is more Stephen complex. As such I know that I would not choose to use the Stephen complex functors. Whereas I find those in [lang] simpler, Stephen if less flexible. Everythings a tradeoff ;-) I find it easier to adopt a conceptual framwork which has a coherent naming convention. There is not coherence in Executor, Transformer, Factory and Predicate although the coexitence of in the same package would suggest so. All which needs to be understood if these functors where renamed following the naming which are customary in functor libraries and which I referred to, is founded on two orthogonal concepts: 1. Functor Types - Function: Functor which has a result - Predicate: Functor which has a boolean result - Procedure: Functor which has no result 2. Number of Arguments - *Unary*Functor: one argument functor - *Binary*Functor: two argument functor - Functor: (Null-ary) no argument functor Once these two axises are understood there is no need to provide extra explanation for instances of Functor interfaces in this space. This is not the case for, Factory, Transformer and Executor. Example BinaryPredicate: is a Functor with a boolean result which has two arguments. It is not necessary to understand possible extensions of this concept, e.g. internal iterators or functor composition. At least not more as if one wanted to use Transformer. For Lang2.0 I would only go as far as limiting functors to Null-ary and Unary functor interfaces, as there currently seems to be no need for Binary functors. I see the lang.functor as a light-weight place for standardizing interfaces of functors. Then other components may provide internal iterators or related interfaces based on lang.functors such as Collections. And functor utility components may provide the compositions and default implementations using the same functor interfaces which are defined in Lang. If lang cannot provide a functor package which may be used as a standard or if this is out of the lang scope, the incoherent current approach to functors may discourage the evolving and adoption of a functor component with a broader scope. Therefore, without modifications, I would opt for dropping functor from lang, and leave the rudimentary functor stuff in collections, as the lang package does not aim for a broader scope. Please take no offense in my argumentation. I know that a lot of people have strong feelings about functors and I
DO NOT REPLY [Bug 17677] - Pooled connection architecture vulnerable to double use
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=17677. 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=17677 Pooled connection architecture vulnerable to double use --- Additional Comments From [EMAIL PROTECTED] 2003-03-24 16:26 --- This is not true, if the pool has a function which automatically puts a connection back into the pool. This is, what this pool call an abandoned connection if an application do not pass back the connection back within an specified time. Since not all programmers are perferct and not all programms are perfect, this is a nice feature to prevent an db connection leak. But, if the connection is passed back to the pool, the object passed to the application should never ever be valid. What, if the wrongly programmed thread which connection is passed back to the pool, issues a commit while another thread is in the middle of an transaction? To the performance problem: If one uses abandoned connections, he/she has to live with this performance gain. If i had a web application in mind, such get/release is not very often and performance might not be a problem. Inconsistent Data is for sure a great problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DBCP] Please let us start to improve the connection pool
Hello ! There are some bug or RFE in DBCP which sould be fixed. Some people (including me) have already posted in this list, but it seems there is no DBCP developer anymore or he/she is very busy. Could one of the DBCP people please comment on how and when development in DBCP could advance. I would like to help in improving it (i have already posted a patch for http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17677), but if there is no one in this list who is willing to discuss, it is hard to do it right. Hope to hear from one of you ... Ciao, Mario
Re: [DBCP] Please let us start to improve the connection pool
There are several circumstances where two different pieces of code can be
inadvertently sharing the same connection.
Connection pool user is responsable for this. User can store connection in
ThreadLocal or
implement something like this:
class MySafeConnection implements InvokationHandler{
Connection connection;
WeakReference owner;
MySafeConnection(Connection connection){
this.connection = connection;
owner = new WeakReference( Thread.currentThread() );
}
Object invoke(Object obj, Method method, Object args[] ) throw Throwable{
if( owner.get() == Thread.currentThread() ){
method.invoke( connection, args );
}else{
throw new IllegalStateExeption();
}
}
static Connection decorate(Connection connection){
return
(Connection)Proxy.newProxyInstance(connection.getClass().getClassLoader(),
new Class[] {Connection.class}, new
MySafeConnection(connection));
}
}
It is trivial, isn't it ?
I do not think stuff like this must be included in to pool distribution, but
it can be in documentation.
- Original Message -
From: Mario Ivankovits [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Monday, March 24, 2003 6:34 PM
Subject: [DBCP] Please let us start to improve the connection pool
Hello !
There are some bug or RFE in DBCP which sould be fixed.
Some people (including me) have already posted in this list, but it seems
there is no DBCP developer anymore or he/she is very busy.
Could one of the DBCP people please comment on how and when development in
DBCP could advance.
I would like to help in improving it (i have already posted a patch for
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17677), but if there is no
one in this list who is willing to discuss, it is hard to do it right.
Hope to hear from one of you ...
Ciao,
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18297] New: - StringArrayConvertor does not convert int[] to String[]
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=18297.
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=18297
StringArrayConvertor does not convert int[] to String[]
Summary: StringArrayConvertor does not convert int[] to String[]
Product: Commons
Version: Nightly Builds
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Bean Utilities
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I would only report this bug with knowledge that an inconsistency exists in the
BeanUtils converters. When using the converter IntegerArrayConverter, the
converter attempts to parse a String[] to an int[], however it makes no attempt
to do the far easier conversion from int[] to String[] in StringArrayConverter.
This happens to be a very important conversion since multiple select boxes in
html forms must be set at a string array even though the model often transfers
data to the form as an int[]. The two conversions are equally important and it
is, in my mind, a missing feature that the conversion exists in one case and not
in the other. The follow is the necessary patch to add this convertor.
--- StringArrayConverter.java.orig 2003-03-21 04:43:17.0 -0500
+++ StringArrayConverter.java 2003-03-21 04:43:20.0 -0500
@@ -113,6 +113,10 @@
// --- Static Variables
+ /**
+* p Model object for int arrays./p
+*/
+ private static int ints[] = new int[0];
/**
* pModel object for type comparisons./p
@@ -149,6 +153,19 @@
return (value);
}
+ // Deal with the input value as an int array
+ if (ints.getClass() == value.getClass())
+ {
+ int[] values = (int[]) value;
+ String[] results = new String[values.length];
+ for (int i = 0; i values.length; i++)
+ {
+ results[i] = new
StringBuffer().append(values[i]).toString();
+ }
+
+ return (results);
+ }
+
// Parse the input value as a String into elements
// and convert to the appropriate type
try {
As you can see, the added functionality is copied almost directly from
IntegerArrayConverter.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] Please let us start to improve the connection pool
Craig, IMHO, any application that depends on the connection pool for recovering abandoned connections (whether or not it recycles them) is broken. Far better is to focus your energy on avoiding all the cases where you grab a connection from the pool but fail to return it for some reason. One simple way to do this is to encapsulate your JDBC-using code in a try/catch/finally block, something like this: I haven't used DBCP for anthing yet, though we're proposing to use it for James in place of our homespun pool. However from what I understand of this discussion there are two things going on here; Thing one, I agree with you, code failing to return connections to the pool should lead to failure, and the sooner this can be done the better for identifying such broken code. Thing two, DBCP will apparently make a value judgement about an assigned connection, and is capable of recycling it with no notification to the code which has checked it out. In my opinion thing two is wrong or incomplete as it creates a situation where potential failure is built in, difficult to reproduce and difficult identify the cause of. In the case of JDBC connection pooling may be reasonable to want to keep a connection even when it is idle, because connections can aquire state which is expensive to reproduce. Is it not, then, unresonable to allow the pool to silently and forcably recycle apparently idle but valuable connections? My solution would either be to make it possible to turn off the forcable recycling of connections, or to make the pool capable of notifying code that its connection has been recycled. Is that reasonable? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist - New directory
ggregory2003/03/24 14:44:17 jakarta-commons/lang/dist - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs - New directory
ggregory2003/03/24 14:44:17 jakarta-commons/lang/dist/docs - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/util - New directory
ggregory2003/03/24 14:44:18 jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/util - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api/org/apache - New directory
ggregory2003/03/24 14:44:17 jakarta-commons/lang/dist/docs/api/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/enum - New directory
ggregory2003/03/24 14:44:17 jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/enum - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/builder - New directory
ggregory2003/03/24 14:44:17 jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/builder - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api/org/apache/commons - New directory
ggregory2003/03/24 14:44:17 jakarta-commons/lang/dist/docs/api/org/apache/commons - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api - New directory
ggregory2003/03/24 14:44:17 jakarta-commons/lang/dist/docs/api - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api/org - New directory
ggregory2003/03/24 14:44:17 jakarta-commons/lang/dist/docs/api/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api/org/apache/commons/lang - New directory
ggregory2003/03/24 14:44:17 jakarta-commons/lang/dist/docs/api/org/apache/commons/lang - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/functor - New directory
ggregory2003/03/24 14:44:18 jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/functor - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/reflect - New directory
ggregory2003/03/24 14:44:18 jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/reflect - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/time - New directory
ggregory2003/03/24 14:44:18 jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/time - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/exception - New directory
ggregory2003/03/24 14:44:18 jakarta-commons/lang/dist/docs/api/org/apache/commons/lang/exception - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/lang/dist - New directory
Arg, I appologize for these emails and new directories. I wanted to add the dist directory created by doing to local build to my local copy of .cvsignore and I think I picked the wrong menu item in Eclipse. Gary -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 2:44 PM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-commons/lang/dist - New directory ggregory2003/03/24 14:44:17 jakarta-commons/lang/dist - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Lang] Source code line length
Hello All, This discussion applies to all of Commons but source code formatting is a religious issue for some so I am happy to only address this at the [Lang] level. For our regular development (at work), we all use Eclipse's formatter with the same parameters (line length is the only factory default we changed, 145). Sun's conventions document advises to Avoid lines longer than 80 characters, since they're not handled well by many terminals and tools. Apache's guidelines points to Sun's while asking contributors to Please respect the style of the orginal[sic] file. Make sure that your additions fit in with that style. Lang Line length seems to be varied. I am happy to follow whatever convention but I would like to plug in a number (80 or ) if there is some unspoken convention here. Thanks, Gary
DO NOT REPLY [Bug 18302] New: - Maven build omits DTDs
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=18302. 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=18302 Maven build omits DTDs Summary: Maven build omits DTDs Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Digester AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I did a maven dist on the CVS head and then tried to use the JAR with the Digester XML rules. My code could not load the rules from XML because the digester-rules.dtd was not in the jar. I'm no Maven expert, but I hacked at the project.xml file and did another build and the DTDs were there. See project.xml patch attached. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18302] - Maven build omits DTDs
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=18302. 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=18302 Maven build omits DTDs --- Additional Comments From [EMAIL PROTECTED] 2003-03-25 00:03 --- Created an attachment (id=5487) maven project.xml patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
scolebourne2003/03/24 16:15:58
Modified:lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Deprecate clean() now trimToEmpty() is added
Revision ChangesPath
1.39 +2 -1
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- StringUtils.java 24 Mar 2003 00:47:02 - 1.38
+++ StringUtils.java 25 Mar 2003 00:15:58 - 1.39
@@ -112,6 +112,7 @@
* @see java.lang.String#trim()
* @param str the String to check
* @return the trimmed text (never codenull/code)
+ * @deprecated use the clearer named trimToEmpty(String)
*/
public static String clean(String str) {
return (str == null ? : str.trim());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] TrimToNull et al
Deprecation of clean() done. Stephen - Original Message - From: Gary Gregory [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Monday, March 24, 2003 6:22 PM Subject: RE: [lang] TrimToNull et al +1 deprecate clean() Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Sunday, March 23, 2003 4:55 PM To: Jakarta Commons Developers List Subject: [lang] TrimToNull et al I have added trimToNull() and trimToEmpty() to StringUtils based on previous discussions. trimToEmpty() actually does the same as clean(), but is IMHO a clearer name. Do we want to leave both in, or deprecate clean()? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Functor debate
From: Arnd Kohrs [EMAIL PROTECTED] Stephen == scolebourne [EMAIL PROTECTED] writes: (My short responses are due to time pressures...) Arnd: I don't agree that the current names chosen in lang.functor are simple, and provided arguments for it in my first post (which you dit not respond to). I do not make this up: When I read about a lang.functor package to be included in 2.0, I checked it out, and was as confused when I browsed over the class names, as people would be about the other functors when first encountering. I needed to look-up for example Factory and then mapped it in my mind to no-arg function. Factory by itself does not sufficiently explain its nature. To put it differently, I suggest a renaming refactoring because the current naming is not indicative enough nor coherent. snip I find it easier to adopt a conceptual framwork which has a coherent naming convention. There is not coherence in Executor, Transformer, Factory and Predicate although the coexitence of in the same package would suggest so. The coherence is that they are basic callback interfaces. The name functor has been used, however this package should never attempt to be a full implementation of functor concepts or to include the work of [functor]. Its about standardising some very common callback interfaces, and providing implementations of those that can be shared. Are they named correctly? Well perhaps Factory could be called Creator, as this would be in line with the create() method. But otherwise I'm happy. All which needs to be understood if these functors where renamed following the naming which are customary in functor libraries and which I referred to, is founded on two orthogonal concepts: 1. Functor Types - Function: Functor which has a result - Predicate: Functor which has a boolean result - Procedure: Functor which has no result 2. Number of Arguments - *Unary*Functor: one argument functor - *Binary*Functor: two argument functor - Functor: (Null-ary) no argument functor I don't dispute that this is the 'correct' or 'right' design for a full functor implementation. However this is very much bigger in concept, and in 'religion', than [lang] could support or would wish to. [lang]s functors do not have this goal - they aim to be simple commonly used callback interfaces. What I am arguing is that you may be reading too much into the word 'functor' in the [lang] context. What you are arguing for is [functor], which is fine if thats what you want to use. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Lang] Source code line length
checkstyle.properties specifies 120, which is a reasonable length. Stephen - Original Message - From: Gary Gregory [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Monday, March 24, 2003 11:24 PM Subject: [Lang] Source code line length Hello All, This discussion applies to all of Commons but source code formatting is a religious issue for some so I am happy to only address this at the [Lang] level. For our regular development (at work), we all use Eclipse's formatter with the same parameters (line length is the only factory default we changed, 145). Sun's conventions document advises to Avoid lines longer than 80 characters, since they're not handled well by many terminals and tools. Apache's guidelines points to Sun's while asking contributors to Please respect the style of the orginal[sic] file. Make sure that your additions fit in with that style. Lang Line length seems to be varied. I am happy to follow whatever convention but I would like to plug in a number (80 or ) if there is some unspoken convention here. Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Please let us start to improve the connection pool
Craig R. McClanahan wrote: On Mon, 24 Mar 2003, Danny Angus wrote: Date: Mon, 24 Mar 2003 22:28:29 - From: Danny Angus [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: RE: [DBCP] Please let us start to improve the connection pool Craig, IMHO, any application that depends on the connection pool for recovering abandoned connections (whether or not it recycles them) is broken. Far better is to focus your energy on avoiding all the cases where you grab a connection from the pool but fail to return it for some reason. One simple way to do this is to encapsulate your JDBC-using code in a try/catch/finally block, something like this: I haven't used DBCP for anthing yet, though we're proposing to use it for James in place of our homespun pool. However from what I understand of this discussion there are two things going on here; Thing one, I agree with you, code failing to return connections to the pool should lead to failure, and the sooner this can be done the better for identifying such broken code. Thing two, DBCP will apparently make a value judgement about an assigned connection, and is capable of recycling it with no notification to the code which has checked it out. will -- can be configured to In my opinion thing two is wrong or incomplete as it creates a situation where potential failure is built in, difficult to reproduce and difficult identify the cause of. There is a lot of flexibility in how you configure DBCP -- most of it inherited from the commons-pool capabilities that lie underneath. In all cases, the use of these features is configurable. * Test On Borrow -- The pool can perform some tests on an object instance that the pool is about to return to the application that asked for it. * Test On Return -- The pool can perform the same sorts of tests, but this time when the application returns the instance to the pool. * Test While Idle -- The pool can perform checks on connections that are in the pool (not currently allocated to an application) to make sure that it is still valid. DBCP (in particular, the BasicDataSource class found there) implements flags to enable each of these behaviors individually, along with a validation query that is used to perform the test. In addition, there are tuning parameters to control things like how often the test when idle checks are performed, and how many connections are tested each time. In the case of JDBC connection pooling may be reasonable to want to keep a connection even when it is idle, because connections can aquire state which is expensive to reproduce. Is it not, then, unresonable to allow the pool to silently and forcably recycle apparently idle but valuable connections? Keeping physical JDBC connections open between uses by the app, and allowing those connections to be shared, is the whole point of DBCP :-). But I think we might be using the term recycle differently. By recycle, do you mean if a connection has been setting in the pool for a long time and is not allocated to an application, so we can close it now? If so, that behavior is already configurable -- just set the maxIdle property to zero and no idle connection will ever get harvested. There's no application to notify in this case, because the instance being harvested wasn't allocated to an application at the time. Or, by recycle, do you mean if a connection has been allocated to an application but not returned for a long time, the pool is allowed to grab it back again -- but you want to notify the application first. The grab it back behavior is already configurable (and not enabled by default) -- and it's this functionality that I object to having at all. If there was no grab it back we wouldn't have to worry about notifying anyone that it was about to happen :-). My solution would either be to make it possible to turn off the forcable recycling of connections, or to make the pool capable of notifying code that its connection has been recycled. You can already turn off the forcible recycling -- in fact, you explicitly have to turn it *on* (i.e., for BasicDataSource, you have to explicitly set the removeAbandoned property and related values to enable it). But, I contend that no one should ever do that :-). Is that reasonable? If we're talking about the second use of recycled above, IMHO, I think adding support for recovering abandoned connections at all was a mistake. Doing anything to make it work better (knowing all the while that it cannot be made perfect) simply perpetuates the mistake. I'd much rather see this whole area of functionality deprecated, rather than continuing to mislead people into believing that its OK to depend on something that cannot ever work reliably 100% of the time. But that's just my opinion. I think Craig is correct. If code is not closing connections (and thereby not returning them to the pool), it is not the responsibility of the
cvs commit: jakarta-commons/jxpath/xdocs users-guide.xml
dmitri 2003/03/24 18:41:35 Modified:jxpath project.xml jxpath/src/java/org/apache/commons/jxpath/ri EvalContext.java JXPathContextReferenceImpl.java jxpath/src/java/org/apache/commons/jxpath/ri/axes InitialContext.java PredicateContext.java RootContext.java SimplePathInterpreter.java UnionContext.java jxpath/src/java/org/apache/commons/jxpath/ri/compiler ExpressionPath.java jxpath/src/java/org/apache/commons/jxpath/ri/model NodePointer.java VariablePointer.java jxpath/src/java/org/apache/commons/jxpath/ri/model/beans CollectionPointer.java PropertyIterator.java jxpath/src/java/org/apache/commons/jxpath/util BasicTypeConverter.java jxpath/src/test/org/apache/commons/jxpath/ri/compiler ExtensionFunctionTest.java TestFunctions.java jxpath/src/test/org/apache/commons/jxpath/ri/model BeanModelTestCase.java jxpath/src/test/org/apache/commons/jxpath/util BasicTypeConverterTest.java jxpath/xdocs users-guide.xml Added: jxpath/src/java/org/apache/commons/jxpath BasicNodeSet.java jxpath/src/java/org/apache/commons/jxpath/ri/axes NodeSetContext.java jxpath/src/java/org/apache/commons/jxpath/ri/model/beans CollectionAttributeNodeIterator.java CollectionChildNodeIterator.java CollectionNodeIterator.java jxpath/src/test/org/apache/commons/jxpath/ri StressTest.java Log: Fixed collection as return value of extension function Reduced the amount of cloning Revision ChangesPath 1.13 +10 -10jakarta-commons/jxpath/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/jxpath/project.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- project.xml 11 Mar 2003 00:59:10 - 1.12 +++ project.xml 25 Mar 2003 02:41:33 - 1.13 @@ -93,18 +93,18 @@ reports reportmaven-junit-report-plugin/report -!-- + reportmaven-jdepend-plugin/report reportmaven-checkstyle-plugin/report -reportmaven-changelog-plugin/report -reportmaven-developer-activity-plugin/report -reportmaven-file-activity-plugin/report -reportmaven-javadoc-plugin/report +!--reportmaven-changelog-plugin/report-- +!--reportmaven-developer-activity-plugin/report-- +!--reportmaven-file-activity-plugin/report-- +!--reportmaven-javadoc-plugin/report-- reportmaven-jxr-plugin/report -reportmaven-license-plugin/report -reportmaven-linkcheck-plugin/report -reportmaven-tasklist-plugin/report -reportmaven-clover-plugin/report --- +!--reportmaven-license-plugin/report-- +!--reportmaven-linkcheck-plugin/report-- +!--reportmaven-tasklist-plugin/report-- +!--reportmaven-clover-plugin/report-- + /reports /project 1.1 jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/BasicNodeSet.java Index: BasicNodeSet.java === /* * $Header: /home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/BasicNodeSet.java,v 1.1 2003/03/25 02:41:33 dmitri Exp $ * $Revision: 1.1 $ * $Date: 2003/03/25 02:41:33 $ * * * The Apache Software License, Version 1.1 * * * Copyright (c) 1999-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4.
Re: [jelly] Scope revisited
Is there any interest in this? I have a base scope, servlet request
scope and a System scope written, but I don't know to go much further if
there is no interest, and the questions below have some impact as well.
Any thoughts? anybody? :-)
~Robert
Robert McIntosh wrote:
Here is a first crack at the interface. I'm assuming that there will
be parent/child scopes here, which the last few methods deal with. I
also thought about having a few other 'collection' type methods, but
don't know what everyone else would think, such as contains( object ),
values(), isEmpty(), keySet(), etc.
Back to the JellyContext, what about finding variables in nested
scopes? For example, say we have one JellyContext (no parent), and it
has the following scopes:
- default scope
- customScope1
- HttpApplication which contains as a child a HttpSession scope
A client does a findVariable() call on the context. We can assume that
the context would search the default, customScope1 and the
HttpApplication scope, but what about the session scope?. If the leaf,
or last scope in a parent/child graph, is bound and not the top
parent, this is no problem, since the child parent can do a
getParent().findVariable() type of call. This doesn't mention if we
have nested Contexts as well.
I can think of three options:
1. we don't have nested scopes and the search is easy. Each context
has its own list of scopes and it can ask its parent.
2. we allow walking down the scope graph as well as up, via a
getChildScope() or something like that. Maybe have that as a protected
method on a BaseScope or something, and the context or the scope
itself can check for that.
3. ???
~Robert
Robert McIntosh wrote:
I don't have a use case for events either, but I thought I would
throw it out there for discussion. I agree that the Scope interface
be very simple and the context should have a default scope, which can
be overridden by the user.
~Robert
bob mcwhirter wrote:
2. Have/keep the scope listeners and events?
I personally see Scope as a way to keep me from having to keep writing
subclasses of JellyContext when I want the context to be backed by my
own data structure.
Talking with Strachan I think we're pondering
context.setDefaultScope( myScope );
In that vein, making Scope very simple be best for my particular
use-case.
public interface Scope
{
void setVariable(String name, Object value);
Object getVariable(String name);
}
If the JellyContext wants to check for ListenableScope and fire events,
that's cool, but it'd also be overblown for all of my use-cases.
-bob
-
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]
/*
* $Header: $
* $Revision: $
* $Date: $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2002 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT
Re: Data Transformer Proposal
The XML Data transformer will be a buffer between the application code and the actual transformer implementation. The actual implementation might be Castor, JAXB or Digester etc. The implementation will be selected based on users setting be it System Property, Services Discovery etc. Very similar to Commons-Logging. I have done some coding since I think this is very useful. And By the way, I checked Morphos and there wasnt any code available in the CVS. Thanks, Srikanth PS : There arent EDI - Java open source transformers yet. However there is a sort of freeware called OBOE (Open Business Objects for EDI) from americancoders.com I like this idea. Would this be a front end to things like Castor and Digester, or would they move to this component? Also, do you already have a codebase you have in mind for this? -- Ryan Hoegg ISIS Networks a href=http://mail.srikanth.org/jump/http://www.isisnetworks.net;http://www.isisnetworks.net/a P.S. Out of curiosity, are you familiar with any open source EDI transformation code? [EMAIL PROTECTED] wrote: - Commons Data Transformer - Sandbox Component proposal - Data Transformation is essential part of day to day computing, whether it is xml-to-xml transformation, xml-to-java transformation, edi-to-java transformation etc. Lets take a simple example of xml-to-java transformation (or vice versa) There are several implementations : Castor, JAXB to name a few. Usage of these introduces dependencies on the implementation. This immediately draws similarity with commons-logging. Commons-Logging acts as a Adapter between the user code and the implementation, freeing the user code from Log4J and J2SE Logging imports. (Thus allowing plug and play logging at the code level.) A similar approach for Data transformations in general (xml-to-java objects in particular) is highly desirable. Programmers like to access in memory Java object representations of external data. Hence I propose a Commons Data Transformer, freeing the user from implementation specific imports. I envision Commons Data transformer will perform x-to-java (direct transform) and java-to-x (inverse transform) transformations. PS : It is interesting to note that certain kinds of Configuration are really a subset of data transformation. Thanks, Srikanth --- End of forwarded message --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - commons-betwixt
On Mon, 24 Mar 2003, robert burrell donkin [EMAIL PROTECTED] wrote: i'm pretty sure that i've tracked down the reason why the build was failing and fixed it. I can confirm that betwixt has been built successfully last night on my box. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Data Transformer Proposal
Morphos has recently been aborted, the sources deleted. However, the code can still be downloaded from CVS (if you check out by date before 2002-02-28). You can probably expect a new effort being started in the Krysalis Metamorphosis project soon. Links: http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/morphos/ http://metamorphosis.krysalis.org/cgi-bin/mmorphosiswiki.pl On 25.03.2003 05:00:41 srikanth wrote: And By the way, I checked Morphos and there wasnt any code available in the CVS. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Any examples on webmail login
Hi I am new here and new to httpclient 2.0. I am trying write a http client which will login to a webmail using username and password. After executing the postmethod executemethod I got a response page with mail login page and a error message please upgrade your browser to one of the following IE or netscape. Is there anything I left out. I am using httpclient 2.0 alpha 3 here is my code. PostMethod post = new PostMethod(url); post.setRequestBody(formInput); //forminput post.setRequestContentLength(EntityEnclosingMethod.CONTENT_LENGTH_AUTO); post.setRequestHeader(Content-type, text/xml; ISO-8859-1); HttpClient httpclient = new HttpClient(); HostConfiguration hostConfig = new HostConfiguration(); hostConfig.setHost(connection.getHost(),connection.getPort(),connection.getProtocol()); httpclient.executeMethod(hostConfig,post); Thanks in advance Vijay. _ Call US for just Rs. 5. http://www.msn.co.in/webtelephony/ Get a phone card - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any examples on webmail login
Sounds like your webmail app is checking the User-Agent header and refusing you access. You might want to fake your User-Agent header to look like an appropriate browser. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net vijay kumar wrote: Hi I am new here and new to httpclient 2.0. I am trying write a http client which will login to a webmail using username and password. After executing the postmethod executemethod I got a response page with mail login page and a error message please upgrade your browser to one of the following IE or netscape. Is there anything I left out. I am using httpclient 2.0 alpha 3 here is my code. PostMethod post = new PostMethod(url); post.setRequestBody(formInput); //forminput post.setRequestContentLength(EntityEnclosingMethod.CONTENT_LENGTH_AUTO); post.setRequestHeader(Content-type, text/xml; ISO-8859-1); HttpClient httpclient = new HttpClient(); HostConfiguration hostConfig = new HostConfiguration(); hostConfig.setHost(connection.getHost(),connection.getPort(),connection.getProtocol()); httpclient.executeMethod(hostConfig,post); Thanks in advance Vijay. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10817] - Provide more Example Code
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=10817. 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=10817 Provide more Example Code --- Additional Comments From [EMAIL PROTECTED] 2003-03-24 18:23 --- Requested sample has been added http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/src/examples/FormLoginDemo.java Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] HttpParser.readRawLine
Patch committed
Oleg
On Fri, 2003-03-21 at 15:02, Kalnichevski, Oleg wrote:
The patch fixes RFC 822 non-compliant line termination problem reported by Carl A.
Dunham
Cheers
Oleg
Index: java/org/apache/commons/httpclient/HttpMethodBase.java
===
RCS file:
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.123
diff -u -r1.123 HttpMethodBase.java
--- java/org/apache/commons/httpclient/HttpMethodBase.java13 Mar 2003 17:51:28
- 1.123
+++ java/org/apache/commons/httpclient/HttpMethodBase.java21 Mar 2003 13:52:16
-
@@ -1980,7 +1980,7 @@
+ \HTTP/\);
}
if (Wire.enabled()) {
-Wire.input(statusString);
+Wire.input(statusString + \r\n);
}
//create the status line from the status string
statusLine = new StatusLine(statusString);
Index: java/org/apache/commons/httpclient/HttpParser.java
===
RCS file:
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpParser.java,v
retrieving revision 1.3
diff -u -r1.3 HttpParser.java
--- java/org/apache/commons/httpclient/HttpParser.java28 Feb 2003 12:48:58
- 1.3
+++ java/org/apache/commons/httpclient/HttpParser.java21 Mar 2003 13:52:15
-
@@ -28,10 +28,10 @@
/**
* Return byte array from an (unchunked) input stream.
- * Stop reading when tt\r\n/tt terminator encountered
+ * Stop reading when tt\n/tt terminator encountered
* If the stream ends before the line terminator is found,
- * the last part of the string will still be returned.
- * '\r' and '\n' are allowed to appear individually in the stream.
+ * the last part of the string will still be returned.
+ * If no input data available, codenull/code is returned
*
* @param inputStream the stream to read from
*
@@ -39,21 +39,14 @@
* @return a byte array from the stream
*/
public static byte[] readRawLine(InputStream inputStream) throws IOException {
-LOG.trace(enter HttpConnection.readRawLine());
+LOG.trace(enter HttpParser.readRawLine());
ByteArrayOutputStream buf = new ByteArrayOutputStream();
int ch;
while ((ch = inputStream.read()) = 0) {
buf.write(ch);
-if (ch == '\r') {
-ch = inputStream.read();
-if (ch 0) {
-break;
-}
-buf.write(ch);
-if (ch == '\n') {
-break;
-}
+if (ch == '\n') {
+break;
}
}
if (buf.size() == 0) {
@@ -63,10 +56,10 @@
}
/**
- * Read up to tt\r\n/tt from an (unchunked) input stream.
+ * Read up to tt\n/tt from an (unchunked) input stream.
* If the stream ends before the line terminator is found,
* the last part of the string will still be returned.
- * '\r' and '\n' are allowed to appear individually in the stream.
+ * If no input data available, codenull/code is returned
*
* @param inputStream the stream to read from
*
@@ -75,17 +68,24 @@
*/
public static String readLine(InputStream inputStream) throws IOException {
-LOG.trace(enter HttpConnection.readLine());
+LOG.trace(enter HttpParser.readLine());
byte[] rawdata = readRawLine(inputStream);
if (rawdata == null) {
return null;
}
int len = rawdata.length;
-if (( len = 2) (rawdata[len - 2] == '\r') (rawdata[len - 1] ==
'\n')) {
-return HttpConstants.getString(rawdata, 0, rawdata.length - 2);
-} else {
-return HttpConstants.getString(rawdata);
+int offset = 0;
+if (len 0) {
+if (rawdata[len - 1] == '\n') {
+offset++;
+if (len 1) {
+if (rawdata[len - 2] == '\r') {
+offset++;
+}
+}
+}
}
+return HttpConstants.getString(rawdata, 0, len - offset);
}
/**
__
-
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]
