mturk 2003/02/09 01:36:56
Modified:daemon/src/native/nt/procrun readme.txt
Log:
Added some examples.
Revision ChangesPath
1.3 +24 -4 jakarta-commons-sandbox/daemon/src/native/nt/procrun/readme.txt
Index: readme.txt
mturk 2003/02/09 01:38:54
Modified:daemon/src/native/nt/procrun procrun.h procrun.c
Log:
Added --Install option that allows to install the procrun from
any directory. This is used for installation programs, where
consoless procrunw can be used.
Revision ChangesPath
mturk 2003/02/09 01:41:18
Modified:daemon/src/native/nt/procrun/bin procrunw.exe procrun.exe
Log:
Binaries build with DevC++ 4.9.7.0
Revision ChangesPath
1.3 +76 -136
jakarta-commons-sandbox/daemon/src/native/nt/procrun/bin/procrunw.exe
Binary file
The FileUpload component has been stable for a while now, but available
only from nightly builds. It's time to create a milestone release
against which a final series of bug fixes and documentation updates can
occur before a FileUpload 1.0 Final release is created.
Therefore, I propose that
On Saturday, February 8, 2003, at 08:20 AM, [EMAIL PROTECTED] wrote:
Geir,
Geir Magnusson Jr. [EMAIL PROTECTED] wrote on 08/02/2003 10:22:47 AM:
Suggestion - might be nice to have a header in it, something like :
!--
build.xml generated by maven from project.xml version
VERSION
On Friday, February 7, 2003, at 06:32 PM, bob mcwhirter wrote:
Does jexl support div/mod? My experiments suggest not.
Or would you consider them not working to be a bug?
Yes. Will fix.
geir
-bob
On Fri, 7 Feb 2003, Geir Magnusson Jr. wrote:
Suggestion - might be nice to have a
On Saturday, February 8, 2003, at 10:20 PM, Martin Cooper wrote:
--
Vote: FileUpload 1.0 Beta 1 Release Plan
[X] +1 I am in favor of the release, and will help support it.
[ ] +0 I am in favor of the release, but am unable
--
Vote: FileUpload 1.0 Beta 1 Release Plan
[ ] +1 I am in favor of the release, and will help support it.
[X] +0 I am in favor of the release, but am unable to help support it.
[ ] -0 I am not in favor of the release.
On Saturday, February 8, 2003, at 08:16 PM, Leo Simons wrote:
James Strachan wrote:
Would it be acceptable
to add a getName() or something similar to the Log interface and the
implementations? That way, we can fully implement the avalon-framework
Logger contract on top of commons-logging.
+1.
mturk 2003/02/09 08:07:59
Added: daemon/src/native/nt/procrun/bin procrun.dll
Log:
DLL build using DevC++
Revision ChangesPath
1.1
jakarta-commons-sandbox/daemon/src/native/nt/procrun/bin/procrun.dll
Binary file
mturk 2003/02/09 08:08:40
Added: daemon/src/native/nt/procrun procrund.dev
Log:
DevC++ DLL project
Revision ChangesPath
1.1
jakarta-commons-sandbox/daemon/src/native/nt/procrun/procrund.dev
Index: procrund.dev
mturk 2003/02/09 08:11:23
Modified:daemon/src/native/nt/procrun procrun.vcproj procrun.h
procrun.c
Log:
Adde PROCRUN_WINDLL build and tree exported functions
for use in Installation programs.
1. InstallService Installs the service
2. UpdateService
Sounds a bit casual, but reasonable.
+0
Martin Cooper wrote:
On Sat, 8 Feb 2003, Jeffrey Dever wrote:
Just curious, if this is the first release build ever, should it not be
labeled Alpha1?
FileUpload has been in use by external customers such as Struts and
Turbine for some time now,
robert burrell donkin wrote:
On Saturday, February 8, 2003, at 08:16 PM, Leo Simons wrote:
James Strachan wrote:
Would it be acceptable
to add a getName() or something similar to the Log interface and the
implementations? That way, we can fully implement the avalon-framework
Logger contract
geirm 2003/02/09 12:17:56
Modified:jexl/src/java/org/apache/commons/jexl/parser ASTDivNode.java
ASTModNode.java
Log:
Make them work :)
Revision ChangesPath
1.2 +51 -13
geirm 2003/02/09 12:20:08
Modified:jexl/src/test/org/apache/commons/jexl JexlTest.java
Log:
added % and /
Revision ChangesPath
1.26 +43 -1
jakarta-commons/jexl/src/test/org/apache/commons/jexl/JexlTest.java
Index: JexlTest.java
Nicola Ken Barozzi wrote:
import org.apache.commons.logging.Log;
public class SomeService {
// container sets the logger to be used using IOC
public void setLog(Log log);
}
Is that what packages using Commons Logging do?
Every single package in Commons that uses CL uses the
Ryan Hoegg wrote:
Commons-logging-api.jar is 16K, which would increase our applet JAR size
by 60+%. That's not acceptable for a system level service like logging.
You can remove the jdk14 logging and the simple logger - and jar only
the interface and a dummy factory.
Costin
I'm still concerned about having public methods in HttpMethodBase that
are not in the HttpMethod interface. These two public interfaces
should not diverge. I had this same problem in a the past, where I
added a public method to the abstract class, and not the interface.
Then I saw user code
ContactOffice (www.contactoffice.com)
ContactOffice is a complete groupware solution ('Virtual office')
combining mail, calendar, storage, contacts, ...
We are using HTTPClient for various back-end tasks (inter-servers
communication, SMS transmission, ...).
Thank you a lot for this great
My thought was that people creating specific instances of HttpMethod
like PostMethod would be able to access the HeaderGroups. I still
would like to have the header groups available for subclasses though.
How would you feel about making these methods protected?
Protected would be fine.
I
Got it. Thanks.
Luc Claes wrote:
ContactOffice (www.contactoffice.com)
ContactOffice is a complete groupware solution ('Virtual office')
combining mail, calendar, storage, contacts, ...
We are using HTTPClient for various back-end tasks (inter-servers
communication, SMS transmission, ...).
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11218.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
23 matches
Mail list logo
