Re: jcl blog post

[Shey Rab Pawo]

> Anyway... I called my newborn connection pool BDCP (basic database
> connection pool).
> 
> Its about 1/5 the size of DBCP and a LOT easier to maintain.

I built my own connection pool for similar but less informed reasons. 
I found DBCP to be simply unworkable for some reason.  I may have been
at fault, but I normally do not have that much trouble with anything. 
I would be very interested in seeing your BDCP, if you are making that
public.

-- 
The radiance of all the stars does not equal a sixteenth part of the
moon's radiance, likewise, good deeds giving us merit, all these do
not equal a sixteenth part of the merit of loving-kindness..

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How do I import into the sandbox?

[Kevin A. Burton]

Brett Porter wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
svn import
https://svn.apache.org/repos/asf/jakarta/commons/sandbox/benchmark/trunk
from inside the directory you have your code locally
Later you need to go to the sandbox checkout of trunks-sandbox and do
svn propedit svn:externals .
and add your new project to have it checked out
Use svn commit -N . to commit just the directory changes.
 

Sweet... I'll add this to the UsingSVN wiki page...
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: How do I import into the sandbox?

[Brett Porter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

svn import
https://svn.apache.org/repos/asf/jakarta/commons/sandbox/benchmark/trunk

from inside the directory you have your code locally

Later you need to go to the sandbox checkout of trunks-sandbox and do
svn propedit svn:externals .
and add your new project to have it checked out

Use svn commit -N . to commit just the directory changes.

HTH,
Brett

Kevin A. Burton wrote:

> Maybe this is a stupid question but spending the last 30 minutes I
can't figure out how to import into SVN.
>
> http://wiki.apache.org/jakarta-commons/UsingSVN
>
> Doesn't document it... and all I can figure out from the above and the
dox is that the import command would be:
>
> svn import
https://svn.apache.org/repos/asf/jakarta/commons/sandbox/benchmark/trunk
jakarta/commons/trunks-sandbox/benchmark
>
> Is this correct? "benchmark" is the name of the package I want to
import and play with in the sandbox.
>
> Kevin
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCEvYyOb5RoQhMkRMRAmTUAKCBsUCVM8+wpj3YnFo15o8FwfIBdACcDf+R
p99txJ8fKvI7BPv5kdPZevc=
=XSqn
-END PGP SIGNATURE-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How do I import into the sandbox?

[Kevin A. Burton]

Maybe this is a stupid question but spending the last 30 minutes I can't 
figure out how to import into SVN.

http://wiki.apache.org/jakarta-commons/UsingSVN
Doesn't document it... and all I can figure out from the above and the 
dox is that the import command would be:

svn import 
https://svn.apache.org/repos/asf/jakarta/commons/sandbox/benchmark/trunk 
jakarta/commons/trunks-sandbox/benchmark

Is this correct?  "benchmark" is the name of the package I want to 
import and play with in the sandbox.

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]

[Jakarta Commons Wiki] Updated: TheSandbox

[commons-dev]

   Date: 2005-02-15T23:06:14
   Editor: KevinBurton
   Wiki: Jakarta Commons Wiki
   Page: TheSandbox
   URL: http://wiki.apache.org/jakarta-commons/TheSandbox

   no comment

Change Log:

--
@@ -17,6 +17,7 @@
  * ThreadPool
  * VFS - under active development again.
  * Workflow
+ * FeedParser
 
 = Unpublished =
 
@@ -29,7 +30,6 @@
  * Servlet - not enough here to justify a component
  * Threading - migrated over from Avalon Excalibur. Currently inactive.
  * xo - XML to Bean mapper.
- * FeedParser
 
 = Dead =
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jcl blog post

[Kevin A. Burton]

Craig McClanahan wrote:
On Tue, 15 Feb 2005 22:50:51 -0600, Vic <[EMAIL PROTECTED]> wrote:
 

oops :-[
Wrong link, this is it:
http://www.szegedi.org/articles/memleak.html
It talks about Commons logging, since i'ts open season.
.V
   

There's lots of ways to shoot yourself in the foot the same way ...
you don't need JCL to do that ... pretty much any implementation of
the factory design pattern should be looked at with suspicion.
By the way ... if you use [chain] you should *really* pay attention to
the Javadocs for CatalogFactory.clear() ;-)
 

You know I have a similar little story about Commons DBCP.
Its evil.. pure evil! ;)
I actually rewrote it from scratch because I needed a good connection 
pool implementation and DBCP just wasn't cutting it but it was 85% there.

So one weekend I gutted the core and wrote my own pool implementation 
and increased performance significantly.

The key part for me was that for SOME reason in my highly multithreaded 
app it would bleed connections. After about 48 hours our app wouldn't 
have any more connections and all my threads would sit there sleeping 
waiting for connections that would never come.

Anyway... I called my newborn connection pool BDCP (basic database 
connection pool).

Its about 1/5 the size of DBCP and a LOT easier to maintain.
Anyway... I was considering OSSing it here in the future but didn't know 
how to approach it with commons-dbcp folks...

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

svn commit: r153994 - jakarta/commons/proper/email/trunk/project.xml

[epugh]

Author: epugh
Date: Tue Feb 15 21:22:10 2005
New Revision: 153994

URL: http://svn.apache.org/viewcvs?view=rev&rev=153994
Log:
Fix email address.  Test commit privileges under SVN

Modified:
jakarta/commons/proper/email/trunk/project.xml

Modified: jakarta/commons/proper/email/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/email/trunk/project.xml?view=diff&r1=153993&r2=153994
==
--- jakarta/commons/proper/email/trunk/project.xml (original)
+++ jakarta/commons/proper/email/trunk/project.xml Tue Feb 15 21:22:10 2005
@@ -60,7 +60,7 @@
 
 Eric Pugh
 epugh
-[EMAIL PROTECTED]
+[EMAIL PROTECTED]
 OpenSource Connections
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jcl blog post

[Craig McClanahan]

On Tue, 15 Feb 2005 22:50:51 -0600, Vic <[EMAIL PROTECTED]> wrote:
> oops :-[
> Wrong link, this is it:
> http://www.szegedi.org/articles/memleak.html
> 
> It talks about Commons logging, since i'ts open season.
> .V

There's lots of ways to shoot yourself in the foot the same way ...
you don't need JCL to do that ... pretty much any implementation of
the factory design pattern should be looked at with suspicion.

By the way ... if you use [chain] you should *really* pay attention to
the Javadocs for CatalogFactory.clear() ;-)

Craig

> 
> 
> -
> 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 33550] - [digester] Add support for CallMethodRule with target offset in xml rules

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33550





--- Additional Comments From [EMAIL PROTECTED]  2005-02-16 05:52 ---
Ok, I've committed the patch to subversion, with some changes. 

The following are equivalent:
  new CallMethodRule(methodName);
and
  new CallMethodRule(0, methodName); // targetoffset=0
This fact allowed the code to be simplified while giving the same effect (I 
think).

Wendy, would you mind testing this? It would be even better if you could provide
a patch to the unit tests...

And thanks for the patch..

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r153990 - in jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/xmlrules: DigesterRuleParser.java digester-rules.dtd

