PROTECTED] / 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
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
--
Th
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 exac
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
--
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 ha
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 .
Please read the short readme at
jakarta-tomcat
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 .
Please read the short readme at
jakarta-tomcat-catalina/modules/stor
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
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
-
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 addi
Hi,
>IMHO, 1.5 would be the right way to go. For me mostly for performance,
>and cleaner code reasons (generics, auto-boxing, enums, etc.).
Please do NOT automatically equate JDK 1.5 with cleaner code.
Cleanliness is obviously subjective. If you think auto-boxing is a good
performance thing, yo
Dear Valued Customer,
Thank you for contacting Customer Support at www.ballystore.com.
In an effort to increase the effectiveness of customer communication, we
recently modified our customer support e-mail addresses, and our system
is unable to accept the e-mail you sent us.
Please visit our onl
Remy Maucherat wrote:
Another thing is that we might want to write the next Tomcat for JDK
1.5.
Anything specific in JDK 1.5? We already spoke a bit about NIO in some
form, but that's JDK 1.4.
Annotations :) (I saw EJB 3)
I have to assume we're going to have some annotations defined in the
sp
On Sun, 16 May 2004, Remy Maucherat wrote:
| Costin Manolache wrote:
|
| > 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
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
For the critical path probably it's good to keep using an interface,
but for all "container changes" and other notification - there is no
performance issue.
Yes, but we can't be too bad either: if we take one minute to deploy
a
Costin Manolache wrote:
Remy Maucherat wrote:
For the critical path probably it's good to keep using an interface,
but for all "container changes" and other notification - there is no
performance issue.
Yes, but we can't be too bad either: if we take one minute to deploy a
webapp (unless we're p
Remy Maucherat wrote:
For the critical path probably it's good to keep using an interface,
but for all "container changes" and other notification - there is no
performance issue.
Yes, but we can't be too bad either: if we take one minute to deploy a
webapp (unless we're precompiling on deploy ;
Costin Manolache wrote:
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/
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 be
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 perf
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 im
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
o
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
"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
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 s
- 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
>
>
> &
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 th
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 distribut
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
ev
> -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 othe
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 outs
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.
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 ASF
> -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 th
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.
As
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 the
> -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 t
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 wo
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
at" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, March 11, 2004 5:54 AM
Subject: [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 relea
This account does not exist
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AIL PROTECTED]>
Sent: Thursday, March 11, 2004 5:54 AM
Subject: [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
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). Th
loads, but most 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
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
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
- 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 an
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 relea
> - 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 rel
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, and
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-rele
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 i
hursday, January 29, 2004 12:48 AM
Subject: WANTED: 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
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
>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
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 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 r
n 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 ?).
- D
- 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:
>
> >R
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
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 just
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 ( getting
differ
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 t
ithin 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 me
> -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
ld be within 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 f
mpile 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 fou
68 matches
Mail list logo
