This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-02-04/commons-jelly-tags-html.html
Buildfile: build.xml
init:
[mkdir] Created dir:
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-02-04/commons-jelly-tags-fmt.html
Buildfile: build.xml
init:
[mkdir] Created dir:
+1
There's still a few patches that need to be applied to commons-sql from Tim
and John. Should we apply those before the move?
James
---
http://radio.weblogs.com/0112098/
- Original Message -
From: Jason van Zyl [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
+1
From: Martin Cooper [EMAIL PROTECTED]
On Mon, 3 Feb 2003, Jan Luehe wrote:
Robert,
(4) Initial Committers
The initial committers will be identical to those of the Standard
Taglib
project.
i'm unhappy with this since it implies that all current taglib
committers
will be
Hi,
I am new to JXPath but it looks great, thanks for
all your hard work. I have just been playing around with it a little as I would
like to use it in a new project that I am working on. I wanted to implement a
generic Factory to create objects and I ran into a small snag. I just wanted to
On Tue, 2003-02-04 at 05:43, James Strachan wrote:
+1
There's still a few patches that need to be applied to commons-sql from Tim
and John. Should we apply those before the move?
Sure, no rush. Everything is setup for new projects. It takes about 5
seconds to get new project info on the main
On Tue, 4 Feb 2003, Incze Lajos wrote:
In message [EMAIL PROTECTED], Hen
ri Yandell writes:
I'm +1 to commons-uri.
What about commons-naming?
That's JNDI.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Adam,
Thank you for your kind words.
The PropertyPointer used to work just like you are suggesting, but then
somebody complained and I changed it to always pass a legitimate index.
So now it is a backward compatibility issue.
Question: can't you determine whether you need to create the
Dmitri,
Thanks for your reply.
I understand about the backward compatibility issue, no problem. (Although
it does strike me as a bit strange that someone would require an index of
zero if the target is not an indexed one, I guess you're fighting a losing
battle if you are trying to satisfy
Hi,
I'd like to see a commons-configuration 1.0 release. Even an Alpha or a
Beta would be fine. I'm willing to help to see this release happen. So
what do we need to do?
As far as I can tell, there have been no code changes for a couple of
weeks. A couple of people have posted new code
scolebourne2003/02/04 08:56:09
Modified:lang/src/java/org/apache/commons/lang/enum Enum.java
Log:
Update to output more nicely formatted toString() that converts $ to .
Revision ChangesPath
1.7 +2 -1
I saw the bugzilla note come through, but I haven't had a chance to take a
detailed look at it yet. Hopefully I should be able to get to this by the
end of the week (unless someone beats me to it, hint, hint :).
On Mon, 3 Feb 2003, Gerald Turner wrote:
Has anyone looked at the bug #16581?
Here's Martin's post on rpc-dev re: cr/lf:
http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]m
sgNo=713
Here's some observations, I've copied individuals from both the xml-rpc and
the httpclient project. It all boils down to using Base64 encoding in the
context of two different RFCs,
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=15451.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
What a coincidence. I was going to propose the same thing today.
I'm not a commiter but I'll definitely help in any way I can.
+jeff
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 8:31 AM
To: [EMAIL PROTECTED]
Subject:
The voting for moving Jelly to the commons proper was 11 +1s and 2 +0s with
no -1s.
Now that all the reorganisation work has been completed, it'd be a good time
to move the code over to the commons proper CVS repository. Does someone who
knows how to do this without loosing the history fancy
Rodney Waldhoff wrote:
Assuming you want the same directory structure under jakarta-commons you
have under jakarta-commons-sandbox, simply executing:
cp -r jakarta-commons-sandbox/jelly jakarta-commons/.
should suffice to move the files and yet preserve the history. Later we
can do a CVS
Let me know what you want me to help with :)
Hen
On Tue, 4 Feb 2003, robert burrell donkin wrote:
by my count, we now have 3 +1's, 3 +0's and no -0's or -1's. therefore,
net is promoted to the commons.
- robert
-
To
Hi all,
personally I favour Ryan's suggestion of setting flags (and/or
system properties) separately to obtain non-RFC compliant behaviour (or
to specify which RFC to follow, where they conflict), or to specify
that exceptions should be raised when encountering a non-Base64 char,
rather
Hi all,
Currently I'm in process of replacing most of our util classes with
Jakarta-Commons.
But I can't find a way to serialize Method instance. I have looked in
commons.lang and commons.beanutils packages.
I'm attaching a possible solution. Don't know if it's not out of scope
though..
On Tue, 4 Feb 2003, robert burrell donkin wrote:
Date: Tue, 4 Feb 2003 18:37:10 +
From: robert burrell donkin [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: [beanutils] 1.6.1 release?
are we
The concept of setting flags etc seems to be quite poor OO. Maybe I'm not
understanding things properly though.
Shouldn't it be a classic FactoryMethod pattern?
Base64Utils
Base64 interface
hidden classes:
RFCBase64
OtherBase64
JimsBase64
and then:
Base64Utils-
public static Base64
org.apache.commons.lang.SerializationUtils doesn't help you here?
Ah. Method's are not Serializable.
There was no attachment Dmiter.
Hen
On Tue, 4 Feb 2003, Dimiter Dimitrov wrote:
Hi all,
Currently I'm in process of replacing most of our util classes with
Jakarta-Commons.
But I can't
You example below would make sense if the Base64 implementations were
dramatically different. It should be noted that the only sticking point is
chunked encoding - in essence, XML-RPC needs an implementation that adds
\n every 76 characters, and HttpClient does not. Making two different
Ok, this happened again...
For some unknown reason the list strips my attachments if they are not
with txt extension...
I'm using Outlook XP (and except for the crashing I haven't seen any
problems with it)...
Here is the attachment again..
-- dimiter
-Original Message-
From:
i'm keen to get jexl a proper commons website now that it's been promoted.
i need to modify a few files in jexl and so i'm going to add myself to the
list of committers unless - that is - someone wants to jump in with an
objection about now...
- robert
Cool, let me know what I can do.
robert burrell donkin [EMAIL PROTECTED] writes:
by my count, we now have 3 +1's, 3 +0's and no -0's or
-1's. therefore, net is promoted to the commons.
--
=
Jeffrey D. Brekke
I think all of us are new to this promotion process. If you lay out the
steps involved, we may be able to volunteer to help with some of them.
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 12:49 PM
To: Jakarta Commons Developers List
Move cvs.
Update website. [create website if need be]
Modify/inform gump.
Announce publically.
Anything else not covered by that?
Hen
On Tue, 4 Feb 2003, Steve Cohen wrote:
I think all of us are new to this promotion process. If you lay out the
steps involved, we may be able to volunteer
Ortwin Glück wrote:
-1
Filtering can be done in most mail clients if the right subject prefixes
are used. A separate list is not necessary.
i.e. use [VOTE][Codec] and not just [VOTE]
for votes interesting for all projects you could use [VOTE][COMMONS] or
[VOTE][ALL] or similar
I
robert burrell donkin wrote:
the following concerns me about the proposal:
(4) Initial Committers
The initial committers will be identical to those of the Standard Taglib
project.
i'm unhappy with this since it implies that all current taglib committers
will be grandfathered in. a list
I have a deja-vu sentiment, I remember we already voted on this.
But +1 again.
Costin
Jan Luehe wrote:
Please cast your vote on the promotion of the commons-el package from
commons sandbox to commons proper.
The commons-el package contains the EL evaluator code from JSP 2.0.
See
--- Robert Leland [EMAIL PROTECTED] wrote:
Rodney Waldhoff wrote:
Assuming you want the same directory structure
under jakarta-commons you
have under jakarta-commons-sandbox, simply
executing:
cp -r jakarta-commons-sandbox/jelly
jakarta-commons/.
should suffice to move the files
Right now the Base64 class is entirely static, with static method and
static members. The constructor is private, it cannot be instantiated.
I don't think we are looking for any OO here, its functional in nature.
We are not looking for radical redesign, changes or improvements, just a
nice
olegk 2003/02/04 12:16:27
Modified:httpclient/src/java/org/apache/commons/httpclient
Cookie.java
Log:
- fixes the problem with Cookie#Cookie(String, String, String, String, int, boolean)
constructor accepting negative max-age values
Contributed by
Are there any committers out there w/ some spare cycles? There are 3 patches for
configuration listed on nagoya.
thanks,
+jeff
-Original Message-
From: robert burrell donkin
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 10:44 AM
To: Jakarta Commons Developers List
1) One of the classes in the package set the flags in a static block.
2) The flags are set before each call to the Base64
encode/decode methods.
To use
flags safely, you would have to make them instance members and requre
instantiation of Base64 objects. This does more harm than good.
If this is the direction in which we are headed, I would nominate
Henri's initial idea. Bear in mind we are not talking about 1.1 here,
but 2.0 (i.e. future).
For 1.1, my vote (as a committer in XML-RPC) is for Jeffrey's solution,
with the default being opur consensus on the reading of the
Fair enough. I guess the normal case would be just
encode/decode(byte[]) without 76 character chunks, which is what
HttpClient would be using anyway.
So I take back any preference to method signature, except that the
normal or default case be not chunked. If xml-rpc is going to be
using
On Tue, 4 Feb 2003, Rodney Waldhoff wrote:
Assuming you want the same directory structure under jakarta-commons you
have under jakarta-commons-sandbox, simply executing:
cp -r jakarta-commons-sandbox/jelly jakarta-commons/.
On icarus, 'man cp' doesn't show a '-r' option. Here's what I used
One would have an encodeChunked, but there would be no need for a
decodeChunked. Whitespace is discarded in base64 data regardless of the
original encoding scheme.
For 1.1, it looks like a consensus is developing for a Base64 with two
functions, one chunked and one not chunked. The discussions
That sounds good here too. We only call Base64 methods a couple of
times anyway, so adaptation is a minor issue.
Just a note about tests, we have a Junit test class (not sure if xml-rpc
has one) that should go along with the main Base64 class. You did a
grep on the code base so I'm sure you
In message [EMAIL PROTECTED], robert burr
ell donkin writes:
you and Daniel are now entitled to commons karma (but you might need to
ask someone to get it).
I'll send a request in a minute to the PMC cc'ed to commons-dev asking
for Jeff and myself to be added to the avail entry for
We do as well. Codec should probably end up with the union, not the
intersection However, ours tests for the MIME specific 76 character
line wrapping.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Jeffrey Dever wrote:
That sounds good here too. We only call Base64 methods a
Base64 is well understood just as a general encoding scheme outside of RFC
2045 MIME. RFC 2045 MIME adds a further requirement that the content be
put into 76 character chunks. Past 1.1 we could also talk about Base64.java
providing the core base64 encoding, and MIMEBase64.java extending
Well said. Totally agree.
Ryan Hoegg wrote:
We do as well. Codec should probably end up with the union, not the
intersection However, ours tests for the MIME specific 76 character
line wrapping.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Jeffrey Dever wrote:
That sounds
In message [EMAIL PROTECTED], robert burr
ell donkin writes:
by my count, we now have 3 +1's, 3 +0's and no -0's or -1's. therefore,
net is promoted to the commons.
Dear Jakarta PMC,
Jakarta Commons has just completed a vote, promoting
jakarta-commons-sandbox/net out of the Sandbox and into
I'd offer to help but I really don't know anything about these processes
or rights to do them.
-Original Message-
From: Daniel F. Savarese [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 3:00 PM
To: Jakarta Commons Developers List
Subject: Re: [RESULT] [net] is promoted to
olegk 2003/02/04 13:22:07
Modified:httpclient/src/java/org/apache/commons/httpclient
Cookie.java
Log:
- Cookie#Cookie(String, String, String, String, int, boolean) constructor corrected
to accept -1 MaxAge value (cookie never expires)
Contributed by
Daniel F. Savarese wrote:
In message [EMAIL PROTECTED], robert burr
ell donkin writes:
by my count, we now have 3 +1's, 3 +0's and no -0's or -1's. therefore,
net is promoted to the commons.
Dear Jakarta PMC,
Jakarta Commons has just completed a vote, promoting
jakarta-commons-sandbox/net
On Tue, 4 Feb 2003, Daniel F. Savarese wrote:
Date: Tue, 04 Feb 2003 16:12:56 -0500
From: Daniel F. Savarese [EMAIL PROTECTED]
Reply-To: Jakarta Project Management Committee List
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject:
Craig R. McClanahan wrote:
Somebody already beat me to getting your jakarta-commons karma set up, but
I also do nightly builds of Commons packages on my machine -- starting
tonight, you should see commons-net nightly builds at:
Yeah, sounds like a latter stage is to get Steve nominated as a Committer
based on his previous work on Net.
On Tue, 4 Feb 2003, Steve Cohen wrote:
I'd offer to help but I really don't know anything about these processes
or rights to do them.
-Original Message-
From: Daniel F.
On Tue, 4 Feb 2003, Daniel F. Savarese wrote:
In message [EMAIL PROTECTED], robert burr
ell donkin writes:
you and Daniel are now entitled to commons karma (but you might need to
ask someone to get it).
I'll send a request in a minute to the PMC cc'ed to commons-dev asking
for Jeff and
scolebourne2003/02/04 14:06:24
Modified:lang/src/java/org/apache/commons/lang ArrayUtils.java
lang/src/test/org/apache/commons/lang ArrayUtilsTest.java
Log:
Add support for indexOf, lastIndexOf and contains for ArrayUtils
from Nikolay Metchev, bug ref 15438
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=15438.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=16785.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
scolebourne2003/02/04 14:12:09
Modified:lang/src/java/org/apache/commons/lang/time
FastDateFormat.java
Log:
Change scope of static constant for performance
from Gary Gregory, bug ref 16622
Revision ChangesPath
1.3 +5 -3
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=16622.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I have tried several times, from several different mirrors to download the src zip or
tar.gz for the latest release of commons-logging and they all appear to be invalid.
Anyone else getting this problem?
Glenn Kidd
-
To
Howdy,
I just downloaded (commons logging 1.0.2 src, tar.gz form) it,
uncompressed it, no problems.
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Glenn Kidd [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 5:18 PM
To: [EMAIL PROTECTED]
Subject:
Yes you are correct, I was mistaken. The tar.gz does appear to work. Thanks. The
zip version still seems to be broken for me though.
Glenn
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 2:22 PM
To: Jakarta Commons Developers List
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=16787.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=16787.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
scolebourne2003/02/04 14:50:31
Modified:lang/src/java/org/apache/commons/lang BooleanUtils.java
Log:
Fix javadoc from checkstyle
Revision ChangesPath
1.4 +2 -4
jakarta-commons/lang/src/java/org/apache/commons/lang/BooleanUtils.java
Index:
On Tue, 4 Feb 2003, Henri Yandell wrote:
On Tue, 4 Feb 2003, Daniel F. Savarese wrote:
I'll go ahead and move the site. It'll still point to commons-sandbox for
the source-reopsitory until the maven site gets rebuilt. Once it's moved,
I'll look into rebuilding.
Hen
Ack. I lied.
rwaldhoff2003/02/04 15:23:10
jakarta-commons-sandbox/jux - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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=16787.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Anyone know why/where fmt relies on Grant?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Morgan Delagrange [EMAIL PROTECTED] wrote on 04/02/2003 09:31:02 PM:
craigmcc2003/02/04 16:45:53
Modified:beanutils/src/test/org/apache/commons/beanutils
BeanUtilsTestCase.java
Log:
Ensure that copyProperty() allows you to set a write-only property.
Revision ChangesPath
1.21 +23 -4
craigmcc2003/02/04 16:49:22
Modified:beanutils/src/test/org/apache/commons/beanutils
BeanUtilsTestCase.java
Log:
Check setProperty() as well as copyProperty() for write-onyl property
support.
Revision ChangesPath
1.22 +23 -4
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=16233.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Just figured I'd start a new thread to mark off items as they're
completed. If I missed any of the TODOs that have been mentioned,
just add 'em.
[x] Get dfs and brekke commit privileges.
[x] Move cvs repository from sandbox to commons proper.
[x] Move project pages from sandbox to commons
craigmcc2003/02/04 17:47:42
Modified:digester/src/java/org/apache/commons/digester
BeanPropertySetterRule.java SetPropertyRule.java
digester/src/test/org/apache/commons/digester
BeanPropertySetterRuleTestCase.java
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=16233.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Mon, 3 Feb 2003, robert burrell donkin wrote:
Date: Mon, 3 Feb 2003 17:43:22 +
From: robert burrell donkin [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: [beanutils] 1.6.1 release? [WAS Re:
I updated the gump descriptors, cutting and pasting. Leveraging the
time I've spent lurking on alexandria-dev and now gump¸ I got gen.sh
to work and built commons-net, verifying my descriptor changes with
update.sh jakarta-ant
build.sh bootstrap-ant
update.sh jakarta-commons
build.sh
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=16645.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=16645.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Sung-Gu wrote:
I don't think it's not mature... :(
They have couple of issues still, as I know.. just not revealed yet.
At least they have reached Alpha status! This is more than enough for a
real commons sub-project outside the sandbox.
Sung-Gu wrote:
There isn't any uni-one to support the various charsets.(Let you regard it!)
Then, once it was tranformed, it should be tranformed back to the original.
That makes the transformed one to the original one.
Sung-Gu,
I have problems understanding your English and I can only guess
- Original Message -
From: Ortwin Glück [EMAIL PROTECTED]
Arrrg... again... :(
Not surprising though... :(((
by the String class. You must use byte[] in this case.
It was...
You speak of transformation. What sort of transformation is that? The
import sun.nio.cs.StandardCharsets;
Hi Sung-Gu
On Tue, 2003-02-04 at 11:37, Sung-Gu wrote:
Hi Oleg,
Again... well..
Ok... let me try to make you understand it again. HmmHmm...
Let's assume I am stupid
BTW, sorry to bother you that I haven't got you to get it right away
at that time even with a diagram and still... :(
Sung-Gu wrote:
- Original Message -
From: Ortwin Glück [EMAIL PROTECTED]
Arrrg... again... :(
Not surprising though... :(((
Sung-Gu, I don't want to upset you. I just want to understand the
problem that you are trying to solve with toUsingCharset. Your
explanations did not help so
You need to add the following line to your code somewhere:
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
The java.protocol.handler.pkgs property is only needed if you want to
use https with java.net.URL.
I previously thought that addProvider() was not needed, but it
- no need for fully qualified class names in @see or @link comments
- please use @since 2.0beta1 new methods/classes
Can do.
- don't see a need for getFirstHeader and getLastHeader
I didn't think so at first either. For some uses though I think it
works. For example if you want to get the
I'm getting an unresolved symbol now. Where do I import
Security.addProvider() from?
Tom
On Tue, 4 Feb 2003, Michael Becke wrote:
You need to add the following line to your code somewhere:
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
The
java.security.Security.addProvider().
Mike
Tom Samplonius wrote:
I'm getting an unresolved symbol now. Where do I import
Security.addProvider() from?
Tom
On Tue, 4 Feb 2003, Michael Becke wrote:
You need to add the following line to your code somewhere:
Security.addProvider(new
Now I get the runtime error:
javax.net.ssl.SSLException: untrusted server cert chain
Is there anything more that needs to be done to setup the connection?
I've seend some examples that setup all sorts of X509 stuff. Is that
required too? I'm using JSSE 1.0.3_01.
Tom
On Tue, 4 Feb
By default JSSE only support SSL certs that are signed by Verisign or
Thawte. To use a self signed cert (this appears to be what you are
doing) you have two options:
1) import the servers cert into your keystore
2) mess around with the X509 stuff, someone posted a URL earlier talking
about
Actually, the certificate is signed by Entrust (the site is
https://www3.interaction.bell.ca).
Can the Entrust root certificate be imported into the keystore easily?
The JSSE INSTALL.TXT talks about which file they go into, but doesn't
really provide any detail on where they come from.
...When I pass a Cookie that has max age set to -1 to the HttpState
addCookie, it thinks its expired (verified by the Cookie.isExpired) call
when clearly it isn't supposed to be. It won't put it in the request.
Any ideas?
Thanks.
Alan
Since the JRE doesn't recognize Entrust by default it is as though the
cert is self signed.
Take a look at Sun's docs for the keytool:
http://java.sun.com/j2se/1.3/docs/tooldocs/win32/keytool.html
There is also a good discussion thread covering this topic at:
Alan
I suppose you want to have a cookie that never expires. Currently
Cookie#Cookie(String, String, String, String, int, boolean) constructor
blindly assumes max age parameter to be a positive integer. To work the
problem around you can use Cookie#Cookie(String, String, String, String,
Date,
After trying to find the Entrust root certficate, I just exported a .cer
file from IE, and imported it like this:
keytool -import -alias entrust -file entrust.cer \
-keystore /usr/local/jdk/jre/lib/security/cacerts
That seems to do the trick.
Tom
On Tue, 4 Feb 2003, Michael
There were a couple threads over on the commons-dev list about having a
seperate VOTE list for all commons issues. I was in support of this,
but was clearly in the minority. The issue is now closed: all voting
will take place on the list where the issues are discussed.
Therefore, votes
Hi Sung-Gu,
Actually, that's very easy...
And not that important unless it's not going to be support multilinqual.
As you see the diagram, bytes informations created from the original charset
should be restored. That's all.
My understanding of what you're saying is that if someone
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=16645.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
- Original Message -
From: Laura Werner [EMAIL PROTECTED]
Hi Sung-Gu,
Actually, that's very easy...
And not that important unless it's not going to be support multilinqual.
As you see the diagram, bytes informations created from the original
charset
should be restored. That's
I occasionally get this exception while trying to readResponse() from a
HttpMethodBase and am trying to learn more about why it happens, and what I
should do about it. I am using 2.0-a2. I have searched bugzilla and found
this bug [ http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13463 ] that
1 - 100 of 103 matches
Mail list logo