[skitching]

Author: skitching
Date: Tue Feb 15 20:51:55 2005
New Revision: 153990

URL: http://svn.apache.org/viewcvs?view=rev&rev=153990
Log:
Support "target offset" feature of CallMethodRule in xmlrules.
Patch by Wendy Smoak (with minor alterations). See bugzilla #33550.

Modified:

jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/xmlrules/DigesterRuleParser.java

jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/xmlrules/digester-rules.dtd

Modified: 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/xmlrules/DigesterRuleParser.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/xmlrules/DigesterRuleParser.java?view=diff&r1=153989&r2=153990
==
--- 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/xmlrules/DigesterRuleParser.java
 (original)
+++ 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/xmlrules/DigesterRuleParser.java
 Tue Feb 15 20:51:55 2005
@@ -1,4 +1,4 @@
-/* $Id: DigesterRuleParser.java,v 1.32 2005/01/18 00:11:12 skitching Exp $
+/* $Id$
  *
  * Copyright 2001-2004 The Apache Software Foundation.
  * 
@@ -540,31 +540,53 @@
 public Object createObject(Attributes attributes) {
 Rule callMethodRule = null;
 String methodName = attributes.getValue("methodname");
+
+// Select which element is to be the target. Default to zero,
+// ie the top object on the stack.
+int targetOffset = 0;
+String targetOffsetStr = attributes.getValue("targetoffset");
+if (targetOffsetStr != null) {
+targetOffset = Integer.parseInt(targetOffsetStr);
+}
+
 if (attributes.getValue("paramcount") == null) {
 // call against empty method
-callMethodRule = new CallMethodRule(methodName);
+callMethodRule = new CallMethodRule(targetOffset, methodName);
 
 } else {
 int paramCount = 
Integer.parseInt(attributes.getValue("paramcount"));
 
 String paramTypesAttr = attributes.getValue("paramtypes");
 if (paramTypesAttr == null || paramTypesAttr.length() == 0) {
-callMethodRule = new CallMethodRule(methodName, 
paramCount);
+callMethodRule = new CallMethodRule(targetOffset, 
methodName, paramCount);
 } else {
-// Process the comma separated list or paramTypes
-// into an array of String class names
-ArrayList paramTypes = new ArrayList();
-StringTokenizer tokens = new 
StringTokenizer(paramTypesAttr, " \t\n\r,");
-while (tokens.hasMoreTokens()) {
-paramTypes.add(tokens.nextToken());
-}
-callMethodRule = new CallMethodRule( methodName,
-paramCount,
-
(String[])paramTypes.toArray(new String[0]));
+String[] paramTypes = getParamTypes(paramTypesAttr);
+callMethodRule = new CallMethodRule(
+targetOffset, methodName, paramCount, paramTypes);
 }
 }
 return callMethodRule;
 }
+
+/**
+ * Process the comma separated list of paramTypes
+ * into an array of String class names
+ */
+private String[] getParamTypes(String paramTypes) {
+String[] paramTypesArray;
+if( paramTypes != null ) {
+ArrayList paramTypesList = new ArrayList();
+StringTokenizer tokens = new StringTokenizer(
+paramTypes, " \t\n\r,");
+while (tokens.hasMoreTokens()) {
+paramTypesList.add(tokens.nextToken());
+}
+paramTypesArray = (String[])paramTypesList.toArray(new 
String[0]);
+} else {
+paramTypesArray = new String[0];
+}
+return paramTypesArray;
+}
 }
 
 /**
@@ -791,4 +813,5 @@
 rule.addAlias(attrName, propName);
 }
 }
+
 }

Modified: 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/xmlrules/digester-rules.dtd
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/xmlrules/digester-rules.dtd?view=diff&r1=153989&r2=153990
==
--- 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/xmlrules/digester-rules.dtd
 (original)
+++ 
jakarta/commons/prop

Re: jcl blog post

[Vic]

oops :-[
Wrong link, this is it:
http://www.szegedi.org/articles/memleak.html
It talks about Commons logging, since i'ts open season.
.V

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [i18n] man available

[Anaximandro (Woody)]

Hello Daniel,

Yup, the ConfigManager not prove to be very usefull. This class is
increasing the coupling level to give me a few features set (the con
figuration features itself) and gave me much more code to delegate ...

But you don't think necessary some code to configure the behaviours of
this component? For instance: in your version when the component not
find one message id they throw one unchecked exception. The component
dont't force me to write one try catch block for each LocalizedEntry but
force me to write all messages ids in their respective resource to avoid
one exception. Avoid try catch blocks is cool, very cool, but this only
make my code more clean, however the cost to do this is high: I must write
the messages id (at least) to don't break the application, but if I forget
one id the application will break in same mode.

Using some code to configure this helps in this situation. I can talk to
component: hey pal, use the message id or entry id as default when you not
find someone. Don't throw an exception, instead, write this in log. I
will write these messages later ok?

Hence I think is better to leave this decision to the user component. I
know you wanna a small and easy to use component, I want the same think,
but ... I think is more easy to use a componente wich can be configured
than one wich we can't do this.

Sorry if I'm talking to much, I really wanna help but my english make this
more hard than really is.

Only one MessageManager? no getInstance? As I see the problem exists
when many threads (with different Locales) try to get a message. I don't
see any problem with diferent applications (sure, the unique ID is requi
red). If you use only one MessageManager you will need to always provide
the desired Locale (in constructor or in getXXX method) because there is
no more a place to store a default Locale info since the older place
(setLocale/getLocale) will be shared by this threads. More than this,
doing this will bestrew Locale info in resulting client code making this
more hard to update. Well, this is just my opinion.

I try to solve this writing the getInstance (as you suggest in email)
but with this I create another problem: how to link a message with their
respective manager? Passing this guy as parameter? nope, this is ugly. So
writing some method to returns the current manager? Yes, make sense, then:
getCurrentInstance, but, again, I created another problem: I need to write
monitor code to lock unlock the instance to avoid data corruption (between
threads). I think this is the last thing I need to close my version. I will
do this (is a little hard to me because I never do this before).

I'm right im my point? I miss something?

Did you find some good idea in my code? If you do I can revise and generate
the apropriate patch to you.

Good luck with envinronment (to be honest I need to learn maven, I just
used eclipse, always redoing the configuration when I need).

Woody

>Hi Woody,
>I'm currently trying to improve the maven environment, so that releases and
>tests can easily be done.
>My goal is to complete the component in the actual state in order to build
a
>usable release as soon as possible.
>I've already had a look at your proposed changes. I'd like to include some
>changes into the current version (LocalizedRuntimeException), but I'm not
>sure with the ConfigManager. This one introduces a lot of complexity.
>In order to keep the i18n-component very simple my suggestions would be to
>keep only one MessageManager with static methods and advice the user to use
>unique message keys (comparable to java package names). This should avoid
>trouble when using multiple applications. Agreed?
>Next steps are to remove misleading methods (as we discussed earlier) and
to
>complete the javadocs and provide some more tutorials. This is the part
>where help would be very much appreciated ;-)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[chain] LookupCommand's return value

[Joe Germuska]

I just realized that LookupCommand returns the return value of 
whatever command it looks up and executes.  This was 
counter-intuitive to what I was trying to achieve, and, I would 
argue, limited if not broken.

public boolean execute(Context context) throws Exception {
Command command = getCommand(context);
if (command != null) {
return (command.execute(context));
} else {
return (false);
}
   }
As it is now, there's no way to abort a looked-up chain without 
causing the base chain to also abort.  It seems like this would not 
always be the desired result.  Specifically, in Struts, I would like 
to implement a command which aborts the chain if the form is invalid 
so that we can eliminate three or four repetitive tests for the same 
condition in commands which follow validation.  It seems like those 
commands shouldn't need to know the condition; that leads to too much 
coupling between the commands.

I'm sure one could reorganize the overall config so that the first 
chain ended without being aborted, and then the commands which would 
have come after are instead on a separate chain behind a conditional 
Lookup command.  This isn't that hard to do, but I'm still not sure 
that I believe the class as implemented should *always* return the 
value of the looked up command.  Could we make a config value out of 
it?

Speaking of a conditional Lookup command, I still think it might be 
neat to implement that using instead of having to write Java code to 
evaluate simple conditions.  It could be like this:



This could also be used for lookups:

Note that these are run-time expressions, not simply config variables.
I'm just hesitant to add a new dependency on my own whim.  JEXL isn't 
very heavy (132 K) but I think people are keen on keeping Chain light 
too.

Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

jcl blog post

[Vic]

http://www.osnews.com/files/WinXP-security-guide.pdf
.V
--
Forums, Boards, Blogs and News in RiA 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: commons site broken.. shot myself in the foot!

[Kevin A. Burton]

Brett Porter wrote:
I'd suggest "maven clean xdoc site:sshdeploy" for now - it'll be much
faster and just get the essentials up there.
 

Sites up and working... I'll rework FeedParser to not extend the 
commons-build and add all the essentials.

Sorry for the glitch guys! 

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: commons site broken.. shot myself in the foot!

[Brett Porter]

Brett Porter wrote:

>Yes, especially if it differs from the sandbox. I'll fix it. I did point
>this out in my other email before this happened...
>  
>
The sandbox is like that too, and it is necessary to build the base part
of the site, so I won't change it.

It's not wise to inherit the same files you use as a master build - the
site should probably be a different subdirectory to the parent, but a
longer term strategy can be looked at now. For now, you should be able
to copy the siteDirectory from commons-lang - it uses an expression to
make sure it is correct.

- Brett


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: commons site broken.. shot myself in the foot!

[Brett Porter]

Kevin A. Burton wrote:

> Kevin A. Burton wrote:
>
>> Crap...
>>
>> I just shot myself in the foot.  Anyone care to help?
>>
>> I pushed to the wrong directory and now
>
>
> More on this subject btw:
>
> the  in commons-build is
>
> /www/jakarta.apache.org/commons
>
> Which is the worst setting right?  

Yes, especially if it differs from the sandbox. I'll fix it. I did point
this out in my other email before this happened...

> I think the problem is that I extended the commons-build/project.xml
> like I did when I was in the sandbox thinking this was the correct
> approach.  Guess I was wrong.
>
> It looks like httpclient doesn't do this (to pick a random sample).
>
> I'm trying to get a new version of the site up (because I feel really
> guilty about breaking it) but I can't find instructions and:
>
> 1. in commons-build "maven site" is taking FOREVER.. ug. It's stuck
> checking a bunch of links right now!
>
> 2. Whats up with the commons-site-deploy goal in maven.xml?   which
> one should I use?

I truly don't know, because I'm not familiar with the commons-build. It
should just be site:deploy - so hopefully that can get cleared up later.

I'd suggest "maven clean xdoc site:sshdeploy" for now - it'll be much
faster and just get the essentials up there.

- Brett


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: commons site broken.. shot myself in the foot!

[Kevin A. Burton]

Kevin A. Burton wrote:
Crap...
I just shot myself in the foot.  Anyone care to help?
I pushed to the wrong directory and now
More on this subject btw:
the  in commons-build is
/www/jakarta.apache.org/commons
Which is the worst setting right?  I think the problem is that I 
extended the commons-build/project.xml like I did when I was in the 
sandbox thinking this was the correct approach.  Guess I was wrong.

It looks like httpclient doesn't do this (to pick a random sample).
I'm trying to get a new version of the site up (because I feel really 
guilty about breaking it) but I can't find instructions and:

1. in commons-build "maven site" is taking FOREVER.. ug. It's stuck 
checking a bunch of links right now!

2. Whats up with the commons-site-deploy goal in maven.xml?   which one 
should I use?

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]

commons site broken.. shot myself in the foot!

[Kevin A. Burton]

Crap...
I just shot myself in the foot.  Anyone care to help?
I pushed to the wrong directory and now
http://jakarta.apache.org/commons/
is the feedparser documentation.
Can anyone help me regen it?
Maven is confusing...
  siteAddress = jakarta.apache.org
  siteDirectory = /www/jakarta.apache.org/commons
I thought that siteDirectory was the root and that it would end up in
/www/jakarta.apache.org/commons/feedparser
But I was wrong...
Anyway... I'll fix this on my end and I'll check the wiki to see if I 
can fix the site before someone replies flaming me!

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: [feedparser] maven site:sshdeploy gives chmod errors

[Brett Porter]

The tar uploaded is only 45 bits long. Did you run site before 
site:sshdeploy?

I think the siteDirectory should be 
/www/jakarta.apache.org/commons/feedparser, not just /commons - that 
will stop the attempt to chmod dbcp which must have bad group write 
permissions.

- Brett
Kevin A. Burton wrote:
Kevin A. Burton wrote:
I'm trying to push out a new version of the FeedParser site at
http://jakarta.apache.org/commons/feedparser/
Instead of the commons/sandbox URL.
Oh... also... the above URL still 404s... :-/
I guess I'm doing something wrong ...
Kevin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [feedparser] maven site:sshdeploy gives chmod errors

[Kevin A. Burton]

Kevin A. Burton wrote:
I'm trying to push out a new version of the FeedParser site at
http://jakarta.apache.org/commons/feedparser/
Instead of the commons/sandbox URL.
Oh... also... the above URL still 404s... :-/
I guess I'm doing something wrong ...
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]

[feedparser] maven site:sshdeploy gives chmod errors

[Kevin A. Burton]

I'm trying to push out a new version of the FeedParser site at
http://jakarta.apache.org/commons/feedparser/
Instead of the commons/sandbox URL.
But I get this error:

site:sshdeploy:
[echo]
  siteAddress = jakarta.apache.org
  siteDirectory = /www/jakarta.apache.org/commons
  siteUser = burton

[tar] Building tar: 
/usr/home/burton/projects/feedparser/target/commons-feedparser-0.5-beta-site.tar
[gzip] Building: 
/usr/home/burton/projects/feedparser/target/commons-feedparser-0.5-beta-site.tar.gz
[delete] Deleting: 
/usr/home/burton/projects/feedparser/target/commons-feedparser-0.5-beta-site.tar
[exec] gunzip: commons-feedparser-0.5-beta-site.tar already 
exists; not overwritten
[exec] chmod: dbcp/style/project-colburne.css: Operation not permitted
[exec] chmod: dbcp/style/maven-classic.css: Operation not permitted
[exec] chmod: dbcp/style/maven-base.css: Operation not permitted
[exec] chmod: dbcp/style/project.css: Operation not permitted
[exec] chmod: dbcp/style/maven-theme.css: Operation not permitted
[exec] chmod: dbcp/images/collapsed.gif: Operation not permitted
[exec] chmod: dbcp/images/external-classic.png: Operation not 
permitted

But it says build successful.
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]

svn commit: r153967 - jakarta/commons/proper/feedparser/trunk/project.xml

[burton]

Author: burton
Date: Tue Feb 15 14:22:32 2005
New Revision: 153967

URL: http://svn.apache.org/viewcvs?view=rev&rev=153967
Log:
now extending commons proper projects

Modified:
jakarta/commons/proper/feedparser/trunk/project.xml

Modified: jakarta/commons/proper/feedparser/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/feedparser/trunk/project.xml?view=diff&r1=153966&r2=153967
==
--- jakarta/commons/proper/feedparser/trunk/project.xml (original)
+++ jakarta/commons/proper/feedparser/trunk/project.xml Tue Feb 15 14:22:32 2005
@@ -1,7 +1,7 @@
 
 
 
-../commons-build/sandbox-project.xml
+../commons-build/project.xml
 
 Commons FeedParser
 
@@ -9,7 +9,7 @@
 
 /images/feedparser-logo-white.png
 
-http://jakarta.apache.org/commons/sandbox/feedparser/
+http://jakarta.apache.org/commons/feedparser/
 
 2004
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r153966 - in jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/network: NetworkException.java ResourceRequestFactory.java

[burton]

Author: burton
Date: Tue Feb 15 14:12:44 2005
New Revision: 153966

URL: http://svn.apache.org/viewcvs?view=rev&rev=153966
Log:
use a smarter cache policy for DNS requests

Modified:

jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/network/NetworkException.java

jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/network/ResourceRequestFactory.java

Modified: 
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/network/NetworkException.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/network/NetworkException.java?view=diff&r1=153965&r2=153966
==
--- 
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/network/NetworkException.java
 (original)
+++ 
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/network/NetworkException.java
 Tue Feb 15 14:12:44 2005
@@ -19,6 +19,8 @@
 import java.io.IOException;
 import java.net.*;
 
+import org.apache.log4j.*;
+
 /**
  * 
  * @author mailto:[EMAIL PROTECTED]">Kevin A. Burton
@@ -26,6 +28,8 @@
  */
 public class NetworkException extends IOException {
 
+private static Logger log = Logger.getLogger( NetworkException.class );
+
 private ResourceRequest request = null;
 
 public Exception e = null;
@@ -136,8 +140,17 @@
 int begin = "HTTP/1.1 ".length();
 int offset = "200".length();
 int end = begin + offset;
-
-responseCode = Integer.parseInt( status.substring( begin, end ) );
+
+try {
+
+responseCode = Integer.parseInt( status.substring( begin, end 
) );
+
+} catch ( NumberFormatException e ) {
+
+log.warn( "Unable to parse response code in header: " + status 
);
+return -1;
+
+}
 
 } 
 

