Spelling error (Was: cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt)

[Fredrik Westermarck]

[EMAIL PROTECTED] wrote:

  +---
  +Administrartion web application:
  +---
You might want to change 'Administrartion' to 'Administration' in 
jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt rev 1.57...

Regards,
Fredrik Westermarck


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

Re: JSPC refactoring/documentation

[Fredrik Westermarck]

Costin Manolache wrote:


The problem that I and others have experienced is that proposals and/or
patches, by non-committers, don't get discussed or voted about.

You have to keep pushing.


Well I did, but the next person might not. In that case the community as 
a whole may miss important features or ideas.

> If you send patches and proposals you can
become a committer - and then you'll start ignoring patches and proposals  
:-)

If I was a committer I wouldn't feel good about ignoring patches and 
proposals. By the way isn't ignoring patches/proposals the opposite of 
what a committer is supposed to do?

I'm sorry - but everyone is very short on time.


Yes, I do know that and respect that.


Is there any concrete feature that you need in 4.1 but is not implemented ?


Not anymore. :)


What's important ( IMO ) is that at the moment it seems more people are
actively working on 5.0, so its easier to get things changed there. 
4.1 is stable - and it's normal to be a high resistence to bigger changes.

I didn't know that Tomcat 4 (as it seems now) wasn't to be actively 
maintained and improved. I thought Tomcat 5 goal was to improve Tomcat 4 
and implement the new Servlet- and JSP-specs.

Maybe the community has to be told that 4.1 is in 'high resistence'-mode 
so that ppl know that they should test their apps with 5.0 if they want 
or is waiting for new features that have been proposed.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Release notes

[Fredrik Westermarck]

Hi!

If the patch which enables JNDIRealms to use SSL will make it into the 
next release of TC 4.1 it might be a good idea to add it in the release 
notes too.

Regards,
Fredrik Westermarck


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>

Re: JSPC refactoring/documentation

[Fredrik Westermarck]

Costin Manolache wrote:


Do you actually mean that a new feature will only be added if there is
enough committers that need the feature? Does this apply only to 4.1.x?

Well... In theory it should apply to all tomcat features, or at 
least to important ones - they must be first proposed on the list,
discussed, and then voted. We use 'lazy consensus' ( i.e. commit
first and wait for -1 ) a bit too much.

Well there is quite a difference between needs and accepts.

The problem that I and others have experienced is that proposals and/or 
patches, by non-committers, don't get discussed or voted about.

Since I'm not aware of the TC 5.0 requirements regarding the JDK and
such I might be wrong here but...

AFAIK - JDK1.3.
( it should work fine with JDK1.2, but I don't think it is tested that 
much ).

Should...


My guess is that many users will not be able to switch to TC 5.0 when it
is released since their applications might have to be modified and in
many cases also be unable to switch since their application might not be
tested with the required JDK.

TC5.0 should be backward compatible.


Should... Yes I also tell my customers that it should work, even if you 
never can be 100% sure. :-)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JSPC refactoring/documentation

[Fredrik Westermarck]

Costin Manolache wrote:


I consider 4.1.x can recieve bug fixes and minor feature additions
(example: the JNDI realm new feature which just got added,
optimisations, etc ...), similar to HTTPd 2.0. This is consistent with
the patches I and others have been applying, the release process we've
been following, and so on.



+1

If there is enough interest and committers that need that feature -
I see no problem with that.


Do you actually mean that a new feature will only be added if there is 
enough committers that need the feature? Does this apply only to 4.1.x?

Since I'm not aware of the TC 5.0 requirements regarding the JDK and 
such I might be wrong here but...

My guess is that many users will not be able to switch to TC 5.0 when it 
is released since their applications might have to be modified and in 
many cases also be unable to switch since their application might not be 
tested with the required JDK.

If so wouldn't it be better if new features could be implemented into TC 
4.x?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realmJNDIRealm.java

[Fredrik Westermarck]

Amy Roh wrote:

I don't use SSL with JNDIRealm so I didn't test this out.  However, the
patch seems ok and has been ignored long enough (with a few complaints).
;-)  Let me know if there're any issues.


Thank you!


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Request] Commit the JNDIRealm patch

