Hello,
the current release is 5.5.10-alpha. Are there plans to change this in a
5.5.10 or make a 5.5.11?
The bug #35894 (http://issues.apache.org/bugzilla/show_bug.cgi?id=35894) Bill
has resolved today is a stopper, because the Tomcat cannot start with
SecurityManager enabled.
Thorsten
--
] / www.yoavshapira.com
-Original Message-
From: Thorsten Kamann [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 04, 2005 2:29 AM
To: tomcat-dev@jakarta.apache.org
Subject: Next Release 5.5.11?
Hello,
the current release is 5.5.10-alpha. Are there plans to change this in a
5.5.10
OK, I can do that at monday.
Thanx
Peter
Remy Maucherat schrieb:
Peter Rossbach wrote:
Hey Remy,
yes, but I thing we need some test. Than I can made the complete
integration.
I vote in favor of doing the complete integration right now. Worst
case it's as bad as the current code, which isn't
Yoav Shapira wrote:
Hi,
Happy new year everyone ;) I just got back from vacation and don't have time
to read all the archives. What's the feeling as to a good time for the next
5.5 release?
I did some more bugfixing. Hopefully the hot deployer will be fully
functional in this build :)
Is it ok
Hey Remy,
I have ready my first storeconfig module to better save server.xml and
context.xml. At the
first step I add the implementation as new module. I have wrote a
StoreConfigLifecycleListener to register
a new Mbean .
Server ..
Listener
Peter Rossbach wrote:
Hey Remy,
I have ready my first storeconfig module to better save server.xml and
context.xml. At the
first step I add the implementation as new module. I have wrote a
StoreConfigLifecycleListener to register
a new Mbean .
Server ..
Listener
Hey Remy,
yes, but I thing we need some test. Than I can made the complete
integration.
Peter
Remy Maucherat schrieb:
Peter Rossbach wrote:
Hey Remy,
I have ready my first storeconfig module to better save server.xml
and context.xml. At the
first step I add the implementation as new module. I
Peter Rossbach wrote:
Hey Remy,
yes, but I thing we need some test. Than I can made the complete
integration.
I vote in favor of doing the complete integration right now. Worst case
it's as bad as the current code, which isn't exactly well tested in the
5.5 branch ;)
Rémy
Hi,
Happy new year everyone ;) I just got back from vacation and don't have time
to read all the archives. What's the feeling as to a good time for the next
5.5 release?
Yoav
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Yoav Shapira wrote:
Hi,
Happy new year everyone ;) I just got back from vacation and don't have time
to read all the archives. What's the feeling as to a good time for the next
5.5 release?
I know there's still some deployer related troubles with 5.5.6. That
should be ok now.
Rémy
Remy Maucherat wrote:
Shapira, Yoav wrote:
One area to keep in mind there is performance. There's no argument on
the utility of JMX at all. I also think most of the performance hit
would be at initialization (and shutdown), as you're
creating/naming/binding JMX operations/attributes. This is
Remy Maucherat [EMAIL PROTECTED] wrote:
I feel like starting working on the possible new codebase for Tomcat,
now that Tomcat 5 is more or less stabilized. I have a few obvious
items, but while a lot could be done to make the code more modern, it
wouldn't make Tomcat actually run better, so
Bill Barker wrote:
Remy Maucherat [EMAIL PROTECTED] wrote in message
+1 for doing this in the Catalina code. Doing it in the Connector code
would mean that CoyoteConnector code for older TC versions would languish
off in a branch.
They have the same name :( I was obviously talking about the
Hi,
I think the valve is the right pattern, so thanks Craig :) The only
thing is that we shouldn't have the ValveContext which adds complexity
(worthless IMO, as we don't need the extra robustness for our
proprietary API, esp since its realm of application is getting lower
due
to the spec
Shapira, Yoav wrote:
One area to keep in mind there is performance. There's no argument on
the utility of JMX at all. I also think most of the performance hit
would be at initialization (and shutdown), as you're
creating/naming/binding JMX operations/attributes. This is better than
having a
I feel like starting working on the possible new codebase for Tomcat,
now that Tomcat 5 is more or less stabilized. I have a few obvious
items, but while a lot could be done to make the code more modern, it
wouldn't make Tomcat actually run better, so I favor changing things
only if it brings
Remy Maucherat [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I feel like starting working on the possible new codebase for Tomcat,
now that Tomcat 5 is more or less stabilized. I have a few obvious
items, but while a lot could be done to make the code more modern, it
wouldn't make
Remy Maucherat wrote:
Bill Barker wrote:
I agree with Yoav that we can afford to wait a few days (if only so I
don't
have to take down the 3.3.2 binary distro :). However, I don't think
that,
without the ASF changing it's position, we can simply add some lines
to the
LICENSE file. That may
-Original Message-
From: Henri Gomez
Here is a reply I got from the community list :
This is not a complete prohibition on all third-party jars or
libraries, but only on those third-party libraries which are
licensed under terms more restrictive than the ASL.
Ask them is
Henri Gomez wrote:
This is not a complete prohibition on all third-party jars or libraries,
but
only on those third-party libraries which are licensed under terms more
restrictive than the ASL.
In the case of mx4j, the code is licenced under the mx4j 1.0 License
[1], which
is a derivative of
Mladen Turk wrote:
-Original Message-
From: Henri Gomez
Here is a reply I got from the community list :
This is not a complete prohibition on all third-party jars or
libraries, but only on those third-party libraries which are
licensed under terms more restrictive than the ASL.
-Original Message-
From: jean-frederic clere
Mladen Turk wrote:
What about linking to static microsoft libraries?
That is probably not OK.
I know that, but I know too that the law doesn't have a term _probably_ in
it's dictionary.
Do we need to sign that or ASF
Mladen Turk wrote:
-Original Message-
From: jean-frederic clere
Mladen Turk wrote:
What about linking to static microsoft libraries?
That is probably not OK.
I know that, but I know too that the law doesn't have a term _probably_ in
it's dictionary.
Do we need to sign that or
jean-frederic clere wrote:
Mladen Turk wrote:
-Original Message-
From: jean-frederic clere
Mladen Turk wrote:
What about linking to static microsoft libraries?
That is probably not OK.
I know that, but I know too that the law doesn't have a term
_probably_ in
it's dictionary.
Henri Gomez wrote:
Well I didn't agreed on moving TC binaries to sf or others.
I mentioned that being also involved in projet like Jpackage, I know
that's producing ready to use packages is not so easy, expecially when
you have to explain to users that they have to get MANY external jars
from
-Original Message-
From: Henri Gomez
Henri, Remy and Costin proposed to move the binaries to
sourceforge,
until
the things clears up.
I'm in favor of that, and will support such a decision if voted.
Well I didn't agreed on moving TC binaries to sf or others.
Sorry,
Please subscribe to [EMAIL PROTECTED] and follow the thread about
'clarification'.
It seems there is a discussion on having non ASF binaries :
2) state that the ASF will allow the use of its infrastructure for the
distribution of binary objects that are legally distributable standalone
Henri Gomez wrote:
Please subscribe to [EMAIL PROTECTED] and follow the thread about
'clarification'.
It seems there is a discussion on having non ASF binaries :
2) state that the ASF will allow the use of its infrastructure for the
distribution of binary objects that are legally
Remy Maucherat wrote:
Henri Gomez wrote:
Please subscribe to [EMAIL PROTECTED] and follow the thread about
'clarification'.
It seems there is a discussion on having non ASF binaries :
2) state that the ASF will allow the use of its infrastructure for
the distribution of binary objects
- Original Message -
From: Mladen Turk [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, March 12, 2004 3:24 AM
Subject: RE: [5.0] Problems with the next release
-Original Message-
From: jean-frederic clere
Mladen Turk
Hi,
There are some problems with the next release, with the decision from
the ASF board to mandate that all ASF releases are to be made of 100%
ASL 2.0 licensed components (as a side note, I'd like to add that this
is obviously a terrible decision). This has many consequences and some
Remy Maucherat wrote:
Hi,
There are some problems with the next release, with the decision from
the ASF board to mandate that all ASF releases are to be made of 100%
ASL 2.0 licensed components (as a side note, I'd like to add that this
is obviously a terrible decision). This has many
likely that might not
be feasible. I would hate to see jakarta projects fork, just so we can provide
complete distributions.
peter lin
Remy Maucherat [EMAIL PROTECTED] wrote:Hi,
There are some problems with the next release, with the decision from
the ASF board to mandate that all ASF releases
Hi,
The options seem to be:
A) Ship Tomcat 5.0.20 without JMX, and have it display a message with
instructions on how to install JMX if it's not present (basically,
everywhere but on JDK 1.5.0).
B) Ship the binaries from non ASF servers (we could setup a project for
that on Sourceforge). The
: [5.0] Problems with the next release
Hi,
There are some problems with the next release, with the decision from
the ASF board to mandate that all ASF releases are to be made of 100%
ASL 2.0 licensed components (as a side note, I'd like to add that this
is obviously a terrible decision). This has
This account does not exist
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bill Barker wrote:
I agree with Yoav that we can afford to wait a few days (if only so I don't
have to take down the 3.3.2 binary distro :). However, I don't think that,
without the ASF changing it's position, we can simply add some lines to the
LICENSE file. That may work in C land, but in Java
Hi,
I'd like to follow on with the one-release-a-month rythm for now, since
we still have interesting bugfixes here and there (ex: the cross context
fix, plus some JSP fixes). So this means tagging 5.0.20 at the end of
next week.
It would be a good idea to attempt to fix all the remaining BZ
, to be used if you have sticky
sessions, for big clusters and faster performance
Filip
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 04, 2004 1:36 AM
To: Tomcat Developers List
Subject: [5.0] Next release
Hi,
I'd like to follow on with the one-release
oh yeah, and the bugs have been fixed :) (27296,27259)
-Original Message-
From: Filip Hanik (lists) [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 04, 2004 8:10 AM
To: Tomcat Developers List
Subject: RE: [5.0] Next release
end of next week sounds good.
I have some very minor fixes
- plenty of admin webapp patches need to be merged; Amy and Larry were
the last persons seen maintaining this feature, so can one of you two do
it if you have time ?
Haven't had much time to spend on admin lately. Let me try to spend some
time on admin before the next release to update. Let
Amy Roh wrote:
- plenty of admin webapp patches need to be merged; Amy and Larry were
the last persons seen maintaining this feature, so can one of you two do
it if you have time ?
Haven't had much time to spend on admin lately. Let me try to spend some
time on admin before the next release
- Original Message -
From: Amy Roh [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, March 04, 2004 9:00 AM
Subject: Re: [5.0] Next release
- plenty of admin webapp patches need to be merged; Amy and Larry were
the last persons seen maintaining
Hi all,
I'm sure that a lot of folks want to see a new release of mod_jk2;
and looking at:
http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/
it seems that the last version 2.0.2 was released 14 (!!) months ago
comments?
Guenter.
Hi all,
I'm sure that a lot of folks want to see a new release of mod_jk2;
and looking at:
http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/
it seems that the last version 2.0.2 was released 14 (!!) months ago
comments?
We sure DO WANT a new release.
regz,
Dominik
Dominik Drzewiecki wrote:
Hi all,
I'm sure that a lot of folks want to see a new release of mod_jk2;
and looking at:
http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/
it seems that the last version 2.0.2 was released 14 (!!) months ago
comments?
We sure DO WANT a new release.
I
: next release mod_jk2 after 14 months!!
Hi all,
I'm sure that a lot of folks want to see a new release of mod_jk2;
and looking at:
http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/
it seems that the last version 2.0.2 was released 14 (!!) months ago
comments?
Guenter
to compile a list of issues which should be fixed in the
next release.
As a starting point:
- Fix HTTP compression check (I think a small refactoring is needed to
make the feature cleaner).
- Fix FORM processing for more complex requests (bug 10229).
- Error message when the Java compiler
a list of issues which should be fixed in the
next release.
As a starting point:
- Fix HTTP compression check (I think a small refactoring is needed to
make the feature cleaner).
- Fix FORM processing for more complex requests (bug 10229).
- Error message when the Java compiler is not found
.
So I would need to compile a list of issues which should be fixed in the
next release.
As a starting point:
- Fix HTTP compression check (I think a small refactoring is needed to
make the feature cleaner).
- Fix FORM processing for more complex requests (bug 10229).
- Error message when
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache
Sent: Wednesday, April 02, 2003 10:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [4.1.x] Next release
Remy Maucherat wrote:
Hi,
As far as I am concerned, the focus for the next stable 4.1.x release
one to two months.
So I would need to compile a list of issues which should be fixed in the
next release.
As a starting point:
- Fix HTTP compression check (I think a small refactoring is needed to
make the feature cleaner).
- Fix FORM processing for more complex requests (bug 10229).
- Error message
Remy Maucherat wrote:
Could I get some details on that filter/facade bug ?
Yes, Filter.init() is called with the Context object instead of the
facade. While Servlet.init() is called correctly.
This may allow access to the internals, and is just weird ( getting
different context objects in
Costin Manolache wrote:
Remy Maucherat wrote:
Could I get some details on that filter/facade bug ?
Yes, Filter.init() is called with the Context object instead of the
facade. While Servlet.init() is called correctly.
This may allow access to the internals, and is just weird ( getting
Costin Manolache wrote:
Remy Maucherat wrote:
Could I get some details on that filter/facade bug ?
Yes, Filter.init() is called with the Context object instead of the
facade. While Servlet.init() is called correctly.
This may allow access to the internals, and is just weird (
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Could I get some details on that filter/facade bug ?
Yes, Filter.init() is called with the Context object instead of the
facade. While Servlet.init() is called correctly.
This may allow access to the internals, and is
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Could I get some details on that filter/facade bug ?
Yes, Filter.init() is called with the Context object instead of the
facade. While Servlet.init() is called correctly.
This may allow access to the internals, and
- Original Message -
From: Jean-Francois Arcand [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, April 02, 2003 12:37 PM
Subject: Re: [4.1.x] Next release
Costin Manolache wrote:
Remy Maucherat wrote:
Could I get some details
in the
next release.
As a starting point:
- Fix HTTP compression check (I think a small refactoring is needed to
make the feature cleaner).
- Fix FORM processing for more complex requests (bug 10229).
- Error message when the Java compiler is not found by Ant (if this is
fixable; Costin ?).
- Double
59 matches
Mail list logo