Modified: 
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/network/ResourceRequestFactory.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/network/ResourceRequestFactory.java?view=diff&r1=153965&r2=153966
==
--- 
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/network/ResourceRequestFactory.java
 (original)
+++ 
jakarta/commons/proper/feedparser/trunk/src/java/org/apache/commons/feedparser/network/ResourceRequestFactory.java
 Tue Feb 15 14:12:44 2005
@@ -27,7 +27,7 @@
  * URL.
  *
  * @author mailto:[EMAIL PROTECTED]">Kevin A. Burton
- * @version $Id: ResourceRequestFactory.java,v 1.2 2005/01/27 07:15:50 burton 
Exp $
+ * @version $Id$
  */
 public class ResourceRequestFactory {
 
@@ -48,8 +48,8 @@
  * 
  * A value of -1 indicates "cache forever".
  */
-public static int NETWORKADDRESS_CACHE_TTL = 5 * 60 * 1000;
-
+public static int NETWORKADDRESS_CACHE_TTL = 5 * 60;
+
 /**
  * These properties specify the default connect and read timeout (resp.) 
for
  * the protocol handler used by java.net.URLConnection.
@@ -210,6 +210,9 @@
 System.setProperty( "sun.net.inetaddr.ttl",
 Integer.toString( NETWORKADDRESS_CACHE_TTL ) );
 
+System.setProperty( "networkaddress.cache.ttl",
+Integer.toString( NETWORKADDRESS_CACHE_TTL ) );
+
 System.setProperty( "sun.net.client.defaultReadTimeout",
 Integer.toString( DEFAULT_READ_TIMEOUT ) );
 
@@ -218,7 +221,7 @@
 
 System.setProperty( "http.maxRedirects",
 Integer.toString( DEFAULT_MAX_REDIRECTS ) );
-
+
 if ( schemeMap == null ) {
 
 schemeMap = new HashMap();



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: a commons-lang patch.

[robert burrell donkin]

On Tue, 2005-02-15 at 08:22, Simon Kitching wrote:
> On Mon, 2005-02-14 at 16:44 -0700, Travis Stevens wrote:
> > I just added a Bugzilla entry which includes a patch.  What do I need to 
> > do to persuade someone to look at the bug and apply the patch?
> > 
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=33574
> > 
> 
> Just creating the bugzilla entry sends an email to this list. If there
> is no response, then a polite reminder every week or two is probably
> acceptable.

+1

it would be a good idea to prefix any mail with a [lang] prefix. most
committers and developers use filtering and posters are asked to prefix
with the name of their component.

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] External and Internal API's

[David Graham]

Eclipse also has a special way of sharing classes with other plugins.  You
can prevent outside plugins from using internal packages by tweaking the
export definition in plugin.xml:

  

  


That seems to be the primary benefit to adding an "internal" package
prefix.  Without the extra functionality provided by Eclipse it's only use
is for documentation.  In that case, you may as well just add a note to
the javadoc like, "This class is not part of the public API" instead of
mangling the package names.

David


--- Mark Diggory <[EMAIL PROTECTED]> wrote:

> I've been working with the Eclipse SDK quite a bit lately, Eclipse has a
> coding standard where they divide the API up into "external" and
> "internal" API's. Internal API's are subject to change, while External
> API's are more stable and regulated. The division of these API's is
> usually:
> 
> External API:
> org.foo.bar
> 
> Internal API:
> org.foo.bar.internal
> 
> Theses are similar to "Interface and Implementation" but without the
> association to OO Class/Interface terms already having "specific
> definitions".
> 
> I think this is very "savvy" concept for managing the codebase. I wonder
> if this is an idea that would be of benefit if implemented in the
> commons? Is this approach already used in some commons components?
> 
> -Mark





__ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17682] - [cli] HelpFormatter does not wrap lines correctly after the second line

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=17682





--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 19:44 ---
It can be fix by changing line 425 for HelpFormatter.java from
 pos = findWrapPos( text, width, nextLineTabStop );
to
 pos = findWrapPos( text, width-nextLineTabStop, nextLineTabStop );

Explanation:
 Start from second lines onwards the width of the line should excludes the
leading spaces, as shonw below
 xx.width
   .width - nextLineTabStop
   .witdh - nextLineTabStop

-- 
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 33167] - [dbcp] Individual connection close method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33167





--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 19:17 ---
I have added your method locally and ran the testcase but if fails.
The assertTrue(c.isClosed()); fails because the connection is still open. This
is normal, the pool is closed but the connection remains open.

After I removed the assert I got the following stacktrace:
org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info
from pool
at
org.apache.commons.dbcp.datasources.PerUserPoolDataSource.getPooledConnectionAndInfo(PerUserPoolDataSource.java:396)
at
org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:631)
at
org.apache.commons.dbcp.datasources.TestPerUserPoolDataSource.testClosing1(TestPerUserPoolDataSource.java:567)
...
Caused by: java.lang.IllegalStateException: Pool not open
at org.apache.commons.pool.BaseObjectPool.assertOpen(BaseObjectPool.java:78)
at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:776)
at
org.apache.commons.dbcp.datasources.PerUserPoolDataSource.getPooledConnectionAndInfo(PerUserPoolDataSource.java:393)
... 17 more

This is what I expected, the closed pool cannot be reused. It must be
unregistered in a way that getPooledConnectionAndInfo() will create a new pool
for the user. (simply removing it from the HashMap?) 

-- 
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] External and Internal API's

[Mark Diggory]

I've been working with the Eclipse SDK quite a bit lately, Eclipse has a
coding standard where they divide the API up into "external" and
"internal" API's. Internal API's are subject to change, while External
API's are more stable and regulated. The division of these API's is usually:
External API:
org.foo.bar
Internal API:
org.foo.bar.internal
Theses are similar to "Interface and Implementation" but without the
association to OO Class/Interface terms already having "specific
definitions".
I think this is very "savvy" concept for managing the codebase. I wonder
if this is an idea that would be of benefit if implemented in the
commons? Is this approach already used in some commons components?
-Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33591] - [DBCP] Connection leak in PoolableConnection.close() (Oracle 10g driver)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33591





--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 18:49 ---
You want to invalidate the pooled connection if the underlying connection is
closed. Try the following PoolableConnection.close() method.

 public synchronized void close() throws SQLException {
try {
if (_conn.isClosed()) {
// underlying connection closed behind our back
try {
_pool.invalidateObject(this);
} catch (Exception ie) {
// DO NOTHING
}
throw new SQLException("Cannot close connection (underlying
connection already closed)");
}
} catch (SQLException e) {
try {
_pool.invalidateObject(this);
} catch (Exception ie) {
// DO NOTHING the original exception will be rethrown
}
throw new SQLNestedException("Cannot close connection (isClosed
check failed)", e);
}
if (_closed) {
throw new SQLException("Already closed.");
} else {
try {
_pool.returnObject(this);
} catch(SQLException e) {
throw e;
} catch(RuntimeException e) {
throw e;
} catch(Exception e) {
throw new SQLNestedException("Cannot close connection (return to
pool failed)", e);
}
}
}


-- 
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 33591] New: - [DBCP] Connection leak in PoolableConnection.close() (Oracle 10g driver)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33591

   Summary: [DBCP] Connection leak in PoolableConnection.close()
(Oracle 10g driver)
   Product: Commons
   Version: 1.2 Final
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Dbcp
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Mail from Hugh Winkler on commons-dev (15-2-2005)
--
PoolableConnection.close() does logic equivalent to :

  if ( isClosed()){
  throw new SQLException(.);
  } else {
  _pool.returnObject(this);
  }

The isClosed() method is that of ancestor DelegatingConnection, and it does:
  if(_closed || _conn.isClosed()) {
  return true;
  }
  return false;


Now nothing prevents the underlying connection from closing itself; that's
why isClosed() checks _conn.isClosed() -- "did you close yourself while I
wasn't looking?" But in that case PoolableConnection never calls
_pool.returnObject(). 

I've got a query in Oracle 10g that causes Oracle's connection to close
itself: the famous "end of file on connection" message causes the connection
to enter the closed state. Doesn't take long to exhaust the pool.

I think the logic we want in PoolableConnection.close() is like so:



  if ( _closed ){ // really ask, did *we* close the connection already
  throw new SQLException(.);
  } else {
  _pool.returnObject(this);
  }

If I've got some logic wrong please stop me before I deploy that change
here!

-- 
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] External and Internal API's

[Mark Diggory]

I've been working with the Eclipse SDK quite a bit lately, Eclipse has a 
coding standard where they divide the API up into "external" and 
"internal" API's. Internal API's are subject to change, while External 
API's are more stable and regulated. The division of these API's is usually:

External API:
org.foo.bar
Internal API:
org.foo.bar.internal
Theses are similar to "Interface and Implementation" but without the 
association to OO Class/Interface terms already having "specific 
definitions".

I think this is very "savvy" concept for managing the codebase. I wonder 
if this is an idea that would be of benefit if implemented in the 
commons? Is this approach already used in some commons components?

-Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: a commons-lang patch.

[Gary Gregory]

Also, providing a unit test patch with a test is, IMHO, essential. I
like to apply the unit test patch, watch the test fail, apply the patch,
watch the test pass.

Cheers,
Gary

-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 15, 2005 5:26 AM
To: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re: a commons-lang patch.

On Tue, 15 Feb 2005 21:22:45 +1300, Simon Kitching
<[EMAIL PROTECTED]> wrote:
> On Mon, 2005-02-14 at 16:44 -0700, Travis Stevens wrote:
> > I just added a Bugzilla entry which includes a patch.  What do I
need to
> > do to persuade someone to look at the bug and apply the patch?
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=33574
> >
> 
> Just creating the bugzilla entry sends an email to this list. If there
> is no response, then a polite reminder every week or two is probably
> acceptable.

Acknowledging the bugzilla issue. :)

Will see if anyone has thoughts on it before we release.

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]

[Jakarta Commons Wiki] New: Transaction

[commons-dev]

   Date: 2005-02-15T08:13:02
   Editor: RajThangaraj
   Wiki: Jakarta Commons Wiki
   Page: Transaction
   URL: http://wiki.apache.org/jakarta-commons/Transaction

   Name of the output file in file transaction

New Page:

I wrote the following code to create temp.txt in the stored directory
But some file with a diff name(aW5kZXgxLnR4dA%3D%3D) gets created. Does someone 
know how to specify the name of the output file

Logger logger = Logger.getLogger("d:\\Raj\\test.log");
LoggerFacade loggerFacade = new Log4jLogger(logger);
FileResourceManager fileResourceManager = 
   new FileResourceManager("D:\\Raj\\stored", "D:\\Raj\\working", 
true, loggerFacade );
fileResourceManager.start();
String txId = fileResourceManager.generatedUniqueTxId();
System.out.println("Working Directory : " + 
fileResourceManager.getWorkDir());
System.out.println("Store Directory : " + 
fileResourceManager.getStoreDir());
System.out.println("Transaction Identifier : " + txId);
fileResourceManager.startTransaction(txId);
FileInputStream fis = new FileInputStream("D:\\Raj\\stored\\index.txt");
byte[] bt1 = new byte[100];
fis.read(bt1);
fis.close();
OutputStream os = fileResourceManager.writeResource(txId, "temp.txt");
os.write(bt1);
fileResourceManager.commitTransaction(txId);

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33550] - [digester] Add support for CallMethodRule with target offset in xml rules

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33550





--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 16:33 ---
Simon, if you're talking about this:
   StringTokenizer tokens = new StringTokenizer(paramTypesAttr, " \t\n\r,");
I didn't add it, I just moved it out to a private method to avoid duplicating
the code.



-- 
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]

AW: [i18n] man available

[Daniel Florey]

Hi Woody,
I'm currently trying to improve the maven environment, so that releases and
tests can easily be done.
My goal is to complete the component in the actual state in order to build a
usable release as soon as possible.
I've already had a look at your proposed changes. I'd like to include some
changes into the current version (LocalizedRuntimeException), but I'm not
sure with the ConfigManager. This one introduces a lot of complexity.
In order to keep the i18n-component very simple my suggestions would be to
keep only one MessageManager with static methods and advice the user to use
unique message keys (comparable to java package names). This should avoid
trouble when using multiple applications. Agreed?
Next steps are to remove misleading methods (as we discussed earlier) and to
complete the javadocs and provide some more tutorials. This is the part
where help would be very much appreciated ;-)

Cheers,
Daniel

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von [EMAIL PROTECTED]
> Gesendet: Dienstag, 15. Februar 2005 15:51
> An: Jakarta Commons Developers List
> Betreff: [i18n] man available
> 
> Hi Daniel,
> Can I 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]

[i18n] man available

[agodinhost]

Hi Daniel,
Can I help?

Woody


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r153937 - jakarta/commons/sandbox/i18n/trunk/project.properties jakarta/commons/sandbox/i18n/trunk/project.xml

[dflorey]

Author: dflorey
Date: Tue Feb 15 06:38:33 2005
New Revision: 153937

URL: http://svn.apache.org/viewcvs?view=rev&rev=153937
Log:
Added JUnit-Test infrastructure

Modified:
jakarta/commons/sandbox/i18n/trunk/project.properties
jakarta/commons/sandbox/i18n/trunk/project.xml

Modified: jakarta/commons/sandbox/i18n/trunk/project.properties
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/project.properties?view=diff&r1=153936&r2=153937
==
--- jakarta/commons/sandbox/i18n/trunk/project.properties (original)
+++ jakarta/commons/sandbox/i18n/trunk/project.properties Tue Feb 15 06:38:33 
2005
@@ -27,8 +27,3 @@
 # M A V E N  J A R  O V E R R I D E
 # 
 maven.jar.override = on
-
-# 
-# Jars set explicity by path.
-# 
-maven.jar.commons-xmlio = ${basedir}/lib/commons-xmlio-0.1pre.jar

Modified: jakarta/commons/sandbox/i18n/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/project.xml?view=diff&r1=153936&r2=153937
==
--- jakarta/commons/sandbox/i18n/trunk/project.xml (original)
+++ jakarta/commons/sandbox/i18n/trunk/project.xml Tue Feb 15 06:38:33 2005
@@ -32,7 +32,7 @@
   Commons I18n
   Internationalization package
 
-  0.2
+  0.3
   

1
@@ -73,15 +73,25 @@
   
 
   
-
-  commons-xmlio
-  0.1pre
-
   
 
   
 commons-dev@jakarta.apache.org
 src/java
+src/test
+
+
+
+  
+**/*Test.java
+  
+
+  
+${basedir}/src/test
+  
+
+
+
   
 
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: a commons-lang patch.

[Henri Yandell]

On Tue, 15 Feb 2005 21:22:45 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-02-14 at 16:44 -0700, Travis Stevens wrote:
> > I just added a Bugzilla entry which includes a patch.  What do I need to
> > do to persuade someone to look at the bug and apply the patch?
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=33574
> >
> 
> Just creating the bugzilla entry sends an email to this list. If there
> is no response, then a polite reminder every week or two is probably
> acceptable.

Acknowledging the bugzilla issue. :)

