DO NOT REPLY [Bug 33228] - [beanutils] Can't access mapped property in some case
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33228 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Can't access mapped property|[beanutils] Can't access |in some case|mapped property in some case -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Extending Validate
I've been looking into adding some methods to Validate; I'd appreciate
any feedback that anyone can provide about the utility of adding any/all
of the following methods to the Validate class.
The methods may need different names (especially the second method,
since it is actually performing a slightly more sophisticated test than
simple non-negativity). Also, the messages could be made more
descriptive. Still, I'm just looking for feedback on the basic
concepts. Would these methods be valuable?
// There would be overloads of this for byte, short, and long.
// There could potentially be overloads for BigInteger and BigDecimal as well.
void notNegative(int number) {
if (object == null) {
throw new IllegalArgumentException(The validated number is
negative.);
}
}
// There would be an overload of this for double.
void notNegative(float number) {
if (0.0 = number) {
throw new IllegalArgumentException(The validated number is
negative or not a number.);
}
}
// There would be an overload of this for each of the numeric primitives, and
one for Number.
// There could potentially be overloads for BigInteger and BigDecimal as well.
void inRange(int number, Range range) {
if (0.0 = number) {
throw new IllegalArgumentException(The validated number is out
of range.);
}
}
--
Mark Fairchild [EMAIL PROTECTED]
Learn Lisp today! Uncle Turing wants you!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Extending Validate
Sorry, I don't know where my head is at tonight. Here it is again, with the
correct method bodies.
I've been looking into adding some methods to Validate; I'd appreciate
any feedback that anyone can provide about the utility of adding any/all
of the following methods to the Validate class.
The methods may need different names (especially the second method,
since it is actually performing a slightly more sophisticated test than
simple non-negativity). Also, the messages could be made more
descriptive. Still, I'm just looking for feedback on the basic
concepts. Would these methods be valuable?
// There would be overloads of this for byte, short, and long.
// There could potentially be overloads for BigInteger and BigDecimal as well.
void notNegative(int number) {
if (!(0 = number)) {
throw new IllegalArgumentException(The validated number is
negative.);
}
}
// There would be an overload of this for double.
void notNegative(float number) {
if (!(0.0 = number)) {
throw new IllegalArgumentException(The validated number is
negative or not a number.);
}
}
// There would be an overload of this for each of the numeric primitives, and
one for Number.
// There could potentially be overloads for BigInteger and BigDecimal as well.
void inRange(int number, Range range) {
if (!range.containsInteger(number)) {
throw new IllegalArgumentException(The validated number is out
of range.);
}
}
--
Mark Fairchild [EMAIL PROTECTED]
Learn Lisp today! Uncle Turing wants you!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33228] - [beanutils] Can't access mapped property in some case
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33228 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 12:16 --- Created an attachment (id=14090) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14090action=view) Sample program to study the issue Property.getProperty(bean, property) works well where 'bean' is an instance of package scoped class which implements public interface and 'property' indicates a method which has no argument. When you execute test.T, IllegalAccessException doesn't occur. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33228] - [beanutils] Can't access mapped property in some case
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33228 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 12:18 --- (In reply to comment #2) If you check the BeanUtils API (http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.6.1/docs/api/): the required characteristics of JavaBeans that are important for most development scenarios are listed here: * The class must be public, and provide a public constructor that accepts no arguments. This allows tools and applications to dynamically create new instances of your bean, without necessarily knowing what Java class name will be used ahead I saw the BeanUtils API document you refered, but I couldn't find description that objects which BeanUtils processes must satisfyJavaBeans specification. I'm sorry. In addition, PropertyUtils.getProperty() works well for an object of package scoped class which implements public interface which has a getter method with *no argument*. If it is true that thislimitation is spec of BeanUtils as you said, I can't understand why the case of methodwhich has one or more arguments is not ok though the case of method which has no argument is ok. I attached another sample program to compare behavior of PropertyUtils.getProperty(). This works well for method 'test2' which has no argument, but it doesn't work well for method 'test' which has one argument. (Please see test/T.java) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Email] To release or not to release
This suspiciously familiar. Most likely causes: 1) There is already a mail server running on the test port (was 25, but there was talk of changing it to 2500) 2) You do not have the dumbster.jar Regards, -Corey On Thu, 20 Jan 2005 10:05:40 +0100, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ok, thanks... build was done. before I now roll the release one question, I got this *test failure* does anyone know more about that? Thanks! Matthias test:test: [junit] Running org.apache.commons.mail.DefaultAuthenticatorTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,21 sec [junit] Running org.apache.commons.mail.EmailAttachmentTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 11,206 sec [junit] Running org.apache.commons.mail.EmailTest [junit] Tests run: 36, Failures: 0, Errors: 0, Time elapsed: 4,797 sec [junit] Running org.apache.commons.mail.HtmlEmailTest java.net.BindException: Address already in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(Unknown Source) at java.net.ServerSocket.bind(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at com.dumbster.smtp.SimpleSmtpServer.run(Unknown Source) at java.lang.Thread.run(Unknown Source) java.net.BindException: Address already in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(Unknown Source) at java.net.ServerSocket.bind(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at com.dumbster.smtp.SimpleSmtpServer.run(Unknown Source) at java.lang.Thread.run(Unknown Source) [junit] Tests run: 6, Failures: 1, Errors: 1, Time elapsed: 5,909 sec [junit] [ERROR] TEST org.apache.commons.mail.HtmlEmailTest FAILED [junit] Running org.apache.commons.mail.MultiPartEmailTest org.apache.commons.mail.EmailException: javax.mail.NoSuchProviderException: smtp at org.apache.commons.mail.Email.send(Email.java:824) at org.apache.commons.mail.MultiPartEmail.send(MultiPartEmail.java:212) at org.apache.commons.mail.MultiPartEmailTest.testSend(MultiPartEmailTest.j ava:173) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTe stRunner.java:325) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnit Task.java:848) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask .java:556) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask .java:532) at org.apache.tools.ant.Task.perform(Task.java:341) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:616 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at
Re: [all][VOTE] svn migration
Paul Libbrecht wrote: You're underestimating the eclipse deployment. Am I? I don't think so. I am not talking about general use of subversion, I am talking about use of svn to manage jakarta-commons projects. The only problematic use case I've found with subeclipse is adding a project to a repository. (Of course, there may be others I haven't hit yet). That is clearly not something the ordinary jakarta-commons committer like myself is going to be doing everyday. When I do something more than committing changes or updating (such as preparing a release), I don't use eclipse at all, even for CVS, but follow the command line scripts on the jakarta-commons website. All friends I know who use Windows have no other ways of using cvs than Eclipse... (they know they can do differently but...). But the migration is clearly going to tighten the wish for maturity of Subclipse paul Le 24 janv. 05, à 00:35, Steve Cohen a écrit : However, I recognize that that's a relatively minor use case for jakarta-commons. I presume that most projects would be added to svn at the command line, and this is a one-time operation anyway. Other use cases within Eclipse seemed to work all right. So I will go along with the infrastructure guys, noting that many of the negative votes are not based on actual experience as extensive as even my limited experience. The ride may be a little bumpy, but isn't that par for the course? - 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 33228] - [beanutils] Can't access mapped property in some case
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33228 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 14:57 --- Created an attachment (id=14095) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14095action=view) Patch solving bug #33228 It seems that BeanUtils is bypassing its specifications (which is a good thing in this case). You can find it here: http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.6.1/docs/api/org/apache/commons/beanutils/package-summary.html#overview.background The good news is that the behaviour you want can be acheived with a couple of minor changes which in turn would bring consistency: * getAccessibleMethodFromInterfaceNest is checking for accesibility beginning with interfaces of the superClass and not the class itself. * MappedPropertyDescriptor is not checking for its interfaces' accesibility, it discards the method if it is not directly accessible. So both of these can be acheived by changing a couple of lines of code. The thing is that IMHO MappedPropertyDescriptor should have an init method to perform the common things that are done in its constructors. This would make it much easier to mantain. For the time being, the patch is attached with a slightly modified test case (separate attachment). Regards, Nacho -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33228] - [beanutils] Can't access mapped property in some case
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33228 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 14:58 --- Created an attachment (id=14096) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14096action=view) Test case for this bug -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] API - methods for logging entry and exit events
Phil Steitz [EMAIL PROTECTED] wrote on 01/24/2005 05:25:09 PM: snip/ While I agree with everything that you have said about indiscriminate logging, I think you are missing Richard's point here. In some environments, this sort of ad hoc change is not allowed or cannot be executed quickly enough to help resolve a production problem. The relevant information simply needs to be available in the logs. I agree with you that entry/exit logging and other forms of automatic instrumentation can create more problems than they solve. The challenge is to get the right info into the logs without, as you put it, polluting them with junk that strains the infrastructure and makes it hard to find the relevant info. Sadly, success here depends much less on what the logging framework provides than what the developer is thinking when deciding when and what to log. Agreed 100%. Careful and thoughtful logging should be strongly encouraged, and placed at a high priority. However, logging tends to be an afterthought for many developers, something that is sprinkled in during debugging of particular problems... hence by it's nature it tends to focus on known problems instead of unknown. Entry/exit logging won't necessarily fix this in some cases, but it will provide a minimum of information in those areas of the code that have less focus on thoughtful logging. Note also that the minimum is sufficient in many cases. Taking a step back, I do have to agree that automated and indescriminate logging can result in excessive pollution of a log. So let me say that I'm not advocating that *every* method on every class be instrumented with entry/exit: public methods are good candidates, while small helper methods are less so. Let's step back and look at the bigger picture in such situations. The first thing that comes to my mind is logging related to tight inner loops of a program. I'd be the first to rip indiscriminate logging out of tight loops during runtime or code review. That said, I'd rather have it [automatic] than have nothing. Pick your poison. Please, before anyone jumps down my throat, I'm not advocating eliminating logging from all loops. The key point is that we're all ahead when the community thinks about all aspects of component development. Phil *** Richard A. Sitze IBM WebSphere WebServices Development
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Richard Sitze wrote:
news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki. TRACE is debatable (I personally like
it), more than TRACE is silly.
Well... call them what you will, I want em'!! lol
And yes, I'm leaning towards EXPLICITLY naming methods to encourage best
practices. To use the distinction made by Curt, I'm pushing the trace
level methods towards diagnostic logger function, and stepping away from
other uses entirely. I'm going to refrain from doing a full brain dump on
all the fun thoughts now running through my head... [separating trace
level methods and messaging/admin level methods into seperate interfaces..
ok I lied].
I think we can pretty much lay to rest the argument that including
ENTER/EXIT is a best practice. There have been so many arguments on
both sides of the issue that it's pretty clear we're not going to reach
a concensus. A best practice is something like database connection
pooling, which everyone agrees is a good idea. ENTER/EXIT is a highly
contentious issue, given that this debate has been raging for weeks.
I still don't understand why if you want enter/exit methods you can't
just do it in your own static method somewhere like shown below.
MyLoggingUtils.enter(MyClass.class, myMethodName, new Object[] { arg1,
arg2, arg3 }).
Does JDK 1.4 logging do something really fancy with ENTER/EXIT methods
that makes you argue so strongly for them? Or is there something in
that IBM alphaworks project that depends on the enter/exit methods?
Couldn't it be rewritten to filter TRACE level logging that began with
the text Entering or Exiting?
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] 2.1...
Hello All: I just noticed it's been about a month since the last 2.1 ponderings. Where do we stand now? Curious, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, December 17, 2004 7:22 PM To: Jakarta Commons Developers List Subject: [lang] 2.1... Sorry for the silence from me. As I've probably said a million times, baby happened. I'm full of coding energy, or perhaps the need to 'have coded' that leads to coding happening and looking to direct some of it to Lang 2.1. Looking at the wiki and bugzilla, we were nearly there as far as I recall. Not a lot has cropped up in the 2 months or so that have passed, couple of bugs I've easily closed out and a couple of trickier ones. Gary seems to have taken care of http://issues.apache.org/bugzilla/show_bug.cgi?id=32625. Is it ready for closure Gary? Despite Matt Blum's comment on a work-around, it still sounds like a fine change to the library. The only other new bug is a note on incorrect javadoc and should be an easy one: http://issues.apache.org/bugzilla/show_bug.cgi?id=32619. Stephen listed the following as smelling: --- 1) - ArrayUtils.lastIndex() Gets the last valid index of an array. Surely users would just call getLength() - 1? 2) - ClassUtils.CLASS_NAME_COMPARATOR - ClassUtils.PACKAGE_NAME_COMPARATOR Although potentially useful, they seem quite specific. What about comparing packages using Class objects? (I've never used a Package object in my work) Or comparing just the short name of a class? 3) - NotImplementedException This now implements Nestable, with a lot of extra methods. None of the other exception classes in the main package have been changed. We should revert this change, or find a lighter weight solution that works with ExceptionUtils. 4) - Validate.allElementsOfClass Should rename to allElementsOfType, and use instanceof style check, not class equals style check Still TODO: 5) - WordUtils Capitalize with separator methods need to define null handling for delimiter list, and better javadoc for two of the three methods 6) - time.DurationFormatUtils (complete?) 7) - time.StopWatch (complete?) 8) - text subpackage (not in 2.1) - I think we were all agreed on 8. 6+7 I'm open to ideas on improvements, I think they were complete but need to look again to convince myself. 3, 4 and 5 all look to be quite agreeable and so just need to be done. 1 and 2 look to be justify thy existence questions to the relevant features. So we need to decide whether we think they should go or not. 1 seems to be a classic it's semantically better argument, whereas 2 seems to be a it's not generic enough. Usually we keep code with semantically better arguments and drop not-generic enough code I think, so 1 would stay and 2 would be rm'd. I'm not tied to either though, so ymmv. I've clovered and uploaded to: http://www.apache.org/~bayard/commons-lang-2.1/clover/ Thoughts? Hen - 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: [logging] Enterprise Common Logging... dare we say 2.0?
I kind of think that maybe commons-logging should be deprecated in
favor of:
http://logging.apache.org/log4j/docs/ugli.html
See UGLI does same thing. But competitions is a good thing; my projects
will ship w/ Log4j instead and ugli. One less jar is good.
.V
Matt Sgarlata wrote:
Richard Sitze wrote:
news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki. TRACE is debatable (I personally
like it), more than TRACE is silly.
Well... call them what you will, I want em'!! lol
And yes, I'm leaning towards EXPLICITLY naming methods to encourage
best practices. To use the distinction made by Curt, I'm pushing the
trace level methods towards diagnostic logger function, and stepping
away from other uses entirely. I'm going to refrain from doing a
full brain dump on all the fun thoughts now running through my
head... [separating trace level methods and messaging/admin level
methods into seperate interfaces.. ok I lied].
I think we can pretty much lay to rest the argument that including
ENTER/EXIT is a best practice. There have been so many arguments on
both sides of the issue that it's pretty clear we're not going to
reach a concensus. A best practice is something like database
connection pooling, which everyone agrees is a good idea. ENTER/EXIT
is a highly contentious issue, given that this debate has been raging
for weeks.
I still don't understand why if you want enter/exit methods you can't
just do it in your own static method somewhere like shown below.
MyLoggingUtils.enter(MyClass.class, myMethodName, new Object[] {
arg1, arg2, arg3 }).
Does JDK 1.4 logging do something really fancy with ENTER/EXIT methods
that makes you argue so strongly for them? Or is there something in
that IBM alphaworks project that depends on the enter/exit methods?
Couldn't it be rewritten to filter TRACE level logging that began with
the text Entering or Exiting?
Matt
--
Forums, Boards, Blogs and News in RiA http://www.boardVU.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Well now... that IS interesting.
flames on
How in the WORLD did this happen? I approached Ceki about aligning JCL
with Log4J... and was turned down, he simply wasn't interested and
wouldn't acknowledge the value of the abstraction [at that time].
This feels like 'not-invented-here' and some backstabbing. How can we
POSSIBLY accomplish our goals if we simply refuse to acknowledge that
other projects have value?! What can we achieve with competing
abstractions at this level?
Frankly, I expected better of the Apache Logging Services community.
Excuse me while I go find a wall and beat my head against it for a
while...
flames off
ras
news [EMAIL PROTECTED] wrote on 01/25/2005 01:21:24 PM:
I kind of think that maybe commons-logging should be deprecated in
favor of:
http://logging.apache.org/log4j/docs/ugli.html
See UGLI does same thing. But competitions is a good thing; my projects
will ship w/ Log4j instead and ugli. One less jar is good.
.V
Matt Sgarlata wrote:
Richard Sitze wrote:
news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki. TRACE is debatable (I personally
like it), more than TRACE is silly.
Well... call them what you will, I want em'!! lol
And yes, I'm leaning towards EXPLICITLY naming methods to encourage
best practices. To use the distinction made by Curt, I'm pushing the
trace level methods towards diagnostic logger function, and stepping
away from other uses entirely. I'm going to refrain from doing a
full brain dump on all the fun thoughts now running through my
head... [separating trace level methods and messaging/admin level
methods into seperate interfaces.. ok I lied].
I think we can pretty much lay to rest the argument that including
ENTER/EXIT is a best practice. There have been so many arguments on
both sides of the issue that it's pretty clear we're not going to
reach a concensus. A best practice is something like database
connection pooling, which everyone agrees is a good idea. ENTER/EXIT
is a highly contentious issue, given that this debate has been raging
for weeks.
I still don't understand why if you want enter/exit methods you can't
just do it in your own static method somewhere like shown below.
MyLoggingUtils.enter(MyClass.class, myMethodName, new Object[] {
arg1, arg2, arg3 }).
Does JDK 1.4 logging do something really fancy with ENTER/EXIT methods
that makes you argue so strongly for them? Or is there something in
that IBM alphaworks project that depends on the enter/exit methods?
Couldn't it be rewritten to filter TRACE level logging that began with
the text Entering or Exiting?
Matt
--
Forums, Boards, Blogs and News in RiA http://www.boardVU.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
***
Richard A. Sitze
IBM WebSphere WebServices Development
RE: [codec] Base64.isArrayByteBase64() issue
Title: RE: [codec] Base64.isArrayByteBase64() issue (WAS: codec : Bas64.isArrayByteBase64() issue)
Hi Gary,
The issue was resolved recently in the CVS
version.
There is still a test that's worth keeping
around (attached as a patch) and some much more minor changes (also as a patch)
that improve the code (1. performance of discardWhitespace(),
2.space used by static arrays, 3. typos: octect = octet.) provided if
you want to use it (heck, I wrote it before I saw the fixed CVS version, so why
not at least submit it to the project). Since its no longer a bug I won't
create an issue in Bugzilla.
= Ezra E.
From: Gary Gregory
[mailto:[EMAIL PROTECTED]Sent: Mon 1/24/2005 5:52
PMTo: Jakarta Commons Developers ListSubject: RE: [codec]
Base64.isArrayByteBase64() issue (WAS: codec : Bas64.isArrayByteBase64()
issue)
Hello Ezra:Yes, it would be great if you could
provide a unit test patch when yousubmit a bug report. This is more
effective than me or another codecvolunteer recreating the issue from
scratch.It would be best to for you to create a Bugzilla issue
when you want toreport an issue in order to make sure it does not get
lost.Thank
you,GaryFrom:
Ezra Epstein [mailto:[EMAIL PROTECTED]]Sent: Monday,
January 24, 2005 5:27 PMTo: commons-dev@jakarta.apache.orgSubject: RE:
codec : Bas64.isArrayByteBase64() issueOooops. Wrong patch
file. Correct one is attached.= Ezra
E.From: Ezra Epstein [mailto:[EMAIL PROTECTED]]Sent: Mon
1/24/2005 5:22 PMTo: commons-dev@jakarta.apache.orgSubject: codec :
Bas64.isArrayByteBase64() issueThere seem to be 2
issues.1. Only 255 byte values are used
when creating base64Alphabet, butthere are 256 possible
values2. octect (shouldn't that be octet ?)
isn't shifted despite thefact that Java uses unsigned bytes. It is
used unchanged as on offsetinto an array (zero based).As a result I
can produce test cases that cause isBase64() to throwIndexOutOfBounds
exceptions.While at it, I suggest one line be added to
discardWhitespace() thatwill improve performance under some circumstances
(i.e., when there isno whitespace in the input).Patch file is
attached.Patch file is based on latest version in CVS ofBase64.java file:
1.23= Ezra E.P.S., I can provide a jUnit TestCase if that's
useful.
Index: Base64.java
===
RCS file:
/home/cvspublic/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/Base64.java,v
retrieving revision 1.23
diff -u -r1.23 Base64.java
--- Base64.java 24 Nov 2004 19:23:25 - 1.23
+++ Base64.java 25 Jan 2005 19:43:21 -
@@ -53,9 +53,9 @@
static final byte[] CHUNK_SEPARATOR = \r\n.getBytes();
/**
- * The base length.
+ * The base length. Positive byte values are from 0 to [EMAIL PROTECTED]
*/
-static final int BASELENGTH = 255;
+static final int BASELENGTH = 128;
/**
* Lookup length.
@@ -154,15 +154,15 @@
}
/**
- * Returns whether or not the codeoctect/code is in the base 64
alphabet.
+ * Returns whether or not the codeoctet/code is in the base 64
alphabet.
*
- * @param octect The value to test
+ * @param octet The value to test
* @return codetrue/code if the value is defined in the the base 64
alphabet, codefalse/code otherwise.
*/
-private static boolean isBase64(byte octect) {
-if (octect == PAD) {
+private static boolean isBase64(byte octet) {
+if (octet == PAD) {
return true;
-} else if (octect 0 || base64Alphabet[octect] == -1) {
+} else if (octet 0 || base64Alphabet[octet] == -1) {
return false;
} else {
return true;
@@ -173,22 +173,22 @@
* Tests a given byte array to see if it contains
* only valid characters within the Base64 alphabet.
*
- * @param arrayOctect byte array to test
+ * @param arrayOctet byte array to test
* @return codetrue/code if all bytes are valid characters in the
Base64
* alphabet or if the byte array is empty; false, otherwise
*/
-public static boolean isArrayByteBase64(byte[] arrayOctect) {
+public static boolean isArrayByteBase64(byte[] arrayOctet) {
-arrayOctect = discardWhitespace(arrayOctect);
+arrayOctet = discardWhitespace(arrayOctet);
-int length = arrayOctect.length;
+int length = arrayOctet.length;
if (length == 0) {
// shouldn't a 0 length array be valid base64 data?
// return false;
return true;
}
for (int i = 0; i length; i++) {
-if (!isBase64(arrayOctect[i])) {
+if (!isBase64(arrayOctet[i])) {
return false;
}
}
@@ -392,7 +392,7 @@
}
/**
- * Decodes Base64 data into octects
+ * Decodes Base64 data into octets
*
DO NOT REPLY [Bug 31457] - [dbcp] Transaction conflicts in Oracle will corrupt prepared statements in the dbcp pool.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31457. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31457 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 20:53 --- Created an attachment (id=14102) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14102action=view) Java source code that demonstrates the bug. This problem does not exist in CP30, and it occurs ONLY when DBCP is configured with poolPreparedStatements=true. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] proposal: FileUtils
Hi Brian! Sorry for the long delay. I was in an delivery period and therefore out of time. After the next week I should have more time again. I am not sure we should implement a poor-man's transaction if we could have more ([transaction] ) for free. Hmmm, I would like to have a depper look on this, remind, if [transaction] fits our needs, we might have locking too. Please let us delay this decision for a while, before we do the hard work I would like to see myself that [transaction] is really overkill. Thanks! --- Mario smime.p7s Description: S/MIME Cryptographic Signature
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 2005-01-25 19:40:35, Richard Sitze wrote: How in the WORLD did this happen? UGLI did not happen overnight. The idea was discussed on this list among others over 6 months ago. http://marc.theaimsgroup.com/?t=10865459724r=1w=2 This feels like 'not-invented-here' and some backstabbing. How can we POSSIBLY accomplish our goals if we simply refuse to acknowledge that other projects have value?! What can we achieve with competing abstractions at this level? The answer can be summarized in a few words: look Ma, no class loaders! Frankly, I expected better of the Apache Logging Services community. Agreed. How dare Apache Logging Services write a logging interface? Moreover, they never complained about JCL before. Seriously, aren't you sick of JCL exploding with an LogConfigurationException at the most inappropriate times? Excuse me while I go find a wall and beat my head against it for a while... No problem. You'll thank us later. :-) -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][VOTE] svn migration
+1 On Sat, 2005-01-22 at 13:31 -0500, Tim O'Brien wrote: Alright a sufficient amount of time has passed for public comments and testing. This is a vote thread for migrating commons to SVN. If this vote passes, I'll contact Justin and schedule the least disruptive migration time possible. Tim O'Brien - 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: [logging] Enterprise Common Logging... dare we say 2.0?
I'm confused Ceki. You've spent a lot of time discussing commons-logging on this list, while at the same time supporting development of UGLI. Which component is your favorite? How come you're working on 2? Matt Ceki Gülcü wrote: On 2005-01-25 19:40:35, Richard Sitze wrote: How in the WORLD did this happen? UGLI did not happen overnight. The idea was discussed on this list among others over 6 months ago. http://marc.theaimsgroup.com/?t=10865459724r=1w=2 This feels like 'not-invented-here' and some backstabbing. How can we POSSIBLY accomplish our goals if we simply refuse to acknowledge that other projects have value?! What can we achieve with competing abstractions at this level? The answer can be summarized in a few words: look Ma, no class loaders! Frankly, I expected better of the Apache Logging Services community. Agreed. How dare Apache Logging Services write a logging interface? Moreover, they never complained about JCL before. Seriously, aren't you sick of JCL exploding with an LogConfigurationException at the most inappropriate times? Excuse me while I go find a wall and beat my head against it for a while... No problem. You'll thank us later. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Management of transactions...
see reply on commons-user list -- Dirk ksv wrote: Hello , Interests everything, that is connected to managements of transactions at use DBCP... Who Can will share experience or links? The database is not essential. The principle of work with transactions through DBCP is necessary... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 2005-01-25 20:45:34, Matt Sgarlata wrote: I'm confused Ceki. You've spent a lot of time discussing commons-logging on this list, while at the same time supporting development of UGLI. Which component is your favorite? How come you're working on 2? As far as I knew, swearing allegiance to commons-logging was not a prerequisite for participation in this list. Moreover, my position on JCL was always publicly known [1]. [1] http://www.qos.ch/logging/thinkAgain.jsp Matt -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Matt Sgarlata wrote: You've spent a lot of time discussing commons-logging on this list, while at the same time supporting development of UGLI. Which component is your favorite? How come you're working on 2? Simmer down now. Lets act intelligent. Many people work on many things and share code across projects its a friendly license. Look at Struts, it has JSF subprojects under it, or lets play how many duplicate projects we can name under ASF. Its all good. Much duplication in Apache, all of it good. Choice = = good. What was that platform where they have the ONE true way? .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
I'm sorry, I didn't mean for my post to sound angry, and I'm sorry if anyone took offense. I was just asking :) Ceki, thanks for that link. You have many excellent points, and I may migrate my projects away from commons-logging. Matt Vic wrote: Matt Sgarlata wrote: You've spent a lot of time discussing commons-logging on this list, while at the same time supporting development of UGLI. Which component is your favorite? How come you're working on 2? Simmer down now. Lets act intelligent. Many people work on many things and share code across projects its a friendly license. Look at Struts, it has JSF subprojects under it, or lets play how many duplicate projects we can name under ASF. Its all good. Much duplication in Apache, all of it good. Choice = = good. What was that platform where they have the ONE true way? ..V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[beanutils] Problem with indexed properties
Someone on struts-user got tripped up by what I thought was a bean that
didn't conform to the spec, but then I learned that for an indexed property,
you can have four accessors, such as:
String[] getProp()
String getProp( int )
void setProp( String[] )
void setProp( int, String )
The struts user threads are:
http://marc.theaimsgroup.com/?t=11064425001r=1w=2
http://marc.theaimsgroup.com/?t=11066637976r=1w=2
I can reproduce the 'argument type mismatch' error under both Windows and
HP-UX, with JDK 1.4.2 or 1.5.0, with this code:
BeanUtilsBean beanUtilsBean = new BeanUtilsBean(
new ConvertUtilsBean(),
new PropertyUtilsBean());
IndexedBean bean = new IndexedBean();
String[] newValue = new String[] { dog, cat, bird };
beanUtilsBean.setProperty(bean, prop, newValue );
(IndexedBean just has the four methods shown above.)
test.bean:
[echo] Running BeanUtils tests ...
[java] [ERROR] PropertyUtils - Method invocation failed.
java.lang.IllegalArgumentException: argument type
mismatchjava.lang.IllegalArgumentException: argument type mismatch
The additional test and bean are attached to bug 28358.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28358
It was originally reported as a JVM problem, but even if the code would work
under 1.3.1, that isn't going to help those of us who have long since moved
up to 1.4 and 1.5.
--
Wendy Smoak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Enterprise Common Logging... dare we say 2.0?
Richard:
You might find the attached GIF handy ;-)
Gary
-Original Message-
From: Richard Sitze [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 25, 2005 11:41 AM
To: Jakarta Commons Developers List
Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
Well now... that IS interesting.
flames on
How in the WORLD did this happen? I approached Ceki about aligning JCL
with Log4J... and was turned down, he simply wasn't interested and
wouldn't acknowledge the value of the abstraction [at that time].
This feels like 'not-invented-here' and some backstabbing. How can we
POSSIBLY accomplish our goals if we simply refuse to acknowledge that
other projects have value?! What can we achieve with competing
abstractions at this level?
Frankly, I expected better of the Apache Logging Services community.
Excuse me while I go find a wall and beat my head against it for a
while...
flames off
ras
news [EMAIL PROTECTED] wrote on 01/25/2005 01:21:24 PM:
I kind of think that maybe commons-logging should be deprecated in
favor of:
http://logging.apache.org/log4j/docs/ugli.html
See UGLI does same thing. But competitions is a good thing; my
projects
will ship w/ Log4j instead and ugli. One less jar is good.
.V
Matt Sgarlata wrote:
Richard Sitze wrote:
news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki. TRACE is debatable (I personally
like it), more than TRACE is silly.
Well... call them what you will, I want em'!! lol
And yes, I'm leaning towards EXPLICITLY naming methods to encourage
best practices. To use the distinction made by Curt, I'm pushing
the
trace level methods towards diagnostic logger function, and
stepping
away from other uses entirely. I'm going to refrain from doing a
full brain dump on all the fun thoughts now running through my
head... [separating trace level methods and messaging/admin level
methods into seperate interfaces.. ok I lied].
I think we can pretty much lay to rest the argument that including
ENTER/EXIT is a best practice. There have been so many arguments
on
both sides of the issue that it's pretty clear we're not going to
reach a concensus. A best practice is something like database
connection pooling, which everyone agrees is a good idea.
ENTER/EXIT
is a highly contentious issue, given that this debate has been
raging
for weeks.
I still don't understand why if you want enter/exit methods you
can't
just do it in your own static method somewhere like shown below.
MyLoggingUtils.enter(MyClass.class, myMethodName, new Object[] {
arg1, arg2, arg3 }).
Does JDK 1.4 logging do something really fancy with ENTER/EXIT
methods
that makes you argue so strongly for them? Or is there something in
that IBM alphaworks project that depends on the enter/exit methods?
Couldn't it be rewritten to filter TRACE level logging that began
with
the text Entering or Exiting?
Matt
--
Forums, Boards, Blogs and News in RiA http://www.boardVU.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
***
Richard A. Sitze
IBM WebSphere WebServices Development
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 2.1...
Checking my mail history Still TODO: 5) - WordUtils Capitalize with separator methods need to define null handling for delimiter list, and better javadoc for two of the three methods And thats it, besides finding a volunteer to do the release (before a svn change?) Stephen - Original Message - From: Gary Gregory [EMAIL PROTECTED] Hello All: I just noticed it's been about a month since the last 2.1 ponderings. Where do we stand now? Curious, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, December 17, 2004 7:22 PM To: Jakarta Commons Developers List Subject: [lang] 2.1... Sorry for the silence from me. As I've probably said a million times, baby happened. I'm full of coding energy, or perhaps the need to 'have coded' that leads to coding happening and looking to direct some of it to Lang 2.1. Looking at the wiki and bugzilla, we were nearly there as far as I recall. Not a lot has cropped up in the 2 months or so that have passed, couple of bugs I've easily closed out and a couple of trickier ones. Gary seems to have taken care of http://issues.apache.org/bugzilla/show_bug.cgi?id=32625. Is it ready for closure Gary? Despite Matt Blum's comment on a work-around, it still sounds like a fine change to the library. The only other new bug is a note on incorrect javadoc and should be an easy one: http://issues.apache.org/bugzilla/show_bug.cgi?id=32619. Stephen listed the following as smelling: --- 1) - ArrayUtils.lastIndex() Gets the last valid index of an array. Surely users would just call getLength() - 1? 2) - ClassUtils.CLASS_NAME_COMPARATOR - ClassUtils.PACKAGE_NAME_COMPARATOR Although potentially useful, they seem quite specific. What about comparing packages using Class objects? (I've never used a Package object in my work) Or comparing just the short name of a class? 3) - NotImplementedException This now implements Nestable, with a lot of extra methods. None of the other exception classes in the main package have been changed. We should revert this change, or find a lighter weight solution that works with ExceptionUtils. 4) - Validate.allElementsOfClass Should rename to allElementsOfType, and use instanceof style check, not class equals style check Still TODO: 5) - WordUtils Capitalize with separator methods need to define null handling for delimiter list, and better javadoc for two of the three methods 6) - time.DurationFormatUtils (complete?) 7) - time.StopWatch (complete?) 8) - text subpackage (not in 2.1) - I think we were all agreed on 8. 6+7 I'm open to ideas on improvements, I think they were complete but need to look again to convince myself. 3, 4 and 5 all look to be quite agreeable and so just need to be done. 1 and 2 look to be justify thy existence questions to the relevant features. So we need to decide whether we think they should go or not. 1 seems to be a classic it's semantically better argument, whereas 2 seems to be a it's not generic enough. Usually we keep code with semantically better arguments and drop not-generic enough code I think, so 1 would stay and 2 would be rm'd. I'm not tied to either though, so ymmv. I've clovered and uploaded to: http://www.apache.org/~bayard/commons-lang-2.1/clover/ Thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33228] - [beanutils] Can't access mapped property in some case
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33228 --- Additional Comments From [EMAIL PROTECTED] 2005-01-26 04:31 --- Thanks a lot! I'm looking forward to applying your patch to the source tree! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all][VOTE][Results] commons svn migration
More than 72 hours have passed for this vote, I think everyone has had ample opportunity to weigh in. We need to do this when Justin is free, and that happens to be Thursday morning or afternoon. Most other conversions are simple one shot conversions, but commons is really more of a series of conversions - each component is converted separately, combined, and then dumped to a dump which we can then import into the ASF repository. It takes 3-4 hours, so when I confirm with Justin, I'll send a note to commons-dev with the time we'll lock the CVS repository. Henri, what, if anything, do we need to do to migrate karma? Vote Summary follows: The original vote message: This is a vote thread for migrating commons to SVN. If this vote passes, I'll contact Justin and schedule the least disruptive migration time possible. Vote: 16 +1s, 4 +0s, 5 -0s, 0 -1s +0 Emmanuel Bourg +1 Don Brown +0 Steve Cohen (+0.75) -0 Stephen Colebourne (-0.9) +1 Martin Cooper +1 Torsten Curdt +1 Mark Diggory +1 Mauro Franceschini +1 Joe Germuska -0 Dion Gillard -0 Hans Glide +1 David Graham -0 Gary Gregory +0 Oliver Heger +1 Ted Husted +0 Mario Ivankovits +1 Jerome Jar +1 Oleg Kalnichevski +1 Paul Libbrecht +1 Alex Karasulu +1 Simon Kitching -0 Peter Royal +1 Phil Steitz +1 Rory Winston +1 Henri Yandell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[i18n,xmlio] current class diagrams
I'm doing some revisions on i18n and, to do this, I reverse the class diagrams below: i18n http://www.drianoxaman.kit.net/sandbox/i18n.gif http://www.drianoxaman.kit.net/sandbox/i18n.doc xmlio (in): http://www.drianoxaman.kit.net/sandbox/xml-in.gif http://www.drianoxaman.kit.net/sandbox/xmlio-in.doc xmlio (out): http://www.drianoxaman.kit.net/sandbox/xml-out.gif http://www.drianoxaman.kit.net/sandbox/xmlio-out.doc and the respective rose model (i18n and xmlio packages): http://www.drianoxaman.kit.net/sandbox/i18n-rose.zip I´m finishing a junit test suit to i18n too. I wish it help Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[feedparser] Fwd: [ST-J] java rss?
From a mailing list I'm on. Thought the developers would like to know. -- Forwarded message -- From: Scot Mcphee [EMAIL PROTECTED] Date: Wed, 26 Jan 2005 15:35:34 +1100 Subject: Re: [ST-J] java rss? To: [EMAIL PROTECTED] yeah I considered that, but you know, I was just trying out the Configuration system and the PropertyConfiguration appears to indulge in duplicating all the keys every time you write() the config back to the disk! The quality of some Commons projects leave a bit to be desired sometimes. regs scot. On Wed, 26 Jan 2005 10:56:07 +1100, Dion Gillard [EMAIL PROTECTED] wrote: http://jakarta.apache.org/commons/sandbox/feedparser/ On Tue, 25 Jan 2005 21:29:29 +1100, Scot Mcphee [EMAIL PROTECTED] wrote: anyone got an opinions, experiences, with java libraries to handle RSS? I've found informa, but it appears to be designed to solve slightly different problems than the one i'm looking at. perhaps i'll just have to resort to DOM or something. -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Fwd: [ST-J] java rss?
Dion Gillard wrote: From a mailing list I'm on. yeah I considered that, but you know, I was just trying out the Configuration system and the PropertyConfiguration appears to indulge in duplicating all the keys every time you write() the config back to the disk! The quality of some Commons projects leave a bit to be desired sometimes. Theres now way this is the FeedParser... we don't have a properties configuration system. Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n,xmlio] current class diagrams
Is your server up? I wanted to have a look at your diagrams, but the request timed out :( Oliver On Wed, 26 Jan 2005 01:13:07 -0800, Anaximandro (Woody) [EMAIL PROTECTED] wrote: I'm doing some revisions on i18n and, to do this, I reverse the class diagrams below: i18n http://www.drianoxaman.kit.net/sandbox/i18n.gif http://www.drianoxaman.kit.net/sandbox/i18n.doc xmlio (in): http://www.drianoxaman.kit.net/sandbox/xml-in.gif http://www.drianoxaman.kit.net/sandbox/xmlio-in.doc xmlio (out): http://www.drianoxaman.kit.net/sandbox/xml-out.gif http://www.drianoxaman.kit.net/sandbox/xmlio-out.doc and the respective rose model (i18n and xmlio packages): http://www.drianoxaman.kit.net/sandbox/i18n-rose.zip I´m finishing a junit test suit to i18n too. I wish it help Woody - 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]
