On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas ma...@apache.org wrote:
All,
I was thinking about this on my way back from ApacheCon and we probably
need to get some advice out to users early next week.
My current understanding is that the MITM attack is triggered by a
renegotiation.
On this
On Wed, Nov 4, 2009 at 6:47 AM, Mikhail Kryshen mikh...@kryshen.net wrote:
On Tue, 3 Nov 2009 16:34:57 -0800
Costin Manolache cos...@gmail.com wrote:
Curious: how does it scale for large number of users, in particular if
you
have NFS homes ?
I use it at a university server with 780 user
Curious: how does it scale for large number of users, in particular if you
have NFS homes ?
It would be interesting to change this to not init the contexts when tomcat
starts - just register a handler that would start the context on first
request.
Or as a Valve that looks for ~foo and then
+1 - Executor seems the right interface, didn't exist when workers were
started - ifanyone needs the pool behavior it can probably be implemented as
an Executor.
I assume you'll have some way to configure what kind of executor ?
Costin
On Fri, Aug 14, 2009 at 1:30 AM, Mark Thomas
, 2009, at 1:22 PM, Costin Manolache wrote:
Thanks - so objectweb instead of BCEL.
I'll try it out - it's a bit different from what I had in mind, it looks
like xbean-finder first finds all classes and
than reads the files using the class loader ( but not Class.forName,
which
is good
Hi, anyone working on the @Filter, @Servlet annotation scanner for
tomcat-trunk ?
If I'm understanding it correctly, tomcat will have to read all files in
classes and lib and look for the
annotation - and I would guess the only reasonable option is looking at
bytecode.
I checked BCEL - seems
/apache/geronimo/specs/geronimo-servlet_3.0_spec/1.0-EA-SNAPSHOT/
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_3.0_spec
thanks
david jencks
On Aug 4, 2009, at 11:11 AM, Costin Manolache wrote:
Hi, anyone working on the @Filter, @Servlet annotation scanner
On Fri, Jul 10, 2009 at 5:19 PM, David Jencksdavid_jen...@yahoo.com wrote:
On Jul 10, 2009, at 5:01 PM, Filip Hanik - Dev Lists wrote:
On 07/10/2009 05:19 PM, Yoav Shapira wrote:
On Fri, Jul 10, 2009 at 6:26 PM, David Jencksdavid_jen...@yahoo.com
wrote:
I am well aware that the tomcat
One suggestion: I think it would be nice to consider scalability - if you
have one tomcat frontend forwarding to 100 backends and acting as a load
balancer - you probably can't afford one connection per thread. Many of the
http forwarders I know use a blocking http client library - I think this
On Mon, Apr 6, 2009 at 3:06 PM, Filip Hanik - Dev Lists
devli...@hanik.comwrote:
Mladen Turk wrote:
Costin Manolache wrote:
So in essence you have a new protocol but the sole
difference is how you describe it.
The API can be something like:
- legacyRequest(RequestMessage) - whatever we
On Sat, Apr 4, 2009 at 1:10 AM, Mladen Turk mt...@apache.org wrote:
Costin Manolache wrote:
and certainly not
worth creating a new protocol. We need to pick one of
thrift/protobuf/hessian for
marshaling, and start doing some mux-ing in the protocol.
All those framework you mention
On Sat, Apr 4, 2009 at 8:12 AM, Mladen Turk mt...@apache.org wrote:
Costin Manolache wrote:
So in essence you have a new protocol but the sole
difference is how you describe it.
The API can be something like:
- legacyRequest(RequestMessage) - whatever we have in the current AJP
protocol
On Sat, Apr 4, 2009 at 9:30 AM, Mladen Turk mt...@apache.org wrote:
Costin Manolache wrote:
On Sat, Apr 4, 2009 at 9:03 AM, David Jencks david_jen...@yahoo.com
wrote:
My understanding of 'what we talk about' is what to do with mod_jk -
deprecate/remove old code, add few features
+1 on removing from trunk.
IMHO AJP as a protocol is a dead end - it is not worth extending, and
certainly not
worth creating a new protocol. We need to pick one of
thrift/protobuf/hessian for
marshaling, and start doing some mux-ing in the protocol. If we end up using
MINA
or some other RPC -
On Fri, Apr 3, 2009 at 10:24 AM, Mladen Turk mt...@apache.org wrote:
Costin Manolache wrote:
+1 on removing from trunk.
IMHO AJP as a protocol is a dead end - it is not worth extending,
Agreed. It has to many limitations to satisfy the
modern webserver/backend connector.
and certainly
I wouldn't be that concerned about configuration - tomcat can still
instantiate the filter
independent of web.xml, like it does with the valve.
Or the filter could be used 'user-space', i.e. user adding the filter
explicitly and not
using the declarative security.
One of the problems with tomcat
, 2009 at 1:36 AM, Costin Manolache cos...@gmail.com wrote:
I wouldn't be that concerned about configuration - tomcat can still
instantiate the filter
independent of web.xml, like it does with the valve.
Or the filter could be used 'user-space', i.e. user adding the filter
explicitly
On Wed, Mar 25, 2009 at 9:12 AM, Henri Gomez henri.go...@gmail.com wrote:
2009/3/25 William A. Rowe, Jr. wr...@rowe-clan.net:
Mladen Turk wrote:
The problem with mod_proxy and mod_cluster is the
fact they are targeted for a *single* web server (httpd)
Which varies from a one off
On Wed, Mar 25, 2009 at 9:42 AM, Mladen Turk mt...@apache.org wrote:
William A. Rowe, Jr. wrote:
If there's a desire to move ahead with a new connector at the tomcat
project, and the branch/release approach is planned to yield stable
code that will improve from release to release, why even
On Wed, Mar 25, 2009 at 11:17 AM, Rainer Jung rainer.j...@kippdata.dewrote:
On 25.03.2009 18:38, Costin Manolache wrote:
This thread was more about where to implement new features - if the goal
is
a 'redesign
from scratch' than maybe sandbox or a branch is a better place, but we
tried
...@kippdata.dewrote:
On 25.03.2009 19:33, Costin Manolache wrote:
On Wed, Mar 25, 2009 at 11:17 AM, Rainer Jungrainer.j...@kippdata.de
wrote:
Thanks Costin for coming back to this topic. Collecting ideas for major
redesigns could be done, but that was not my intention. I don't see
enough
On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez henri.go...@gmail.com wrote:
If you look at my message, my favourite is *not* a JK3. I'm in favor of
jk
1.3. The difference for me is that 1.3 will be very close to 1.2 without
any
bug architectural changes like migrating to APR.
ok.
I
On Tue, Mar 24, 2009 at 8:57 AM, jean-frederic clere jfcl...@gmail.comwrote:
Costin Manolache wrote:
On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez henri.go...@gmail.com
wrote:
If you look at my message, my favourite is *not* a JK3. I'm in favor of
jk
1.3. The difference for me
On Tue, Mar 24, 2009 at 8:46 AM, Rainer Jung rainer.j...@kippdata.dewrote:
On 24.03.2009 16:29, Costin Manolache wrote:
On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomezhenri.go...@gmail.com
wrote:
Why not moving into mod_proxy? If httpd were approaching a major version
change (e.g. httpd 3.0
operation (it's not really the case today).
This AJP library could be fully APR (and so remove the pain with
#define / #ifdef...)
2009/3/24 Costin Manolache cos...@gmail.com:
On Tue, Mar 24, 2009 at 8:46 AM, Rainer Jung rainer.j...@kippdata.de
wrote:
On 24.03.2009 16:29, Costin
Please go ahead and remove it.
10 years ago it seemed a good idea to avoid the IPC. Now it seems even
running them
on the same machine is obsolete.
Costin
On Thu, Mar 5, 2009 at 1:03 AM, Mark Thomas ma...@apache.org wrote:
Mladen Turk wrote:
Mark Thomas wrote:
I stumbled across some code
On Fri, Feb 6, 2009 at 3:07 PM, Remy Maucherat r...@apache.org wrote:
On Fri, 2009-02-06 at 14:59 -0700, Filip Hanik - Dev Lists wrote:
that discussion does exist if you look back into the archives
what has changed since then?
The proposed module layout looks so-so to me, and apparently
On Tue, Feb 3, 2009 at 5:14 AM, Remy Maucherat r...@apache.org wrote:
On Fri, 2009-01-30 at 17:44 -0700, Filip Hanik - Dev Lists wrote:
I would suggest
https://svn.apache.org/repos/asf/tomcat/
- site
- tc6.0.x
- trunk
- modules -- ADD THIS
- jdbc-pool
It's getting spaghetti... If you really have to - no need to add 'modules' -
just have them top-level ( i.e. under asf/tomcat ).
What prevents you from tagging ? Tag is cheap AFAIK - just tag the entire
trunk.
I personally hate working with many small repos. I understand the need when
you want
+0
I kind of liked the functionality ( i.e. write a servlet and have it 'just
work', without web.xml ).
And the annotations have their own problems ( scanning all the classes ).
But to turn this around to my favorite subject - wouldn't be better to
exclude it from the
release ? Maybe this and
I think there is a solution that would make everyone happy :-) - put this
code and
everything that depends on it in a separate module ( separate == different
release cycle and binary ). I don't know if it should be in a separate svn
tree, probably
would be better.
Then you can cut a release - and
On Tue, Oct 21, 2008 at 1:05 PM, Filip Hanik - Dev Lists [EMAIL PROTECTED]
wrote:
Let's get a feel for what we think we should do.
Based on
https://issues.apache.org/bugzilla/show_bug.cgi?id=46038
I believe (pick only one):
a. [ ] It doesn't belong here, take it elsewhere
b. [ ] Bring
On Thu, Oct 9, 2008 at 11:49 PM, jean-frederic clere [EMAIL PROTECTED]wrote:
Costin Manolache wrote:
On Thu, Oct 9, 2008 at 9:18 AM, Filip Hanik - Dev Lists
[EMAIL PROTECTED]wrote:
Costin Manolache wrote:
I never understood the use of the manual changelog - as opposed to svn
log
On Fri, Oct 10, 2008 at 8:03 AM, Tim Funk [EMAIL PROTECTED] wrote:
If we really prefer to be particular about change logs. Then we should
create a BUGZILLA VERSION called trunk and potentially a new product
called tomcat 7 (or tomcat-unknown). Then any fix first goes into Bugzilla
with a
On Thu, Oct 9, 2008 at 9:18 AM, Filip Hanik - Dev Lists
[EMAIL PROTECTED]wrote:
Costin Manolache wrote:
I never understood the use of the manual changelog - as opposed to svn log
and good commit messages.
Could we just use that ?
that would be nice if we then could generate the 'changelog
I never understood the use of the manual changelog - as opposed to svn log
and good commit messages.
Could we just use that ?
Costin
On Wed, Oct 8, 2008 at 4:24 PM, Filip Hanik - Dev Lists
[EMAIL PROTECTED]wrote:
I'd like for us to start using the changelog for trunk, we're losing a lot
of
Quick update: I've been working on the async protocol and the proxy,
cleaning up a bit and adding the POST support.
I think it's getting better, but I think I'll leave it in sandbox a bit
more, so the rest of the code gets used with the stable
connectors. IMO it's pretty cool - but not ready, want
Well, there is interest - the tomcat-lite in the sandbox does allow that (
there is even a TomcatLiteNoConnector unit test ).
The code is broken right now - in process of moving part of it to trunk and
adjusting it to be easier to digest. Will take quite a while
before it's ready for an official
was posting to the wrong group and chasing my tail with it.
--
Jess Holle
Costin Manolache wrote:
Well, there is interest - the tomcat-lite in the sandbox does allow that (
there is even a TomcatLiteNoConnector unit test ).
The code is broken right now - in process of moving part of it to trunk
There are few issues and questions, I'm not sure its as simple as it looks
:-)
For new development - are you going to make changes in both branches ? I
assume there will be
features that can only be done in 1.3.
Also, if we have separate releases of APR - are we going to release binaries
? For
On Fri, Oct 3, 2008 at 10:43 AM, Mladen Turk [EMAIL PROTECTED] wrote:
Costin Manolache wrote:
There are few issues and questions, I'm not sure its as simple as it looks
:-)
For new development - are you going to make changes in both branches ? I
assume there will be
features that can only
] wrote:
Costin Manolache wrote:
What is the apr version in common linux distros ?
Depends, Httpd 2.2.something+ relies on APR 1.3. SVN as well,
so eventually distros will pick it up.
Well, that's a bit tricky - people don't upgrade prod servers easily.
My concern is mostly about
On Thu, Sep 4, 2008 at 12:47 AM, Jason Brittain [EMAIL PROTECTED]wrote:
On Tue, Sep 2, 2008 at 8:20 AM, Costin Manolache [EMAIL PROTECTED] wrote:
On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk [EMAIL PROTECTED] wrote:
Costin Manolache wrote:
A LOT OF STUFF WHICH CAN BE FOUND IN THE ARCHIVES
On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk [EMAIL PROTECTED] wrote:
Costin Manolache wrote:
A LOT OF STUFF WHICH CAN BE FOUND IN THE ARCHIVES
Cool. In a nutshell - I like all the ideas.
But while I like the idea of ditching Valves/LifecycleListeners - how does
this work when the component
have a lot of new code, quite the opposite, most changes
will
remove code and features ( from the coyote-standalone and tomcat-lite target
).
On Sat, Aug 30, 2008 at 2:11 PM, Remy Maucherat [EMAIL PROTECTED] wrote:
On Fri, 2008-08-29 at 21:13 -0700, Costin Manolache wrote:
I think moving forward
Hi,
About 2 years ago (closer to 3) I started a sandbox experiment with the goal
of refactoring tomcat to a smaller
and easier to embed variant. I think it's time to see what can be
contributed back to tomcat main branch, what can be
released, and what needs to be retired or moved out.
The code
I'm curious - why do you think warp sounds 'better', or 'faster and more
efficient' than AJP ?
I don't remember any benchmark or major difference. And I think that was the
main reason
it was abandoned - it was just different, without 'better'. In fact there
were even talks to
abandon AJP - since
On Tue, Jul 22, 2008 at 10:17 AM, Filip Hanik - Dev Lists
[EMAIL PROTECTED] wrote:
As promised, here is the vote for inclusion of the bayeux toolkit
https://issues.apache.org/bugzilla/show_bug.cgi?id=45413
I think this toolkit should
[X] +1 include it as an independent component, I'm
On Thu, Jul 17, 2008 at 7:00 AM, Filip Hanik - Dev Lists [EMAIL PROTECTED]
wrote:
Remy Maucherat wrote:
On Thu, 2008-07-17 at 07:39 -0400, Yoav Shapira wrote:
On Wed, Jul 16, 2008 at 9:47 PM, Filip Hanik - Dev Lists
[EMAIL PROTECTED] wrote:
I'd like some feedback on the contribution,
Following Filip's example :-)
Please check http://people.apache.org/~costin/startup/ for a new class I
would like to add to tomcat(head), and an associated example/unit test. It
allows a jetty-like mode of programmatic loading/config of tomcat, without
any config file.
I know the 'official' way
Thanks, my +1 on committing it to tomcat, seems like a good start and a good
example on how to use the
async stuff.
Costin
On Thu, Jul 17, 2008 at 7:50 AM, Filip Hanik - Dev Lists [EMAIL PROTECTED]
wrote:
Costin Manolache wrote:
On Thu, Jul 17, 2008 at 7:00 AM, Filip Hanik - Dev Lists
I think this is a nice contribution ( haven't reviewed the code in detail
yet ), but seems like a separate enough feature
to be distributed as a separate/optional package.
I can't think of any good reason to include it in the base tomcat distro (
except that a lot of other stuff is there and
that
shouln't be used by apps.
A small automated test would be extra nice ( if you really want feedback )
:-)
Costin
On Wed, Jul 16, 2008 at 10:45 PM, Costin Manolache [EMAIL PROTECTED] wrote:
I think this is a nice contribution ( haven't reviewed the code in detail
yet ), but seems like a separate
On Wed, Jul 2, 2008 at 11:02 AM, David Jencks [EMAIL PROTECTED]
wrote:
On Jun 29, 2008, at 9:43 AM, Costin Manolache wrote:
Also, is there any documentation (or anyone who can explain)
DefaultInstanceManager.processAnnotations() ?
Sorry, I'm a bit confused, lots of calls and structures
the mail archives - the comments in the submits don't
seem to have more info than the javadocs or
comments... Again, sorry if it's something obvious.
Costin
On Sat, Jun 28, 2008 at 10:26 AM, Costin Manolache [EMAIL PROTECTED] wrote:
Hi,
Just one small 'feature' request:
Since InstanceManager
On Sun, Jun 29, 2008 at 10:45 AM, Filip Hanik - Dev Lists
[EMAIL PROTECTED] wrote:
here's some history on package etc
http://tomcat.markmail.org/search/?q=InstanceManager
Filip
Costin Manolache wrote:
Also, is there any documentation (or anyone who can explain
And if the TCK signature tests pass - that's a bug in the tests :-).
We shouldn't touch the method signatures in servlet API.
Costin
On Tue, May 6, 2008 at 2:03 AM, Remy Maucherat [EMAIL PROTECTED] wrote:
On Tue, 2008-05-06 at 08:27 +0100, Mark Thomas wrote:
I am leaning towards 4 on the
From Rainer's email few days ago:
http://svn.apache.org/repos/asf/tomcat/trunk/
I suppose after it's in it may be backported to the stable branches if it
works well and people like it.
Costin
On Mon, May 5, 2008 at 8:26 AM, Henri Gomez [EMAIL PROTECTED] wrote:
Providing in is just adding a
This is a proposal for a very small change in tomcat trunk, to make tomcat
easier to use with JConsole.
Right now if you start tomcat 'out of box' and than try to inspect it with
jconsole, you'll only see the 'platform' mbeans
(memory etc). That's because tomcat doesn't use the platform mbean
Sure - but as it is right now the .classpath file was broken, even if you
download the extra files - there is no mention of the jar.
The alternative fix would be to add the jars ( like we do for ant.jar,
eclipse, etc ) - but given the license and the fact that the default
build.xml excludes them
:-)
Kind regards,
Peter Kriens
On 30 apr 2008, at 19:28, Costin Manolache wrote:
On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens [EMAIL PROTECTED]
wrote:
Regarding HttpService - I don't think it's a good idea for tomcat.
One of the major problems with OSGI ( and we
We already have eclipse files checked in AFAIK - that counts as the second
build system.
We used to have makefiles too, also in parallel with ant (in 3.0 times).
The goal IMO is that people who like to type mvn can do it - without any
guarantee that
the result will be identical with the official
On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens [EMAIL PROTECTED]
wrote:
Regarding HttpService - I don't think it's a good idea for tomcat.
One of the major problems with OSGI ( and we need to make sure we don't
fall
in this trap ) is the re-invention of common APIs - logging, servlet
On Wed, Apr 30, 2008 at 11:31 AM, Filip Hanik - Dev Lists
[EMAIL PROTECTED] wrote:
Costin Manolache wrote:
We already have eclipse files checked in AFAIK - that counts as the
second
build system.
We used to have makefiles too, also in parallel with ant (in 3.0
times).
The goal
:
Costin Manolache wrote:
On Wed, Apr 30, 2008 at 11:31 AM, Filip Hanik - Dev Lists
[EMAIL PROTECTED] wrote:
Costin Manolache wrote:
We already have eclipse files checked in AFAIK - that counts as the
second
build system.
We used to have makefiles too, also
On Wed, Apr 30, 2008 at 5:32 PM, Filip Hanik - Dev Lists [EMAIL PROTECTED]
wrote:
Costin Manolache wrote:
Aren't we in 'comit then review' mode for the trunk ?
My understanding was that RTC is in effect for the stable releases, but
not
the trunk,
and if there is no controversy
BTW - can someone remove [EMAIL PROTECTED] from tomcat-dev ?
It's quite annoying, after each mail I get an auto-reply from them... I
don't think I have karma to do it.
Costin
On Wed, Apr 30, 2008 at 6:06 PM, Costin Manolache [EMAIL PROTECTED] wrote:
On Wed, Apr 30, 2008 at 5:32 PM, Filip
On Mon, Apr 28, 2008 at 11:25 PM, Peter Kriens [EMAIL PROTECTED]
wrote:
Tomcat to really make a lot of sense. Providing OSGi headers seems to
fulfill
the immediate need of several groups. However, it would be really nice if
you
could provide a service interface like an Http Service (Http
On Tue, Apr 29, 2008 at 1:44 PM, Remy Maucherat [EMAIL PROTECTED] wrote:
On Tue, 2008-04-29 at 22:09 +0200, Henri Gomez wrote:
Just a new thread to discuss about mavenizing Tomcat (OSGI Thread is
allready fully loaded and really interesting).
Costin told us he didn't want to change the
Well, IMHO the servlet spec is going from bad to worse in terms of
complexity and feature bloat, so
careful what you wish :-)
My point was mostly that we don't have to implement OSGI HttpService, it may
be ok to use them for
modularization but for servlet-specific APIs we should stick with the
On Fri, Apr 25, 2008 at 12:49 AM, David Jencks [EMAIL PROTECTED] wrote:
On Apr 24, 2008, at 11:11 PM, Henri Gomez wrote:
I've heard various claims of this nature from osgi zealots, but when
talking to apparent experts the only things resembling this they seemed
to
know about were
I'm not an expert, but I think I can tell you that yes, hello world
applications can be upgraded without stopping, real
applications can't.
As long as you use sessions or statics or you make config changes -
you have to restart the webapp.
OSGI is good of having 2 versions of a bundle running at
On Wed, Apr 23, 2008 at 4:35 AM, Remy Maucherat [EMAIL PROTECTED] wrote:
On Tue, 2008-04-22 at 12:45 +0200, Henri Gomez wrote:
Hi to all,
Did there is plans, ideas or interest around about OSGI-fing Tomcat ?
The only thing which ever attracts you is pointless hype, it's quite
funny
I don't know if you noticed, but I have not really been participating in
Tomcat's trunk development for months, and am only dealing with Tomcat
6.0. In trunk or any other future developments, at the moment my plan is
only to comment (pretty much like Costin does).
I'm actually working in
Well, adding OSGI-compatible manifests to the existing jars is not
that intrusive,
and could be easily done in the trunk. AFAIK an Activator is not required - i.e.
if you don't need the BundleContext or to add services, you can have a bundle
that just imports/exports packages.
I agree with Remy
On Wed, Apr 23, 2008 at 8:36 AM, Henri Gomez [EMAIL PROTECTED] wrote:
Silly question, but did experiments with OSGI could be done, first, in
tomcatlight ?
I'm not sure it's the best idea, my goal is to move it out of sandbox,
it already has enough experiments
that need completion. and the
First define 'mavenizing' please :-)
If you mean exporting tomcat components in maven repository - fine with me.
If you mean building tomcat with maven instead of ant - the opposite,
absolutely not fine.
Maintaining a separate maven build file - unofficial, i.e. the default
build instructions
On Wed, Apr 23, 2008 at 1:17 PM, Henri Gomez [EMAIL PROTECTED] wrote:
First define 'mavenizing' please :-)
Yes
If you mean exporting tomcat components in maven repository - fine with
me.
It's allready done (by hand) ?
If you mean building tomcat with maven instead of ant -
On Wed, Apr 23, 2008 at 1:38 PM, Henri Gomez [EMAIL PROTECTED] wrote:
And that would be the reason for -1.
If a build system requires intrusive changes and forces a particular code
organization - it shouldn't be used.
that's maven phylosophy, not so bad.
The layout may be good (
I think OSGI has some good ideas - it is pretty good at handling class
loaders and loading/unloading modules. On the other side, they are
very 'framework' - and like all other frameworks you have to do all
things their way and they re-invent a lot of wheels ( from logging
APIs to almost
Well, if the _server machine_ is running out of memory - I think
Yourkit/Jprofiler or most java options won't help.
Just make sure you do have the -Xmx option in tomcat - and it's
reasonable ( less than 1/2 of total RAM I would guess ).
Java is very good at using -Xmx for the heap - I never seen
I had this on my computer for a while, moved at very slow pace over
the years - but it passes all 'watchdog' servlet and most jsp tests.
I'll post more when I finish sumitting.
Costin
On 3/25/08, Henri Gomez [EMAIL PROTECTED] wrote:
Added:
Speaking of deps - I'm completely confused by tomcat-dbcp.jar - it
seems to break the build ( 'download' ) with JDK1.6, yet I can't find
that's because DBCP implements interfaces, and only implements the
java.sql/javax.sql up to JDK 1.5.
any usage in the code - and just removing it
What's the current status of commons-logging versus juli/logging ? Do
we still need the dep ?
Speaking of deps - I'm completely confused by tomcat-dbcp.jar - it
seems to break the build ( 'download' ) with JDK1.6, yet I can't find
any usage in the code - and just removing it doesn't seem to hurt
On 3/3/08, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
Costin Manolache wrote:
On 3/3/08, Remy Maucherat [EMAIL PROTECTED] wrote:
On Mon, 2008-03-03 at 15:58 -0700, Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
This problem is a small detail. Much more should
+1
4 years ago the last version, about 8 years ago the first (or 3.0)
release...
I wish we also had a '6.x-minimal' release for people wanting something very
small ( and not using jetty ).
Costin
On Thu, Feb 14, 2008 at 4:05 PM, Mark Thomas [EMAIL PROTECTED] wrote:
All,
The last 3.x release
+1
Are you going to make any difference between 4.0.x and 4.1.x ? I think we
should drop 4.0.x sooner.
Costin
On Thu, Feb 14, 2008 at 4:12 PM, Mark Thomas [EMAIL PROTECTED] wrote:
All,
Tomcat 4 has been in maintenance mode for some time now with nearly all
changes either updating libraries
Yes, JVM is not so good because it changes, I agree /usr/local/lib ( and the
JVM dir ) are only good for people with root access.
What about having 2 options:
- 'system' installation - /usr/local/lib
- 'local' - TOMCAT_HOME/lib/native ( or TOMCAT_HOME/lib/`arch` if same
install is shared on
Nice.
Few small suggestions:
- for users of ubuntu ( and probably some rpm-based distro ) - it would be
good to include the packages they should install first and have a specific
example.
apt-get install libapr1.0-dev libssl-dev
...
(specific command flags )
It would be even better to have a
Will we have installers for it ? Will the installer/release include the
associated libapr ? I assume both native and java
code will be included ? What additional docs will be needed ? Will tomcat
releases bundle it, or just require to download it separately ?
It would be great to have it as
On Nov 8, 2007 6:15 AM, Yoav Shapira [EMAIL PROTECTED] wrote:
Hey,
On Nov 8, 2007 9:10 AM, Alexey Petrenko [EMAIL PROTECTED]
wrote:
I want to suggest you to create Tomcat out of the box bundle on top of
Harmony.
I've created such a bundle with the previous Harmony milestone release
What is apache doing ? Better be consistent, both sides (log or no log) have
value.
( log - good to know it's happening, no-log - don't want to fill the logs
with garbage if they do it from lots of machines / drones )
Costin
What is
On 10/21/07, Rémy Maucherat [EMAIL PROTECTED] wrote:
On
'bytes' should be counted at a lower level, in connector. I'm not sure this
is something generic enough - but you can make some changes to your tomcat,
where read() is done from socket.
I guess it would be nice to have a JMX graph with bytes/sec in/out.
Costin
'bytes'
On 10/22/07, Dave Rathnow
at connectors but wasn't sure if this was what I wanted. To
avoid anther wild goose chase I decided to ask. Can you point me in the
direction of some documentation where I might be able to get started?
Dave.
-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Sent
-0
The setProperty was done way before JMX, and it's quite hacky. I think
standardising on JMX-like model is better - i.e. if we make changes to
setProperty and connector configuration, it should bring it closer to JMX.
In JMX we have a void setAttribute(...) throws AttributeNotFound, plus a
On 10/18/07, Paul Shemansky [EMAIL PROTECTED] wrote:
On 10/17/07, Costin Manolache [EMAIL PROTECTED] wrote:
But if you want to create a maven build file ( or a Makefile, or
eclipse/netbeans projects, etc :-) that builds tomcat - I personally
don't
see a problem with that - as long
-1 as well on switching to maven as default ( or back to many source tree
'modules' ).
But if you want to create a maven build file ( or a Makefile, or
eclipse/netbeans projects, etc :-) that builds tomcat - I personally don't
see a problem with that - as long as it doesn't require moving code
Not sure where is the dependency between sorting out the Comet strategy and
implementing
any new protocol or any new connector.
I think if there is interest - it can and should be pursued, would be a good
start to see
if the 'scratch your itches, but not in the core distro' works out :-). It
On 9/28/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
you build the bayeux servlet crap on top of the Comet processor, its not
a protocol over TCP, its a protocol over HTTP, but requires the ability
to do async servlet, ie to cut of the dependency between the tomcat
worker thread and
+1
On 9/22/07, Jim Jagielski [EMAIL PROTECTED] wrote:
On Sep 22, 2007, at 9:45 AM, Jim Jagielski wrote:
[X] +1. Yes, the above works and addresses my concerns
as well as the problems which started this whole
thing.
[ ] 0. Whatever.
[ ] -1. The above
101 - 200 of 369 matches
Mail list logo