Will see if anyone has thoughts on it before we release.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JELLY-201) NotAvailableTag

[Nacho G. Mac Dowell (JIRA)]

 [ 
http://issues.apache.org/jira/browse/JELLY-201?page=comments#action_59199 ]
 
Nacho G. Mac Dowell commented on JELLY-201:
---

Hi, what I was looking for is the negative version of util:available. If 
ant:available exists, maybe util:available is not recommended? The 
util:available tag accepts a file and an uri. I suppose the ant:available 
doesn't provide the same functionality? The thing is that there are quite a few 
places I've seen where mkdir gets called regardless if the directory exists. 
While the overhead is not a problem, I think that it would improve readability 
of jelly scripts.

Thanks,

Nacho

> NotAvailableTag
> ---
>
>  Key: JELLY-201
>  URL: http://issues.apache.org/jira/browse/JELLY-201
>  Project: jelly
> Type: Improvement
>   Components: taglib.util
> Reporter: Nacho G. Mac Dowell
>  Attachments: NotAvailableTag.patch, NotAvailableTag.patch, 
> UtilTagLibrary.patch, suite.jelly.patch
>
> It would be useful to have a NotAvailableTag. Even though (for example) mkdir 
> can be called each time without any overhead, sometimes the code would 
> improve readability with the use of this tag.
> Solution:
> Create a method boolean isAvailable() in AvailableTag which does all the job 
> and have the NotAvailableTag extend AvailableTag and in the doTag method:
> if (!isAvailable()) {
> invokeBody(output);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33580] - [daemon] runs as multiple instances, does not use PID file logic

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33580


[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||33581
  nThis||




-- 
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 33581] - [daemon] Making jsvc multiple instances enabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33581


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
  BugsThisDependsOn||33580




--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 11:18 ---
Re: "Point 8) might even be better addressed by the jsvc executable."

I agree. That would help to get jsvc to handle a single instance reliably.

That would be nice: Single instance jsvc refuses to start a duplicate instance,
and with this bug solved, multi instance jsvc refuses to run duplicates per each
of true multiple instances.

-- 
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]

