--- Larry Isaacs [EMAIL PROTECTED] wrote:
Hi Costin,
Good to see you back.
FYI: My helper\SessionUtil.java is still looking for
SessionIdGenerator.generateId(). Did you mean to
commit SessionUtil.java
too?
Yes, but there are few other changes and I need to
"serialize" the commits.
My intention was to make sure we all agree about what
goes into 3.3, and we all agree that those changes are
not just "feature-ism", but things that will give us
a better tomcat.
Please review the list of changes - I'm willing to
undo any of them if you have good arguments or a
better solution (
One problem I have with the patches ( and I sent a
reply to Pilho Kim the first time he posted the
patches) is the impact on performances.
The least we can do is to detect if the encoding is
compatible with ASCII ( or UNICODE ) and use the
getBytes() only if it isn't. The method has a big
Hi Jon,
First, I want to thank you for the advices and your
mail - even if I don't like what you say I do believe
that your mail have some good things for me.
It really scares me that you are the only person (as
far as I can tell) that is seriously interested in
? maintaining and developing
Hi,
I am able to compile Apache2.0, and I updated mod_jk
for the modified functions in 2.0 - it now compiles.
I'm pretty confident we can have it running in few
days - it did worked before and it works fine with
other multithreaded servers. As you can see, most of
the code in mod_jk is
I don't agree. TC3.3 is a rewrite of TC3.2, with all
of the TC4 "fancy features" (and some more).
3.3 is not a "rewrite" of 3.2 - some code was moved
for better organization and modularity, and we
finished a number of optimizations that were started
during 3.2 development.
Yes, a lot of code
I wish people would pay more attention to what the
overall issues are
instead of focusing on entirely the wrong things.
+1 on this
The issue is the idea of a 3.3 and I'm not saying to
"jump" to 4.0.
I don't see how did you created a "3.3" issue -
tomcat3.x development continues as it
they were. Jon, you might
be annoying and obnoxious at times, but those kids
don't even care about reading what you're writing...
Too bad all this is on an open mailing list where the
mails can be read again and again - and people may
form their own opinions.
_exactly_ happening: from
Way back to technic ;-)
Great too see that.
May be the last time :-(
I hope not - it's great working with you :-)
- it's not a bad idea - as long as it's an option
That's could be a secured ajp13 or ajp14 ?-)
AFAIK ajp13 can be extended in a backward-compatible
way ( or at least
Perhaps there are two i18n improvements in Servlet 2.3 and JSP 1.2:
1, javax.servlet.ServletRequest#setCharacterEncoding()
2, pageEncoding attribute of Page directive
Alternative workarounds in these two points makes non-ASCII users
happy.
What I'm saying is that instead of
--- Alex Fernández [EMAIL PROTECTED] wrote:
I think the benchmarks are very interesting. Unfortunately, the
results from HelloWorld don't seem too revealing.
Depends what you want to measure - HelloWorld shows one number, the
container overhead. For any servlet that does something more you'll
On Mon, 2001-09-10 at 16:40, Pier Fumagalli wrote:
A third one could be an API merger between the two... If you want
to talk
about it...
No, I meant between JK and WebApp... :)
Well, webapp has a very nice protocol - it would be a great addition to
jni, ajp12, ajp13 and ajp14. And I
+1
Costin
--- GOMEZ Henri [EMAIL PROTECTED] wrote:
I would like to propose Mike Anderson as a new committer.
He found many subtils bugs in mod_jk and since he's
working on Netware platforms, it will a great help
to improve connectors on this OS.
Vote please
-
Henri Gomez
1 is very bad, it would alter the history.
I would go with 2, but I'm not sure it's an import but regular
cvs add ( import is used to create new repositories AFAIK ).
Costin
--- kevin seguin [EMAIL PROTECTED] wrote:
i'd be tempted to go with 1), but i like to live on the edge ;-) the
cvs
FYI,
I'm not planning any major changes in the near future for jasper34. I'm
reasonably happy with the first round of cleanup and refactoring, and I
think we are moving in a good direction with the toolkit-isation of
jasper and the various optimizations we discussed.
I want to let the code
Hi Kevin, Henri,
I will spend some time on the connector and can help a bit with
that too.
Merging should be reasonably easy, but I would like to keep a backup,
i.e. do the merge in a new file.
Kevin - what about doing the merge as part of Ajp14 ? It should be able
to handle ajp13 requests
On 18 Aug 2001 19:56:33 +0200, Paulo Gaspar wrote:
I have been trying to improve a bit on the admin
application, especially on the contextAdmin bit,
tweaking its web pages/JSPs in order to add functionality
and ease of use.
Great :-)
I am especially interested on making it easier to
On 20 Aug 2001 02:01:12 +0200, Paulo Gaspar wrote:
Your explanation sure helps understanding what functionality is intended
for each tag. I can take a look at that too. It is easier for me to
understand the taglibs than the rest of Tomcat.
=;o)
Well, I hope understanding the rest of tomcat
Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ?
AFAIK JAAS is included in JDK1.3+ - and available to older VMs.
The only problem is getUserRoles(), which is not supported very well
by JAAS.
I'm fine with implementing them as valves
Jeanfrancois Arcand wrote:
Costin Manolache wrote:
Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ?
AFAIK JAAS is included in JDK1.3+ - and available to older VMs.
I agree on JAAS too for Authentication if it is available
It seems I missread your post, I tought you would add another
authentication interface too ...
But I still don't like the interface :-)
I need to think about it.
I'm pretty sure we can use Policy, Permission, etc without a security
manager, and it would be better to go directly to use those.
the security manager ).
Costin
Costin Manolache wrote:
It seems I missread your post, I tought you would add another
authentication interface too ...
But I still don't like the interface :-)
I need to think about it.
I'm pretty sure we can use Policy, Permission, etc without a security
Jeanfrancois Arcand wrote:
Where the permission object will be created? In Authenticator? I would
prefer delegating the permission to Authorization interface (but I can
live it :-) ). There is also another problem. If the permission is not
granted, the method will return false. Then we will
Remy Maucherat wrote:
The mapper has a currently unused dependency on JNDI, and I plan to put
it in the org.apache.tomcat.util.http.mapper package.
JNDI deps are fine - dependencies on org.apache.naming are not very good
( since tomcat can be used in an app that uses a different naming impl ).
Remy Maucherat wrote:
Speaking of which, I'm missing a registration for the hosts (I don't
know if it's defined in JSR 77).
Could we add some custom attributes on the object name for wrapper
(giving the mapping), as well as the host registration, and still comply
with the spec (I'd say yes,
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
The mapper has a currently unused dependency on JNDI, and I plan to put
it in the org.apache.tomcat.util.http.mapper package.
JNDI deps are fine - dependencies on org.apache.naming are not very good
( since tomcat can
Jeanfrancois Arcand wrote:
If we look at JSR115, it sugests creating several (3?) permission objects
- each will be associated with the request.
The creation of those objects will be part of the container ( probably in
a valve or other module ).
The point is that all _authorization_ decisions
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Cast the notification to MBeanServerNotification :-)
Ok, it sort of works now.
The remaining problems:
- some attributes need to send JMX notifications (welcome files,
mappings, etc) so the mapper can be updated
Remy Maucherat wrote:
Remy Maucherat wrote:
BTW - I assume you read the discussion on authorization - the problem
is the same ( mapping requests URIs to constraints ), it would be good
if we can reuse some code.
The mapping code is generic. I was thinking about having the mapper do
Remy Maucherat wrote:
Costin Manolache wrote:
If the question is about using JMX1.2 - it was alredy proposed, and it
seems nobody objected ( but nobody did it either ). If you want to do
that - all you need is update the mbean descriptors, and change all the
arrays to use the JNI names
Remy Maucherat wrote:
Tim Funk wrote:
Tomcat5 does not compile with JDK1.3. It does with JDK1.4.
There is only one line of code that prevents it from compiling with
JDK1.3. org.apache.catalina.loader.WebappClassLoader depends on
File.toURI() which does not exist on jdk1.3.
I got around
Tim Funk wrote:
After looking at the older revisions, I agree my patch was stupendously
horrible :(
The patch now uses reflection to keep the current code equivalent for
jdk14 and use the old way in case of a jdk1.3 jvm.
That being said - I would assume that the RMI issue your patch
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Tim Funk wrote:
Tomcat5 does not compile with JDK1.3. It does with JDK1.4.
There is only one line of code that prevents it from compiling with
JDK1.3. org.apache.catalina.loader.WebappClassLoader depends on
File.toURI
of myself and should I be patient and wait for
someone with better insight to do this instead?
You seem to have good insight, please do it.
Costin
-Tim
Remy Maucherat wrote:
Costin Manolache wrote:
Tim Funk wrote:
Oh, NO. Please don't even think about it Commons-dbcp must do
this is for servetapi_4.
Same applies to servletapi_5 ( I already sent a patch few weeks ago ).
The problem is that JDK1.4 stack traces can't find the root cause.
AFAIK nothing in the servlet or JSP specs requires breaking the normal
contract for exceptions - which is to pass the root cause to
Nielsen wrote:
BTW, this does not build with JDK's 1.4 and if you use a servlet.jar
built with 1.4 in a JVM 1.4 you get a NoSuchMethodError.
This change for jakarta-servletapi-4 need to reverted for now.
Glenn
Costin Manolache wrote:
this is for servetapi_4.
Same applies
,
-- Jeanfrancois
Glenn Nielsen wrote:
BTW, this does not build with JDK's 1.4 and if you use a servlet.jar
built with 1.4 in a JVM 1.4 you get a NoSuchMethodError.
This change for jakarta-servletapi-4 need to reverted for now.
Glenn
Costin Manolache wrote:
this is for servetapi_4
jean-frederic clere wrote:
Remy Maucherat wrote:
jean-frederic clere wrote:
Remy Maucherat wrote:
Hi,
I plan to tag 4.1.20 later today. Thanks to Glenn and Jan for getting
some good fixes in.
I would like to add some changes in Manager:
For example to add createEmptySession that
Amy Roh wrote:
I have investigated further and found out that
GlobalResourcesLifecycleListener is not creating mbeans for userdatabase
anymore, therefore, admin failure due to missing mbeans.
Costin,
Do you have a better idea why Userdatabase MBeans are not getting
created anymore since
Thanks Amy.
Costin
Amy Roh wrote:
Amy Roh wrote:
I have investigated further and found out that
GlobalResourcesLifecycleListener is not creating mbeans for
userdatabase anymore, therefore, admin failure due to missing mbeans.
Costin,
Do you have a better idea why Userdatabase
I suspect it's a windows specific return code from recv().
The code in question calls socket_recvfull - which in turn calls recv()
to fill a buffer. It handles EAGAIN - but knowing windows, it may be
something else.
If you can do a checkout from HEAD and built again - you should see
the errno
Remy Maucherat wrote:
Jeanfrancois Arcand wrote:
Are you able to build it? The nightly build failled with the following
(see below). I will look at the failure latter this afternoon...
It's a hint that there are urgent bugs to fix in either JspC or Jasper,
which make precompilation fail
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Jeanfrancois Arcand wrote:
Are you able to build it? The nightly build failled with the following
(see below). I will look at the failure latter this afternoon...
It's a hint that there are urgent bugs to fix in either
Kin-Man Chung wrote:
It seems to be introduced by one of the recent changes - I had no
problem compiling the admin few weeks ago. We either roll back the
change or find another way.
The bug happens in the jsp-examples precompilation (which is supposed to
work also, right ?). One of the
Remy Maucherat wrote:
Filip Hanik wrote:
yes, you are right, how do I subscribe to this event?
I know that the server has a addLifeCycleListener, but how do I access
the server from a cluster object for example?
You can go up the tree, I think, but otherwise, you can just use
Kin-Man Chung wrote:
It seems the new spec revisions mean more complex + more bloated :-(
This is quite disappointing ...
Isn't that always true? :-) You need to add new features but cannot
remove old ones.
You can allways side-step and create a new specification for the new
features.
Henri Gomez wrote:
Remy Maucherat wrote:
Henri Gomez wrote:
It seems that latest JTC / CATALINA require now a post 1.0 modeler.
Did there is release plan for modeler 1.1 ?
I think it'll be better called 2.0 - there are many big changes ( even
if it should be backward compatible ).
The
Remy Maucherat wrote:
Ok, I saw your commit.
Now that I think about it, I'd like to include a build script for the
new clustering features, and include them in the release (so it's
delayed for one additional day).
Can we postpone it till Monday ? I want to get the embed/ working too,
I just
Henri Gomez wrote:
From what I see, it seems we also need ant HEAD to compile
parts of JTC (JndiProperties).
Did this stuff will be in ant 1.5.2 release ?
JndiProperties is not required for anything - it's part of a refactoring
of naming, but we don't use it in any way. It shouldn't be
Jeanfrancois Arcand wrote:
BTW - in order to release modeler we need at least 3 +1 votes - so far I
feel a bit alone :-) Is anyone else interested in this piece ?
I am :-) If I can collaborate, guide me to what we need to do for
releasing it :-)
I don't know :-)
I'm just fixing itches as
Sven Köhler wrote:
There is another problem with how mod_jk handles the ajp connetor
sockets. That is the one to one mapping of apache child process to an ajp
connector. On an apache server that serves normal http requests you can
end up with many idle socket connections to Tomcat, and Tomcat
Remy Maucherat wrote:
ballot
[ ] Alpha
[ ] Beta
[X] Stable (GA)
/ballot
Please vote (after testing the release, if possible ;).
It works for me. It would be nice to fix the jspc bugs tough.
I fixed a small regression in modeler(HEAD) so it can be used as drop-in
replacement ( if you have
Sven Köhler wrote:
I took a short look at the ajp13 protocol draft, and the design of the
protocol is really simple, too simple.
There are few knwon problems with the protocol - both sides of jk2 are
designed to support multiple protocols and extensions.
yes, but how? how can either client
Sorry, my previous mail got a bit long ( and a bit unfriendly :-)
The short version:
There are 3 ways to extend jk2:
1. With a completely different protocol module - marshalling and all low
level stuff. I'm +1 on such a thing if the new marshalling is a standard
one - and I think XDR is the right
I would really apreciate if someone could check how this works.
The steps are:
- compile
- make sure /jkstatus is enabled and works
- configure jk2.properties:
class.modjkmx=org.apache.jk.common.ModJkMX
modjkmx.webServerHost=localhost
modjkmx.webServerPort=80
mx.port=
- start apache
-
Sven Köhler wrote:
3. On top of regular request/response. Almost everything related with
auth, pings, discovery, reconfiguration can be implemented by just using
regular Ajp13 requests - with a special URL. That is by far my favorite
mechanism. It also has the advantage that it can reuse
Sven Köhler wrote:
...
special URLs are by far the best mechanism?
the next simpson-episode should start with bart writing special urls
are by far the worst mechanism ever to the board.
it's working around a missing feature - nothing more, nothing less.
it's the worse method i could
Bill Barker wrote:
Once I have time to go through and patch the regression failures for Jk2,
maybe I'll test the new features. Until then, I'm strictly a Jk1 person.
What failures do you have ?
I've used jk2 on my machine for the last 3-4 months without any problem
( it is true, I don't get
Hans Bergsten wrote:
Good. For JspC, I think there are more urgent problems than the tag
related problem, such as the mangling issues which just got fixed in
Tomcat 5. That's why I didn't bother trying to apply whatever patch was
needed for tags, knowing it would still be broken.
Well, if
Hans Bergsten wrote:
You are a tomcat committer just like Remy or everyone else. Commit
the fix - and if someone has a problem with it he can -1 and
propose a better solution.
Yes, I am, but it's been years since I committed anything and my
environment is not set up for it. I simply don't
Remy Maucherat wrote:
Hi,
I proposed that to Costin a few days ago, but got not so enthusiastic
comments.
The idea would be to add a new monitor servlet to the manager webapp. It
would generate data similar to http://www.apache.org/server-status. It
would mostly (exclusively ?) use JMX to
Remy Maucherat wrote:
Well, I indeed have a few things on my task list, including:
- new static resource cache (the current one is inefficient both in
terms of syncing and memory management)
Any chance you'll make this a bit more independent of the internals -
I tried to do a bit of
Henri Gomez wrote:
Henri Gomez wrote:
Hi to all,
Some of my friends in the jpackage project have problems with the
way tomcat4 start/stop.
There is case where a catalina.sh stop didn't stop a running tomcat.
In such case a restart (stop/start) failed.
I proposed them to works on a
Remy Maucherat wrote:
Costin Manolache wrote:
Henri Gomez wrote:
Henri Gomez wrote:
Hi to all,
Some of my friends in the jpackage project have problems with the
way tomcat4 start/stop.
There is case where a catalina.sh stop didn't stop a running tomcat.
In such case a restart (stop/start
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
costin 2003/03/07 22:52:36
Modified:coyote/src/java/org/apache/coyote/tomcat5
MapperListener.java
Log:
A Server is not required for non-standalone operation. In fact, Embeded
doesn't define
a
Bill Barker wrote:
Index: CoyoteConnector.java
===
@@ -1062,11 +1062,12 @@
* Initialize this connector (create ServerSocket here!)
*/
public void initialize()
-throws LifecycleException {
Henri Gomez wrote:
Henri Gomez wrote:
Remy Maucherat wrote:
Tomcat 4.1.22 Alpha is now available for testing.
Changes over 4.1.21 include:
- Fix for mangling with JSPC
- Fix precompilation with tag libraries packaged in JARs
- Fix JDBC store thread safety bug which was causing improper
Alexander Leyke wrote:
I am a developer at AOL and have been recently working on a JK2 family
module for AOLserver. The module is ready now and I'd like to take steps
necessary to contribute the sources to Tomcat project. I read the
Just send the patches and the new files. You can open an
[EMAIL PROTECTED] wrote:
amyroh 2003/03/10 19:25:52
Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanFactory.java ServerLifecycleListener.java
Log:
Set to use JSR77 names as default.
Please make sure tomcat 5 is also updated.
I would do
Henri Gomez wrote:
Did some of you ever think that Tomcat could became a
direct Apache subproject, like ant ?
It seems Maven follow the same way.
As such having Tomcat as a direct Apache projects will
allow a Tomcat PMC ?
Costin, Remy, other commiters, what do you think ?
I'm
Amy Roh wrote:
[EMAIL PROTECTED] wrote:
amyroh 2003/03/10 19:25:52
Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanFactory.java ServerLifecycleListener.java
Log:
Set to use JSR77 names as default.
Please make sure tomcat 5 is also
Hi,
I'm close to get JAAS realm and the memory LoginModule working - if I
remember correctly we agreed to make JAAS the default for 5.0 ( I don't
remember any objections ).
I never tried it in 4.x - but from the code and code I strongly doubt it
works.
There is one change I would like to make.
.
we don't want that to happen to us, do we :))
I don't think we'll be affected :-), but it may fix the jboss bug ( if they
switch to using the built-in tomcat JAAS realm )
Costin
Filip
-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March
I think it is reasonable to fix it.
This can be serious - if someone relies on application isolation ( like
a hosting environment ), the consequences can be really bad, with
one webapp guessing the credentials of another one.
The fix seems reasonably simple and clean.
Costin
Keith Wannamaker
Bill Barker wrote:
I think it is reasonable to fix it.
This can be serious - if someone relies on application isolation ( like
a hosting environment ), the consequences can be really bad, with
one webapp guessing the credentials of another one.
The fix seems reasonably simple and clean.
Amy Roh wrote:
It makes sense to use different domain names instead of using service
name. It'll take lots of code change in admin to change all the
objectnames to get rid of service name though. *sigh*
I think a bit of grep can do the magic :-)
It's not a big hurry. I'll start changing
Remy Maucherat wrote:
+for( int i=0; irepositories.length ; i++ ) {
+sb.append( repositories[i]).append(:);
+}
I think your should use the path separator here.
You're right. I put it in mostly for debug. I'll fix it.
Costin
Jeanfrancois Arcand wrote:
Hi,
I'm close to get JAAS realm and the memory LoginModule working - if I
remember correctly we agreed to make JAAS the default for 5.0 ( I don't
remember any objections ).
What about authorization :-) Righ now, the Realm implementation includes
the 3 authorization
Reinhard Moosauer wrote:
Additional information:
Without virtual host I got the request mapped. But no answer but
a segmentation fault .. child .. in apache's error_log
Can you send a stack trace ?
I'm checking the hosts problem.
Costin
thanks,
Am Mittwoch, 12. März 2003
Remy - in the build process for 4.1 ( and 5.0 ), are you using anything
but the download targets ? Can you make sure you do the builds on a clean
workspace ?
Right now 4.1 clean build fails - fileupload is not downloaded.
I'm trying to do full builds of both on a clean machine.
Costin
Remy Maucherat wrote:
Costin Manolache wrote:
Remy - in the build process for 4.1 ( and 5.0 ), are you using anything
but the download targets ? Can you make sure you do the builds on a clean
workspace ?
Right now 4.1 clean build fails - fileupload is not downloaded.
You know, 4.1's
[EMAIL PROTECTED] wrote:
remm2003/03/12 13:32:50
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- If init needs guards against being invoked twice, this also needs it.
- Any explanation why, BTW ?
The general
[EMAIL PROTECTED] wrote:
billbarker2003/03/12 22:17:53
Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java
Log:
Initial support to do a redirect to a directory where the URL doesn't
end in '/'.
This prevents browsers from becoming confused when they get
When we add a new dependency to the code, we should:
1. Update gump
2. Make a small proposal and get a vote
3. Use conditionals if the dependency is not required and update download
target
Dependencies are very important and affect everyone.
I don't remember when fileupload was added to
What OS ?
I added strerror - so if you update you may get better error number on
receiving message body.
Regarding ajp_process_callback: that's most likely a user hiting BREAK
on the browser. I downgraded the message to debug, it is a normal case.
How loaded is tomcat ( number of requests
Few questions ( and thanks for the help ).
[EMAIL PROTECTED] wrote:
!-- If not set explicitely in one of the user overrides, set it here
--
- property name=base.path location=../repository /
property file=build.properties.default/
Ok - what is the base.path you use
Logging: I double fixed it, there was an missmatch with the logging
build.xml ( I fixed that ), and I also removed the build, logging is
stable and released.
We should only build the dependencies that are not stable and we may
need to change - el, modeler, daemon.
Regarding modeler: do an
Remy Maucherat wrote:
Well, the build is still broken for me. commons-logging inists on being
built in ${tomcat.build} instead of ${tomcat.build}/common/lib and
${tomcat.build}/server/lib.
What's the point of the updated build ?
The point of the updated build is to get some consistency.
Remy Maucherat wrote:
Costin Manolache wrote:
When we add a new dependency to the code, we should:
1. Update gump
2. Make a small proposal and get a vote
3. Use conditionals if the dependency is not required and update download
target
Dependencies are very important and affect everyone
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Well - I tought the rule is that we can't release with dependencies on
unreleased or beta code.
And HTMLManagerServlet was supposed to be a simple servlet - it now has
dependencies on fileupload and that is forced
Forgot to include: the patch was submited by Stefan Proels.
Costin
[EMAIL PROTECTED] wrote:
costin 2003/03/13 16:03:03
Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java
Log:
Extra fix - avoids the need for a change in Response
PR: 14292
Revision
Mladen Turk wrote:
Hi,
I was wondering if we can add the '-shutdown portnumber' to the
catalina's command line parameters.
The usage would be to enable multiple TC instances using the same
server.xml file.
If present the param would override the config's Server port=8005
For 4.1.x or
Remy Maucherat wrote:
Here's my own failure, trying to run ant download:
jar:
[copy] Copying 1 file to
L:\home\tomcat-5\jakarta-servletapi-5\jsr154\build
[jar] Building jar:
L:\home\tomcat-5\repository\servlet-api-2.4\lib\servlet-api.jar
BUILD FAILED
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
costin 2003/03/14 07:28:06
Modified:.build.xml
Log:
Trying to guess what's wrong on Remy's machine.
The APIs are built in download as dependencies, no need to build
them twice.
I don't know what's wrong. I
Remy Maucherat wrote:
Glenn Nielsen wrote:
There was a bug fix to JDBCStore after 4.1.22 was built.
I think we need a 4.1.23 build for stable.
Sorry!
No problem.
Since you're at it, could you remove the fileupload related
functionality from 4.1.x ?
Big +1 !
Costin
Glenn Nielsen wrote:
It has been a while since a mod_jk 1.2 release was done.
There have been a number of bug fixes and a few minor feature
enhancements.
I just did some commits to fix some bugs I was seeing with mod_jk 1.2 and
Apache 2.0. Some of these will also improve the connector for
Glenn Nielsen wrote:
Remy Maucherat wrote:
Glenn Nielsen wrote:
There was a bug fix to JDBCStore after 4.1.22 was built.
I think we need a 4.1.23 build for stable.
Sorry!
No problem.
Since you're at it, could you remove the fileupload related
functionality from 4.1.x ?
If
Glenn Nielsen wrote:
Beta != release.
And no, that's not the main reason. If you need the manager to include
fileupload - than place it in WEB-INF/lib, don't bloat server/lib.
The /admin doesn't place struts.jar in server/lib.
That can be done. But I will also have to move the
Was jsr154 compiled correctly ?
Do you have it in your repository ?
Can you include the full build log - it's impossible to guess from a
fragment.
Costin
Filip Hanik wrote:
ant download
BUILD FAILED
file:C:/Development/jakarta-servletapi-5/jsr152/build.xml:72: Compile
failed; see the
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
costin 2003/03/14 14:42:43
Modified:.build.xml
Log:
Fix Filip's build.
It seems my clean workspace wasn't that clean after all.
This whole thing is unbelievable. I have no idea how we end up with
this
1 - 100 of 737 matches
Mail list logo