[Fredrik Westermarck]

Jonathan Eric Miller wrote:

I have a patch as well which I submitted back in June. I haven't received a
response either.


Well I guess you and I are the only ones using SSL to connect to our 
directory servers...

It would be nice if someone reviewed our patches, merged and commited 
them, or atleast did start a discussion on the subject if the 
implementation could be improved or be done in a different and better way.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[Request] Commit the JNDIRealm patch

[Fredrik Westermarck]

Hi!

I have on several occations tried to get my patch commited without any 
luck, no one have opposed the patch or the actual implementation.

The patch enables the JNDIRealm to connect to a directory server using SSL.

The patch (and docs-patch) can be found in my original post 
.

Can someone with privileges to commit please commit it to TC4.1?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: The JNDIRealm

[Fredrik Westermarck]

?? ??? wrote:

Hi!

On this subject already wrote Fredrik Westermarck.

I concerning JNDIRealm. Unfortunately I am not yet commiter, therefore 
of powerful contribution bring I can not.
Usage SSL in JNDIRealm is a urgent subject - we use it for 
authentification of the users registered in Novell NDS - and the base 
mechanism does not suffice. It is necessary to work with LDAP not only 
as with the database (realm) but also as with the mechanism of 
identification of the users. For this purpose JNDIRealm tries to 
incorporate to the server through the mechanism of a login name - 
password indicated by the user. It is desirable that JNDIRealm was 
connected even with a minimum level of privacy.

I offer to expand JNDIRealm so, that it could solve all these tasks.

Tomcat 4.1.x support binding as the user _or_ searching for a user and 
comparing passwords.

However it doesn't support connecting to a SSL-enabled directory server 
- the patch I posted will let you do that. But we need someone that is 
willing to commit the patch... or atleast reviewing it and commeting it 
and how it could be improved.


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>

The JNDIRealm

[Fredrik Westermarck]

Hi!

On the 27th Sep I posted a patch regarding JNDIRealm and SSL 
(http://www.mail-archive.com/tomcat-dev@;jakarta.apache.org/msg34121.html).

When I didn't get any feedback on the patch for a couple of weeks I sent 
a followup to try to remaind the tomcat developer community of the 
existance of the patch.

Since that message also seems to have been overlooked I then both Craig 
(who is the origninal author) and Remy about it (yes, I realize you guys 
are busy).

So far without any response. :(

Whats the meaning of using an OSS development model if the 
users/non-commiters work is not considered?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [patch] JNDIRealm and SSL

[Fredrik Westermarck]

Fredrik Westermarck wrote:
> Hi!
> 
> I have added the possibility to use SSL with the JNDIRealm in the file 
> JNDIRealm.java.diff.

So how about this patch? Anyone that want to commit it, or else comment 
on how it could be done in a better way?




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

[patch] JNDIRealm and SSL

[Fredrik Westermarck]

Hi!

I have added the possibility to use SSL with the JNDIRealm in the file 
JNDIRealm.java.diff.

This patch allows two more parameters to be set for the JNDIRealm. If they are 
not explicitly set the JNDIRealm will behave in the same way as before.

I tried to document the changes (or additions) for the configuration in the 
realm.xml.diff.

O, as a bonus I did remove some unused imports and a fixed a typo in the 
javadoc in JNDRealm.

Regards,
Fredrik Westermarck


JNDIRealm.java.diff
Description: Binary data


realm.xml.diff
Description: Binary data

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

Building jakarta-tomcat-connectors issue

[Fredrik Westermarck]

Hi!

I have been trying to follow the instructions 
(http://jakarta.apache.org/tomcat/tomcat-4.1-doc/BUILDING.txt) on how to 
build Tomcat from source.

After awhile all needed packages was installed and the build.properties 
was configured properly.

 > ant dist

BUILD FAILED

/home/fwk/jakarta/jakarta-tomcat-connectors/jk/build.xml:377: Class 
org.apache.tools.ant.taskdefs.condition.Not doesn't support the nested 
"isset" element.

I'm using Ant 1.5 and the jakarta-tomcat-connectors from HEAD.

What to do about it? All I want to do is to compile Tomcat. :P

Regards,
Fredrik Westermarck


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