[functor] status evolution ?

[Marc DEXET]

Hi everybody and especially functor folks.

I've a question about functor status.
I know it's still in sandbox, but how far is project from going out of
sandbox ?
I know too API can still change, but how functor folks would qualify project
statibility ?
There is a futur promotion vote planified ?
Thanks.


-- 
Marc DeXeT
CNRS

DO NOT REPLY [Bug 20903] - [digester] CallFactoryMethodRule

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20903





--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 10:18 ---
And by the way, is that diff against the CVS version? There's a couple of
problems when applying the patch, and I think that's the cause. I can probably
resolve them but if you are able to create a diff against the latest subversion
copy of this file that would be appreciated.

-- 
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 33561] - [logging] Need Log.close method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33561





--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 10:14 ---
Thanks to both of you - I'll try the ideas in the FAQ entry.

-- 
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]

[jira] Commented: (JELLY-201) NotAvailableTag

[Paul Libbrecht (JIRA)]

 [ 
http://issues.apache.org/jira/browse/JELLY-201?page=comments#action_59193 ]
 
Paul Libbrecht commented on JELLY-201:
--

Do I understand that you are wishing a negative version of ant:available ?
Why not in ant taglib ? Or... even... in ant itself ?

paul

> NotAvailableTag
> ---
>
>  Key: JELLY-201
>  URL: http://issues.apache.org/jira/browse/JELLY-201
>  Project: jelly
> Type: Improvement
>   Components: taglib.util
> Reporter: Nacho G. Mac Dowell
>  Attachments: NotAvailableTag.patch, NotAvailableTag.patch, 
> UtilTagLibrary.patch, suite.jelly.patch
>
> It would be useful to have a NotAvailableTag. Even though (for example) mkdir 
> can be called each time without any overhead, sometimes the code would 
> improve readability with the use of this tag.
> Solution:
> Create a method boolean isAvailable() in AvailableTag which does all the job 
> and have the NotAvailableTag extend AvailableTag and in the doTag method:
> if (!isAvailable()) {
> invokeBody(output);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33581] - [daemon] Making jsvc multiple instances enabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33581





--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 10:09 ---
Please see http://www.junlu.com/msg/139408.html for an example wrapper script
which can set $CATALINA_BASE for an instance.

-- 
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 33581] - [daemon] Making jsvc multiple instances enabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33581


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Making jsvc multiple|[daemon] Making jsvc
   |instances enabled   |multiple instances enabled




-- 
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 33581] New: - Making jsvc multiple instances enabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33581

   Summary: Making jsvc multiple instances enabled
   Product: Commons
   Version: unspecified
  Platform: All
   URL: http://miti.sourceforge.net
OS/Version: All
Status: NEW
  Severity: major
  Priority: P2
 Component: Daemon
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


This bug is closely related to 33580. The Tomcat5.sh script bundled with jsvc is
not capable of handling multiple instances. According to
http://miti.sourceforge.net this script should be adapted in the following ways:
1) Introduce a variable $INSTANCE_NAME which is unique
2) Introduce a variable $CATALINA_BASE_DIRS which represents a directory where
all the instances will be located (e.g. /usr/local/tomcat/instances)
3) Set $CATALINA_BASE in the script (or require the shell variable to be
non-zero) to  $CATALINA_BASE/$INSTANCE_NAME
4) Introduce a parameter TMP_DIR=$CATALINA_BASE/$INSTANCE_NAME/temp
5) Adapt the parameter in the jsvc call: "-Djava.io.tmpdir=$TMP_DIR \" 
6) Introduce a parameter PIDFILE=/var/run/jsvc-$INSTANCE_NAME.pid
7) Add a line with "-pidfile $PIDFILE \" to the parameters for the jsvc call in
the start section
8) Change the stop case to
stop)
#
# Stop Tomcat
#
PID=`cat $PIDFILE`
if [ -n $PID ]
then
   kill $PID
   rm $PIDFILE
fi
;;

If the installation is for a single instance, $CATALINA_BASE will be empty and
therefore can be set to $CATALINA_HOME.
Point 8) might even be better addressed by the jsvc executable.

-- 
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 33550] - [digester] Add support for CallMethodRule with target offset in xml rules

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33550





--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 10:01 ---
Hi Wendy,

Is this thing about having a string containing a comma-separated list of types
an established xmlrules convention, or is this patch the first time this has
been done?

-- 
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 33561] - [logging] Need Log.close method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33561





--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 09:49 ---
I've added an entry to the logging FAQ on this:
  http://wiki.apache.org/jakarta-commons/Logging/FrequentlyAskedQuestions

-- 
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]

[Jakarta Commons Wiki] Updated: Logging/FrequentlyAskedQuestions

[commons-dev]

   Date: 2005-02-15T00:48:06
   Editor: SimonKitching
   Wiki: Jakarta Commons Wiki
   Page: Logging/FrequentlyAskedQuestions
   URL: http://wiki.apache.org/jakarta-commons/Logging/FrequentlyAskedQuestions

   no comment

Change Log:

--
@@ -33,6 +33,30 @@
 
 For more information see http://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]&msgNo=5737
 
+
+== How can I close loggers when using Commons-Logging? ==
+
+You can't. 
+
+Commons-logging is a wrapper intended to isolate code from the underlying 
logging library when log calls are being made.
+In particular, it is intended to allow library code to contain logging calls 
without caring about what concrete log implementation
+is being used by the wider application the library is deployed within.
+
+It is not intended to isolate applications from the logging-specific details 
of initialization and termination.
+
+The fact that some logging implementations auto-configure themselves when 
first used doesn't mean that commons-logging guarantees to
+do this in all cases, nor that the default initialization behaviour of the 
concrete logging libraries is appropriate under all circumstances.
+
+And the fact that some logging libraries (or subsets thereof) terminate nicely 
without requiring library-specific shutdown code doesn't mean that
+all libraries will work correctly in this manner, nor that commons-logging 
will isolate code from this task.
+
+In short: when necessary, obtain a reference to the actual underlying log 
implementation and use library-specific calls to initialise
+and terminate as required. 
+
+If you need a reference to the underlying object for a particular 
commons-logging Log object in order to perform initialisation or
+termination, then in most cases the org.apache.commons.logging.Log class can 
be downcast to a concrete type that then has a
+"getLogger" method that returns the real underlying object.
+
 
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33574] - [lang] unbalanced ReflectionToStringBuilder

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33574


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Linux   |All
   Platform|PC  |All
Summary|unbalanced  |[lang] unbalanced
   |ReflectionToStringBuilder   |ReflectionToStringBuilder




-- 
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]

[jira] Commented: (JELLY-201) NotAvailableTag

[Nacho G. Mac Dowell (JIRA)]

 [ 
http://issues.apache.org/jira/browse/JELLY-201?page=comments#action_59192 ]
 
Nacho G. Mac Dowell commented on JELLY-201:
---

Only attachments 2 and 4 should be used. I don't know why the order went weird 
as it should be attachments 3 and 4...

> NotAvailableTag
> ---
>
>  Key: JELLY-201
>  URL: http://issues.apache.org/jira/browse/JELLY-201
>  Project: jelly
> Type: Improvement
>   Components: taglib.util
> Reporter: Nacho G. Mac Dowell
>  Attachments: NotAvailableTag.patch, NotAvailableTag.patch, 
> UtilTagLibrary.patch, suite.jelly.patch
>
> It would be useful to have a NotAvailableTag. Even though (for example) mkdir 
> can be called each time without any overhead, sometimes the code would 
> improve readability with the use of this tag.
> Solution:
> Create a method boolean isAvailable() in AvailableTag which does all the job 
> and have the NotAvailableTag extend AvailableTag and in the doTag method:
> if (!isAvailable()) {
> invokeBody(output);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JELLY-201) NotAvailableTag

[Nacho G. Mac Dowell (JIRA)]

 [ http://issues.apache.org/jira/browse/JELLY-201?page=history ]

Nacho G. Mac Dowell updated JELLY-201:
--

Attachment: suite.jelly.patch

Test cases for NotAvailableTag.

> NotAvailableTag
> ---
>
>  Key: JELLY-201
>  URL: http://issues.apache.org/jira/browse/JELLY-201
>  Project: jelly
> Type: Improvement
>   Components: taglib.util
> Reporter: Nacho G. Mac Dowell
>  Attachments: NotAvailableTag.patch, NotAvailableTag.patch, 
> UtilTagLibrary.patch, suite.jelly.patch
>
> It would be useful to have a NotAvailableTag. Even though (for example) mkdir 
> can be called each time without any overhead, sometimes the code would 
> improve readability with the use of this tag.
> Solution:
> Create a method boolean isAvailable() in AvailableTag which does all the job 
> and have the NotAvailableTag extend AvailableTag and in the doTag method:
> if (!isAvailable()) {
> invokeBody(output);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JELLY-201) NotAvailableTag

[Nacho G. Mac Dowell (JIRA)]

 [ http://issues.apache.org/jira/browse/JELLY-201?page=history ]

Nacho G. Mac Dowell updated JELLY-201:
--

Attachment: NotAvailableTag.patch

Previous NotAvailableTag patch doesn't work... Too early in the morning...
The new patch now includes modifications to AvailableTag, creation of 
NotAvailableTag and inclusion of NotAVailableTag in UtilTagLibrary. So both 
previous patches are useless. Tests will be included in next patch.

> NotAvailableTag
> ---
>
>  Key: JELLY-201
>  URL: http://issues.apache.org/jira/browse/JELLY-201
>  Project: jelly
> Type: Improvement
>   Components: taglib.util
> Reporter: Nacho G. Mac Dowell
>  Attachments: NotAvailableTag.patch, NotAvailableTag.patch, 
> UtilTagLibrary.patch
>
> It would be useful to have a NotAvailableTag. Even though (for example) mkdir 
> can be called each time without any overhead, sometimes the code would 
> improve readability with the use of this tag.
> Solution:
> Create a method boolean isAvailable() in AvailableTag which does all the job 
> and have the NotAvailableTag extend AvailableTag and in the doTag method:
> if (!isAvailable()) {
> invokeBody(output);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33580] New: - [daemon] runs as multiple instances, does not use PID file logic

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33580

   Summary: [daemon] runs as multiple instances, does not use PID
file logic
   Product: Commons
   Version: 1.0 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: Daemon
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


jsvc writes its own pid file but it appears that it does not have a logic that
secures its own integrity.
Multiple duplicate processes can be created simply by issuing the same jsvc
command multiple times. The created processes cannot be killed using the pppid
file for obvious reasons.

1) jsvc should terminate prematurely if it finds its own pid file.

2) jsvc should delete its own pid file when killed.

If 1) and 2) are not acceptable because (hypothetically, because I don't know
the specifications) the specifications require that the caller incorporates this
logic, then jsvc should not write a pid file.

Why do i think so?

Depending on implementation, the risk of malfunctioning is much higher if the
pid file is managed across different execution environments.
One major reason is that these environments are not usually maintained by the
same person.

I guess one might try to get a file system lock on the pid file before launching
the java program.

Please excuse my ignorance if I am misinterpreting the daemon functionality in
any way. I have tried to get responses from 3 relevant mailing lists,
commons-user, commons-dev and tomcat-user, but nobody replied.
I am not a Linux programmer and I would not be surprised if this kind of
programming problem (uniqueness of id'd processes on one machine) has a standard
solution under Linux.

Because

-- 
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]

[jira] Updated: (JELLY-201) NotAvailableTag

[Nacho G. Mac Dowell (JIRA)]

 [ http://issues.apache.org/jira/browse/JELLY-201?page=history ]

Nacho G. Mac Dowell updated JELLY-201:
--

Attachment: UtilTagLibrary.patch

Included NotAvailableTag in UtilTagLibrary for testing purposes

> NotAvailableTag
> ---
>
>  Key: JELLY-201
>  URL: http://issues.apache.org/jira/browse/JELLY-201
>  Project: jelly
> Type: Improvement
>   Components: taglib.util
> Reporter: Nacho G. Mac Dowell
>  Attachments: NotAvailableTag.patch, UtilTagLibrary.patch
>
> It would be useful to have a NotAvailableTag. Even though (for example) mkdir 
> can be called each time without any overhead, sometimes the code would 
> improve readability with the use of this tag.
> Solution:
> Create a method boolean isAvailable() in AvailableTag which does all the job 
> and have the NotAvailableTag extend AvailableTag and in the doTag method:
> if (!isAvailable()) {
> invokeBody(output);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (JELLY-201) NotAvailableTag

[Nacho G. Mac Dowell (JIRA)]

NotAvailableTag
---

 Key: JELLY-201
 URL: http://issues.apache.org/jira/browse/JELLY-201
 Project: jelly
Type: Improvement
  Components: taglib.util  
Reporter: Nacho G. Mac Dowell


It would be useful to have a NotAvailableTag. Even though (for example) mkdir 
can be called each time without any overhead, sometimes the code would improve 
readability with the use of this tag.

Solution:

Create a method boolean isAvailable() in AvailableTag which does all the job 
and have the NotAvailableTag extend AvailableTag and in the doTag method:

if (!isAvailable()) {
invokeBody(output);
}



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: a commons-lang patch.

[Simon Kitching]

On Mon, 2005-02-14 at 16:44 -0700, Travis Stevens wrote:
> I just added a Bugzilla entry which includes a patch.  What do I need to 
> do to persuade someone to look at the bug and apply the patch?
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=33574
> 

Just creating the bugzilla entry sends an email to this list. If there
is no response, then a polite reminder every week or two is probably
acceptable.

However there's no way to "force" someone to look at the patch - nor is
there any need to, as you are of course free to use and redistribute
your patched version of lang.

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33554] - [launcher] Print targest instead of usage

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33554





--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 09:08 ---
Created an attachment (id=14286)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14286&action=view)
First version containing changes for discussion.

First version containing changes for discussion.

-- 
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]

[jira] Updated: (JELLY-201) NotAvailableTag

[Nacho G. Mac Dowell (JIRA)]

 [ http://issues.apache.org/jira/browse/JELLY-201?page=history ]

Nacho G. Mac Dowell updated JELLY-201:
--

Attachment: NotAvailableTag.patch

Updated AvailableTag and created NotAvailableTag

> NotAvailableTag
> ---
>
>  Key: JELLY-201
>  URL: http://issues.apache.org/jira/browse/JELLY-201
>  Project: jelly
> Type: Improvement
>   Components: taglib.util
> Reporter: Nacho G. Mac Dowell
>  Attachments: NotAvailableTag.patch, UtilTagLibrary.patch
>
> It would be useful to have a NotAvailableTag. Even though (for example) mkdir 
> can be called each time without any overhead, sometimes the code would 
> improve readability with the use of this tag.
> Solution:
> Create a method boolean isAvailable() in AvailableTag which does all the job 
> and have the NotAvailableTag extend AvailableTag and in the doTag method:
> if (!isAvailable()) {
> invokeBody(output);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]