Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?

[Bill Barker]

I'm pretty much going to agree with Costin on this one.  I have no objection 
to having a maven build as an alternative to the ant build (assuming that it 
can do the same thing, which I don't really believe without seeing the pom). 
But most mavenized projects that I have see (e.g. apache-commons) seem to 
spend much more time on the pom then on the actual module code.  And most of 
the look-feel of mavenized project's websites frankly s*ck.

Personally, I consider maven to be a virus (downloading files onto my 
computer without my permission).  M1 is difficult to configure to always run 
offline, and M2 is close to impossible.

"Costin Manolache" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> -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 around
> and can play nicely with the current code layout and other build tools. I
> think the 'official' way to build tomcat should remain ant ( at least 
> until
> any potential replacement has a large mileage ), but having other 
> alternate
> build tools can't hurt.
>
> I'm quite happy using mostly eclipse - I hardly ever use ant ( mostly to
> generate jars and move code around ), the auto-recompilation and fast
> run/debug/hot-replace in eclipse are saving me a lot of time, but if
> something faster emerges I'll try it.
>
> Costin
> -1
>
> On 10/17/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
>>
>> lemme give you my feedback and some history
>>
>> Paul Shemansky wrote:
>> > Dear Fellow Tomcat Developers,
>> >
>> > As you may have already noticed, I recently joined the ASF and the
>> > Tomcat Developer's List.  I have been a Maven 2 user since 2005, and I
>> > previously used Ant for all of my projects.  I suffered through many
>> > hardships migrating from Ant to Maven, but in my humble opinion, it
>> > was well worth it.  I believe that the Tomcat build can certainly
>> > benefit from some of the key features of Maven 2 mentioned below.
>> >
>> > It is not my intention to start a flame war between Ant and Maven
>> > users, but merely to propose Maven 2 to this group, and respectfully
>> > use this thread to discuss the advantages and disadvantages of
>> > switching Tomcat's build process within the 6.0.x or possibly 7.0
>> > release schedule. Please use this thread to voice your opinion.  Reply
>> > to this message with any comments, and/or simple votes for or against
>> > the migration to Maven 2.
>> >
>> > If by some odd chance you have never seen or heard about Maven 2,
>> > please visit and explore :
>> > http://maven.apache.org/
>> >
>> > Key features that may be useful to us are :
>> >
>> > - The Standard Directory Layout - Specifically, multi-module builds.
>> > This might make managing individual components easier for catalina,
>> > coyote, naming, jsp/servlet api/implementation, connector, etc.
>> >
>> we just refactored everything from being "component/module" based into a
>> single source tree.
>> Everyone at the time agreed that it would make life easier, for me
>> personally, it was a huge improvement.
>> > - Model-Based builds - Automatic packaging for the individual modules.
>> >
>> not sure what this is, even though we have a single source tree, we do
>> generate a list of jars.
>> > - Dependency Management - Whether it is Apache or another third-party,
>> > dependencies can all easily be plugged in.
>> >
>> we do that today, crude but working, ANT just adopted Ivy, a dependency
>> manager for ANT.
>> > - Distribution Management - Packaging and Deployment - Although Tomcat
>> > has a structured distribution model with Ant, Maven could make this
>> > easier with its assembly plugin.  This also allows outside entities to
>> > easily embed specific Tomcat components or customize the server to
>> > suit their needs, (i.e. containers like Geronimo and JBoss, IDE
>> > plugins for Eclipse or Tomcat.)
>> >
>> We currently have a "distribute to Maven repo" in place.
>> The most current version is in the sandbox, that would allow us to
>> publish to the central ASF repo with signed JAR's.
>> This allows(will allow) other projects that do use Maven, to integrate
>> tomcat into their system.
>> You can glance over it here
>> http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/res/maven/
>>
>> > - Project Site and Report Generation. - The Tomcat documentation site
>> > may benefit greatly, but the Maven reporting plugins seem to be the
>> > bigger win here.
>> >
>>
>> > As a new ASF / Tomcat contributor, I am hesitant to step on toes.
>> > But, I vote that we eat the dog food.
>> and in that last statement is where I think the problem lies. I've
>> attended a few hackathons where the coders at my table spent most of
>> their day "eating the dog food".
>> This has not really been the 

Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?

[Mary Joseph]

Hi guys, 

i have been a passive listener all the while but i feel its time for change. 

I vote for Maven 

regards, 
Mary

>>> Peter Rossbach <[EMAIL PROTECTED]> 10/18/07 11:08 AM >>>
Yes!

I can't see that maven build is better choice.

Peter

Vote -1 for build with maven!



Am 18.10.2007 um 00:45 schrieb Mark Thomas:

> Paul Shemansky wrote:
>> Key features that may be useful to us are :
>>
>> - The Standard Directory Layout - Specifically, multi-module builds.
>> This might make managing individual components easier for catalina,
>> coyote, naming, jsp/servlet api/implementation, connector, etc.
>
> "might" isn't a compelling argument.
>
>> - Model-Based builds - Automatic packaging for the individual 
>> modules.
>
> Our build script does this.
>
>> - Dependency Management - Whether it is Apache or another third-
>> party,
>> dependencies can all easily be plugged in.
>
> There are only a few and they are easily managed with the current
> build process.
>
>> - Distribution Management - Packaging and Deployment - Although 
>> Tomcat
>> has a structured distribution model with Ant, Maven could make this
>> easier with its assembly plugin.  This also allows outside 
>> entities to
>> easily embed specific Tomcat components or customize the server to
>> suit their needs, (i.e. containers like Geronimo and JBoss, IDE
>> plugins for Eclipse or Tomcat.)
>
> Easier how?
>
>> - Project Site and Report Generation. - The Tomcat documentation site
>> may benefit greatly, but the Maven reporting plugins seem to be the
>> bigger win here.
>
> "May" isn't compelling. What reporting? What do we get that we want to
> get don't currently?
>
>> As a new ASF / Tomcat contributor, I am hesitant to step on toes.
>> But, I vote that we eat the dog food.  This migration would certainly
>> be something that I could dedicate myself to, and I believe I could
>> make the transition seamless for all of us.  I look forward to 
>> hearing
>> from you.  Whether you vote Yes or No, I am still happy to be working
>> with you. :)
>
> Overall -1. I just don't see the point. The current process is nice
> and simple and works. If it ain't broke...
>
> Mark
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

svn commit: r585877 - /tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc

[mturk]

Author: mturk
Date: Wed Oct 17 22:56:42 2007
New Revision: 585877

URL: http://svn.apache.org/viewvc?rev=585877&view=rev
Log:
Fix compilation. Properly quote the strings

Modified:
tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc

Modified: tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc?rev=585877&r1=585876&r2=585877&view=diff
==
--- tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc (original)
+++ tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc Wed Oct 17 
22:56:42 2007
@@ -5,18 +5,18 @@
 
 #define TCN_COPYRIGHT "Licensed to the Apache Software Foundation (ASF) under 
" \
   "one or more contributor license agreements.  See the " \
-  "NOTICE file distributed with this work for additional "\
+  "NOTICE file distributed with this work for additional " 
\
   "information regarding copyright ownership."
 
 #define TCN_LICENSE  "The ASF licenses this file to You under the Apache " \
- "License, Version 2.0 (the "License"); you may not use " \
+ "License, Version 2.0 (the ""License""); you may not use 
" \
  "this file except in compliance with the License.  You " \
  "may obtain a copy of the License at\r\n\r\n" \
  "http://www.apache.org/licenses/LICENSE-2.0\r\n\r\n"; \
  "Unless required by applicable law or agreed to in " \
  "writing, software distributed under the License is " \
- "distributed on an "AS IS" BASIS, WITHOUT WARRANTIES " \
- "OR CONDITIONS OF ANY KIND, either express or implied. "\
+ "distributed on an ""AS IS"" BASIS, WITHOUT WARRANTIES " \
+ "OR CONDITIONS OF ANY KIND, either express or implied. " \
  "See the License for the specific language governing " \
  "permissions and limitations under the License."
 



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

svn commit: r585876 - /tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc

[mturk]

Author: mturk
Date: Wed Oct 17 22:50:50 2007
New Revision: 585876

URL: http://svn.apache.org/viewvc?rev=585876&view=rev
Log:
Fix compilation. Add missing backslash

Modified:
tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc

Modified: tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc?rev=585876&r1=585875&r2=585876&view=diff
==
--- tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc (original)
+++ tomcat/connectors/trunk/jni/native/os/win32/libtcnative.rc Wed Oct 17 
22:50:50 2007
@@ -11,7 +11,7 @@
 #define TCN_LICENSE  "The ASF licenses this file to You under the Apache " \
  "License, Version 2.0 (the "License"); you may not use " \
  "this file except in compliance with the License.  You " \
- "may obtain a copy of the License at\r\n\r\n"
+ "may obtain a copy of the License at\r\n\r\n" \
  "http://www.apache.org/licenses/LICENSE-2.0\r\n\r\n"; \
  "Unless required by applicable law or agreed to in " \
  "writing, software distributed under the License is " \



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

Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?

[Peter Rossbach]

Yes!

I can't see that maven build is better choice.

Peter

Vote -1 for build with maven!



Am 18.10.2007 um 00:45 schrieb Mark Thomas:


Paul Shemansky wrote:

Key features that may be useful to us are :

- The Standard Directory Layout - Specifically, multi-module builds.
This might make managing individual components easier for catalina,
coyote, naming, jsp/servlet api/implementation, connector, etc.


"might" isn't a compelling argument.

- Model-Based builds - Automatic packaging for the individual  
modules.


Our build script does this.

- Dependency Management - Whether it is Apache or another third- 
party,

dependencies can all easily be plugged in.


There are only a few and they are easily managed with the current
build process.

- Distribution Management - Packaging and Deployment - Although  
Tomcat

has a structured distribution model with Ant, Maven could make this
easier with its assembly plugin.  This also allows outside  
entities to

easily embed specific Tomcat components or customize the server to
suit their needs, (i.e. containers like Geronimo and JBoss, IDE
plugins for Eclipse or Tomcat.)


Easier how?


- Project Site and Report Generation. - The Tomcat documentation site
may benefit greatly, but the Maven reporting plugins seem to be the
bigger win here.


"May" isn't compelling. What reporting? What do we get that we want to
get don't currently?


As a new ASF / Tomcat contributor, I am hesitant to step on toes.
But, I vote that we eat the dog food.  This migration would certainly
be something that I could dedicate myself to, and I believe I could
make the transition seamless for all of us.  I look forward to  
hearing

from you.  Whether you vote Yes or No, I am still happy to be working
with you. :)


Overall -1. I just don't see the point. The current process is nice
and simple and works. If it ain't broke...

Mark

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

svn commit: r585875 - /tomcat/tc6.0.x/trunk/STATUS

[pero]

Author: pero
Date: Wed Oct 17 22:41:23 2007
New Revision: 585875

URL: http://svn.apache.org/viewvc?rev=585875&view=rev
Log:
add my vote

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=585875&r1=585874&r2=585875&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Wed Oct 17 22:41:23 2007
@@ -86,6 +86,6 @@
 
 * Warn if connector can not use external executors
   http://issues.apache.org/bugzilla/show_bug.cgi?id=43643
-  +1: fhanik
+  +1: fhanik, pero
   -1:
   



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

Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?

[Konstantin Kolinko]

Hi, Paul!

Just a suggestion how to start (seeing all the opinions around):

You may start playing in some sandbox, creating a directory structure
there, and pulling branches of tomcat code through the use of
svn:externals property. It is called creating a view.

Having done that, it will be more easy to show what benefits it
provides, if any.



2007/10/18, Costin Manolache <[EMAIL PROTECTED]>:
> -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 around
> and can play nicely with the current code layout and other build tools. I
> think the 'official' way to build tomcat should remain ant ( at least until
> any potential replacement has a large mileage ), but having other alternate
> build tools can't hurt.
>
> I'm quite happy using mostly eclipse - I hardly ever use ant ( mostly to
> generate jars and move code around ), the auto-recompilation and fast
> run/debug/hot-replace in eclipse are saving me a lot of time, but if
> something faster emerges I'll try it.
>
> Costin
> -1
>
> On 10/17/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> >
> > lemme give you my feedback and some history
> >
> > Paul Shemansky wrote:
> > > Dear Fellow Tomcat Developers,
> > >
> > > As you may have already noticed, I recently joined the ASF and the
> > > Tomcat Developer's List.  I have been a Maven 2 user since 2005, and I
> > > previously used Ant for all of my projects.  I suffered through many
> > > hardships migrating from Ant to Maven, but in my humble opinion, it
> > > was well worth it.  I believe that the Tomcat build can certainly
> > > benefit from some of the key features of Maven 2 mentioned below.
> > >
> > > It is not my intention to start a flame war between Ant and Maven
> > > users, but merely to propose Maven 2 to this group, and respectfully
> > > use this thread to discuss the advantages and disadvantages of
> > > switching Tomcat's build process within the 6.0.x or possibly 7.0
> > > release schedule. Please use this thread to voice your opinion.  Reply
> > > to this message with any comments, and/or simple votes for or against
> > > the migration to Maven 2.
> > >
> > > If by some odd chance you have never seen or heard about Maven 2,
> > > please visit and explore :
> > > http://maven.apache.org/
> > >
> > > Key features that may be useful to us are :
> > >
> > > - The Standard Directory Layout - Specifically, multi-module builds.
> > > This might make managing individual components easier for catalina,
> > > coyote, naming, jsp/servlet api/implementation, connector, etc.
> > >
> > we just refactored everything from being "component/module" based into a
> > single source tree.
> > Everyone at the time agreed that it would make life easier, for me
> > personally, it was a huge improvement.
> > > - Model-Based builds - Automatic packaging for the individual modules.
> > >
> > not sure what this is, even though we have a single source tree, we do
> > generate a list of jars.
> > > - Dependency Management - Whether it is Apache or another third-party,
> > > dependencies can all easily be plugged in.
> > >
> > we do that today, crude but working, ANT just adopted Ivy, a dependency
> > manager for ANT.
> > > - Distribution Management - Packaging and Deployment - Although Tomcat
> > > has a structured distribution model with Ant, Maven could make this
> > > easier with its assembly plugin.  This also allows outside entities to
> > > easily embed specific Tomcat components or customize the server to
> > > suit their needs, (i.e. containers like Geronimo and JBoss, IDE
> > > plugins for Eclipse or Tomcat.)
> > >
> > We currently have a "distribute to Maven repo" in place.
> > The most current version is in the sandbox, that would allow us to
> > publish to the central ASF repo with signed JAR's.
> > This allows(will allow) other projects that do use Maven, to integrate
> > tomcat into their system.
> > You can glance over it here
> > http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/res/maven/
> >
> > > - Project Site and Report Generation. - The Tomcat documentation site
> > > may benefit greatly, but the Maven reporting plugins seem to be the
> > > bigger win here.
> > >
> >
> > > As a new ASF / Tomcat contributor, I am hesitant to step on toes.
> > > But, I vote that we eat the dog food.
> > and in that last statement is where I think the problem lies. I've
> > attended a few hackathons where the coders at my table spent most of
> > their day "eating the dog food".
> > This has not really been the case with Tomcat, and especially Tomcat 6
> > simplified version of the structure and build.
> >
> > So, speaking for myself, I have yet not seen a benefit of Maven over our
> > current ANT build. And I wouldn't be up for eating dog food.
> > water and cr

Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?

[Mark Thomas]

Paul Shemansky wrote:
> Key features that may be useful to us are :
> 
> - The Standard Directory Layout - Specifically, multi-module builds.
> This might make managing individual components easier for catalina,
> coyote, naming, jsp/servlet api/implementation, connector, etc.

"might" isn't a compelling argument.

> - Model-Based builds - Automatic packaging for the individual modules.

Our build script does this.

> - Dependency Management - Whether it is Apache or another third-party,
> dependencies can all easily be plugged in.

There are only a few and they are easily managed with the current
build process.

> - Distribution Management - Packaging and Deployment - Although Tomcat
> has a structured distribution model with Ant, Maven could make this
> easier with its assembly plugin.  This also allows outside entities to
> easily embed specific Tomcat components or customize the server to
> suit their needs, (i.e. containers like Geronimo and JBoss, IDE
> plugins for Eclipse or Tomcat.)

Easier how?

> - Project Site and Report Generation. - The Tomcat documentation site
> may benefit greatly, but the Maven reporting plugins seem to be the
> bigger win here.

"May" isn't compelling. What reporting? What do we get that we want to
get don't currently?

> As a new ASF / Tomcat contributor, I am hesitant to step on toes.
> But, I vote that we eat the dog food.  This migration would certainly
> be something that I could dedicate myself to, and I believe I could
> make the transition seamless for all of us.  I look forward to hearing
> from you.  Whether you vote Yes or No, I am still happy to be working
> with you. :)

Overall -1. I just don't see the point. The current process is nice
and simple and works. If it ain't broke...

Mark

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

Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?

[Wendy Smoak]

On 10/17/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:

> We currently have a "distribute to Maven repo" in place.
> The most current version is in the sandbox, that would allow us to
> publish to the central ASF repo with signed JAR's.
> This allows(will allow) other projects that do use Maven, to integrate
> tomcat into their system.
> You can glance over it here
> http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/res/maven/

Hi Filip.  Speaking of that... the GPG plugin issue I opened (Ability
to sign jars when using deploy:deploy-file) has been closed/fixed, and
the feature is in the latest release of the plugin.

ISTR you were hosting the Tomcat jars in a separate repository due to
lack of signatures.  Is that still the case?  It should be possible to
deploy with signatures now.  Can you point me to the script or
procedure you're using now?  I only see the poms in the directory you
linked to above.

Thanks,
-- 
Wendy

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

Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?

[Costin Manolache]

-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 around
and can play nicely with the current code layout and other build tools. I
think the 'official' way to build tomcat should remain ant ( at least until
any potential replacement has a large mileage ), but having other alternate
build tools can't hurt.

I'm quite happy using mostly eclipse - I hardly ever use ant ( mostly to
generate jars and move code around ), the auto-recompilation and fast
run/debug/hot-replace in eclipse are saving me a lot of time, but if
something faster emerges I'll try it.

Costin
-1

On 10/17/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
>
> lemme give you my feedback and some history
>
> Paul Shemansky wrote:
> > Dear Fellow Tomcat Developers,
> >
> > As you may have already noticed, I recently joined the ASF and the
> > Tomcat Developer's List.  I have been a Maven 2 user since 2005, and I
> > previously used Ant for all of my projects.  I suffered through many
> > hardships migrating from Ant to Maven, but in my humble opinion, it
> > was well worth it.  I believe that the Tomcat build can certainly
> > benefit from some of the key features of Maven 2 mentioned below.
> >
> > It is not my intention to start a flame war between Ant and Maven
> > users, but merely to propose Maven 2 to this group, and respectfully
> > use this thread to discuss the advantages and disadvantages of
> > switching Tomcat's build process within the 6.0.x or possibly 7.0
> > release schedule. Please use this thread to voice your opinion.  Reply
> > to this message with any comments, and/or simple votes for or against
> > the migration to Maven 2.
> >
> > If by some odd chance you have never seen or heard about Maven 2,
> > please visit and explore :
> > http://maven.apache.org/
> >
> > Key features that may be useful to us are :
> >
> > - The Standard Directory Layout - Specifically, multi-module builds.
> > This might make managing individual components easier for catalina,
> > coyote, naming, jsp/servlet api/implementation, connector, etc.
> >
> we just refactored everything from being "component/module" based into a
> single source tree.
> Everyone at the time agreed that it would make life easier, for me
> personally, it was a huge improvement.
> > - Model-Based builds - Automatic packaging for the individual modules.
> >
> not sure what this is, even though we have a single source tree, we do
> generate a list of jars.
> > - Dependency Management - Whether it is Apache or another third-party,
> > dependencies can all easily be plugged in.
> >
> we do that today, crude but working, ANT just adopted Ivy, a dependency
> manager for ANT.
> > - Distribution Management - Packaging and Deployment - Although Tomcat
> > has a structured distribution model with Ant, Maven could make this
> > easier with its assembly plugin.  This also allows outside entities to
> > easily embed specific Tomcat components or customize the server to
> > suit their needs, (i.e. containers like Geronimo and JBoss, IDE
> > plugins for Eclipse or Tomcat.)
> >
> We currently have a "distribute to Maven repo" in place.
> The most current version is in the sandbox, that would allow us to
> publish to the central ASF repo with signed JAR's.
> This allows(will allow) other projects that do use Maven, to integrate
> tomcat into their system.
> You can glance over it here
> http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/res/maven/
>
> > - Project Site and Report Generation. - The Tomcat documentation site
> > may benefit greatly, but the Maven reporting plugins seem to be the
> > bigger win here.
> >
>
> > As a new ASF / Tomcat contributor, I am hesitant to step on toes.
> > But, I vote that we eat the dog food.
> and in that last statement is where I think the problem lies. I've
> attended a few hackathons where the coders at my table spent most of
> their day "eating the dog food".
> This has not really been the case with Tomcat, and especially Tomcat 6
> simplified version of the structure and build.
>
> So, speaking for myself, I have yet not seen a benefit of Maven over our
> current ANT build. And I wouldn't be up for eating dog food.
> water and cracker, although simple, have sustained us very long.
>
> I'd vote against the proposal, maybe cause I'm just getting to old to
> spend hours with Maven, but you should collect feedback from the others
> as well, and maybe there is a majority one way or the other.
>
> Filip
>
>
>
> > This migration would certainly
> > be something that I could dedicate myself to, and I believe I could
> > make the transition seamless for all of us.  I look forward to hearing
> > from you.  Whether you vote Yes or No, I am still happy to be working
> > with you. :)
> >
> > Thank You,
> > Paul Shem

Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?

[Filip Hanik - Dev Lists]

lemme give you my feedback and some history

Paul Shemansky wrote:

Dear Fellow Tomcat Developers,

As you may have already noticed, I recently joined the ASF and the
Tomcat Developer's List.  I have been a Maven 2 user since 2005, and I
previously used Ant for all of my projects.  I suffered through many
hardships migrating from Ant to Maven, but in my humble opinion, it
was well worth it.  I believe that the Tomcat build can certainly
benefit from some of the key features of Maven 2 mentioned below.

It is not my intention to start a flame war between Ant and Maven
users, but merely to propose Maven 2 to this group, and respectfully
use this thread to discuss the advantages and disadvantages of
switching Tomcat's build process within the 6.0.x or possibly 7.0
release schedule. Please use this thread to voice your opinion.  Reply
to this message with any comments, and/or simple votes for or against
the migration to Maven 2.

If by some odd chance you have never seen or heard about Maven 2,
please visit and explore :
http://maven.apache.org/

Key features that may be useful to us are :

- The Standard Directory Layout - Specifically, multi-module builds.
This might make managing individual components easier for catalina,
coyote, naming, jsp/servlet api/implementation, connector, etc.
  
we just refactored everything from being "component/module" based into a 
single source tree.
Everyone at the time agreed that it would make life easier, for me 
personally, it was a huge improvement.

- Model-Based builds - Automatic packaging for the individual modules.
  
not sure what this is, even though we have a single source tree, we do 
generate a list of jars.

- Dependency Management - Whether it is Apache or another third-party,
dependencies can all easily be plugged in.
  
we do that today, crude but working, ANT just adopted Ivy, a dependency 
manager for ANT.

- Distribution Management - Packaging and Deployment - Although Tomcat
has a structured distribution model with Ant, Maven could make this
easier with its assembly plugin.  This also allows outside entities to
easily embed specific Tomcat components or customize the server to
suit their needs, (i.e. containers like Geronimo and JBoss, IDE
plugins for Eclipse or Tomcat.)
  

We currently have a "distribute to Maven repo" in place.
The most current version is in the sandbox, that would allow us to 
publish to the central ASF repo with signed JAR's.
This allows(will allow) other projects that do use Maven, to integrate 
tomcat into their system.

You can glance over it here
http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/res/maven/


- Project Site and Report Generation. - The Tomcat documentation site
may benefit greatly, but the Maven reporting plugins seem to be the
bigger win here.
  



As a new ASF / Tomcat contributor, I am hesitant to step on toes.
But, I vote that we eat the dog food.  
and in that last statement is where I think the problem lies. I've 
attended a few hackathons where the coders at my table spent most of 
their day "eating the dog food".
This has not really been the case with Tomcat, and especially Tomcat 6 
simplified version of the structure and build.


So, speaking for myself, I have yet not seen a benefit of Maven over our 
current ANT build. And I wouldn't be up for eating dog food.

water and cracker, although simple, have sustained us very long.

I'd vote against the proposal, maybe cause I'm just getting to old to 
spend hours with Maven, but you should collect feedback from the others 
as well, and maybe there is a majority one way or the other.


Filip




This migration would certainly
be something that I could dedicate myself to, and I believe I could
make the transition seamless for all of us.  I look forward to hearing
from you.  Whether you vote Yes or No, I am still happy to be working
with you. :)

Thank You,
Paul Shemansky
Maven 2 Evangelist / Open-Source Advocate / Java Code-Monkey

P.S. - Maven has also been covered by the last few issues of JDJ,
which has certainly given it a lot more public exposure lately :
http://java.sys-con.com/read/393300.htm
http://java.sys-con.com/read/400116.htm
http://java.sys-con.com/read/419727.htm

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



  



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

Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?

[Filip Hanik - Dev Lists]

Rémy Maucherat wrote:

On Wed, 2007-10-17 at 16:21 -0400, Paul Shemansky wrote:
  

It is not my intention to start a flame war between Ant and Maven
users, but merely to propose Maven 2 to this group, and respectfully
use this thread to discuss the advantages and disadvantages of
switching Tomcat's build process within the 6.0.x or possibly 7.0
release schedule. Please use this thread to voice your opinion.  Reply
to this message with any comments, and/or simple votes for or against
the migration to Maven 2.



I don't think this work is acceptable in 6.0.x.
  

to elaborate more for you, 6.0.x is our current 6.0 release branch.
We are using RTC, Review-Then-Commit policy here, and introducing maven 
into a stable release branch like this, is probably not the best idea.
What you should focus your proposal on, is our "trunk" that doesn't yet 
exist. Once we have a trunk, ideas and contributions get discussed and 
added there, then they can be suggested for a back port.


At this moment, we don't have a trunk, but you can assume that there 
will be one




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

Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?

[Rémy Maucherat]

On Wed, 2007-10-17 at 16:21 -0400, Paul Shemansky wrote:
> It is not my intention to start a flame war between Ant and Maven
> users, but merely to propose Maven 2 to this group, and respectfully
> use this thread to discuss the advantages and disadvantages of
> switching Tomcat's build process within the 6.0.x or possibly 7.0
> release schedule. Please use this thread to voice your opinion.  Reply
> to this message with any comments, and/or simple votes for or against
> the migration to Maven 2.

I don't think this work is acceptable in 6.0.x.

Rémy



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

svn commit: r585708 - /tomcat/tc6.0.x/trunk/STATUS

[fhanik]

Author: fhanik
Date: Wed Oct 17 14:39:15 2007
New Revision: 585708

URL: http://svn.apache.org/viewvc?rev=585708&view=rev
Log:
proposed fix

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=585708&r1=585707&r2=585708&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Wed Oct 17 14:39:15 2007
@@ -82,4 +82,10 @@
 * Fix multicasting bind address on multihomed computers
   http://issues.apache.org/bugzilla/show_bug.cgi?id=43641
   +1: fhanik, pero
-  -1: 
\ No newline at end of file
+  -1: 
+
+* Warn if connector can not use external executors
+  http://issues.apache.org/bugzilla/show_bug.cgi?id=43643
+  +1: fhanik
+  -1:
+  



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

svn commit: r585707 - /tomcat/sandbox/gdev6x/java/org/apache/catalina/startup/ConnectorCreateRule.java

[fhanik]

Author: fhanik
Date: Wed Oct 17 14:38:24 2007
New Revision: 585707

URL: http://svn.apache.org/viewvc?rev=585707&view=rev
Log:
http://issues.apache.org/bugzilla/show_bug.cgi?id=43643

Modified:

tomcat/sandbox/gdev6x/java/org/apache/catalina/startup/ConnectorCreateRule.java

Modified: 
tomcat/sandbox/gdev6x/java/org/apache/catalina/startup/ConnectorCreateRule.java
URL: 
http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/java/org/apache/catalina/startup/ConnectorCreateRule.java?rev=585707&r1=585706&r2=585707&view=diff
==
--- 
tomcat/sandbox/gdev6x/java/org/apache/catalina/startup/ConnectorCreateRule.java 
(original)
+++ 
tomcat/sandbox/gdev6x/java/org/apache/catalina/startup/ConnectorCreateRule.java 
Wed Oct 17 14:38:24 2007
@@ -20,12 +20,15 @@
 package org.apache.catalina.startup;
 
 
-import org.apache.catalina.Executor;
-import org.apache.catalina.Service;
 import org.apache.catalina.connector.Connector;
-import org.apache.tomcat.util.IntrospectionUtils;
 import org.apache.tomcat.util.digester.Rule;
 import org.xml.sax.Attributes;
+import org.apache.catalina.Service;
+import org.apache.catalina.Executor;
+import org.apache.tomcat.util.IntrospectionUtils;
+import java.lang.reflect.Method;
+import org.apache.juli.logging.LogFactory;
+import org.apache.juli.logging.Log;
 
 
 /**
@@ -34,7 +37,7 @@
 
 public class ConnectorCreateRule extends Rule {
 
-
+protected static Log log = LogFactory.getLog(ConnectorCreateRule.class);
 // - Public Methods
 
 
@@ -50,14 +53,18 @@
 ex = svc.getExecutor(attributes.getValue("executor"));
 }
 Connector con = new Connector(attributes.getValue("protocol"));
-if ( ex != null )  setExecutor(con,ex);
-
+if ( ex != null )  _setExecutor(con,ex);
+
 digester.push(con);
 }
-
-public void setExecutor(Connector con, Executor ex) throws Exception {
-   IntrospectionUtils.callMethod1(con.getProtocolHandler(), "setExecutor", 
-   ex, java.util.concurrent.Executor.class.getName(), 
getClass().getClassLoader());
+
+public void _setExecutor(Connector con, Executor ex) throws Exception {
+Method m = 
IntrospectionUtils.findMethod(con.getProtocolHandler().getClass(),"setExecutor",new
 Class[] {java.util.concurrent.Executor.class});
+if (m!=null) {
+m.invoke(con.getProtocolHandler(), new Object[] {ex});
+}else {
+log.warn("Connector ["+con+"] does not support external executors. 
Method setExecutor(java.util.concurrent.Executor) not found.");
+}
 }
 
 
@@ -65,7 +72,7 @@
  * Process the end of this element.
  */
 public void end() throws Exception {
-digester.pop();
+Object top = digester.pop();
 }
 
 



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

DO NOT REPLY [Bug 43643] - Setting the executor attribute in a connector that does not support the executor attribute causes a

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43643


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #20997|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2007-10-17 14:37 ---
Created an attachment (id=21000)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21000&action=view)
Modified patch to log warning


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?

[Paul Shemansky]

Dear Fellow Tomcat Developers,

As you may have already noticed, I recently joined the ASF and the
Tomcat Developer's List.  I have been a Maven 2 user since 2005, and I
previously used Ant for all of my projects.  I suffered through many
hardships migrating from Ant to Maven, but in my humble opinion, it
was well worth it.  I believe that the Tomcat build can certainly
benefit from some of the key features of Maven 2 mentioned below.

It is not my intention to start a flame war between Ant and Maven
users, but merely to propose Maven 2 to this group, and respectfully
use this thread to discuss the advantages and disadvantages of
switching Tomcat's build process within the 6.0.x or possibly 7.0
release schedule. Please use this thread to voice your opinion.  Reply
to this message with any comments, and/or simple votes for or against
the migration to Maven 2.

If by some odd chance you have never seen or heard about Maven 2,
please visit and explore :
http://maven.apache.org/

Key features that may be useful to us are :

- The Standard Directory Layout - Specifically, multi-module builds.
This might make managing individual components easier for catalina,
coyote, naming, jsp/servlet api/implementation, connector, etc.

- Model-Based builds - Automatic packaging for the individual modules.

- Dependency Management - Whether it is Apache or another third-party,
dependencies can all easily be plugged in.

- Distribution Management - Packaging and Deployment - Although Tomcat
has a structured distribution model with Ant, Maven could make this
easier with its assembly plugin.  This also allows outside entities to
easily embed specific Tomcat components or customize the server to
suit their needs, (i.e. containers like Geronimo and JBoss, IDE
plugins for Eclipse or Tomcat.)

- Project Site and Report Generation. - The Tomcat documentation site
may benefit greatly, but the Maven reporting plugins seem to be the
bigger win here.

As a new ASF / Tomcat contributor, I am hesitant to step on toes.
But, I vote that we eat the dog food.  This migration would certainly
be something that I could dedicate myself to, and I believe I could
make the transition seamless for all of us.  I look forward to hearing
from you.  Whether you vote Yes or No, I am still happy to be working
with you. :)

Thank You,
Paul Shemansky
Maven 2 Evangelist / Open-Source Advocate / Java Code-Monkey

P.S. - Maven has also been covered by the last few issues of JDJ,
which has certainly given it a lot more public exposure lately :
http://java.sys-con.com/read/393300.htm
http://java.sys-con.com/read/400116.htm
http://java.sys-con.com/read/419727.htm

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

DO NOT REPLY [Bug 43641] - Using the bind attribute for Membership tag causes Multicast to break

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43641





--- Additional Comments From [EMAIL PROTECTED]  2007-10-17 11:23 ---
(In reply to comment #3)
> OK, can we please add if(log.isInfoEnabled) before the log statements.
> 
no need, this is not a frequently called method

> I think also the after Exception the log level is warn and not info! User has
create
> a wrong configuration !
not at all, it is simple that on some OS' don't support binding to the multicast
address, and the bind exception is expected.


> 
> :-)
> Peter



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r585616 - /tomcat/tc6.0.x/trunk/STATUS

[pero]

Author: pero
Date: Wed Oct 17 11:14:09 2007
New Revision: 585616

URL: http://svn.apache.org/viewvc?rev=585616&view=rev
Log:
add my vote

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=585616&r1=585615&r2=585616&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Wed Oct 17 11:14:09 2007
@@ -81,5 +81,5 @@
 
 * Fix multicasting bind address on multihomed computers
   http://issues.apache.org/bugzilla/show_bug.cgi?id=43641
-  +1: fhanik
+  +1: fhanik, pero
   -1: 



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

DO NOT REPLY [Bug 43641] - Using the bind attribute for Membership tag causes Multicast to break

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43641





--- Additional Comments From [EMAIL PROTECTED]  2007-10-17 11:12 ---
OK, can we please add if(log.isInfoEnabled) before the log statements.

I think also the after Exception the log level is warn and not info! User has 
create
a wrong configuration !

:-)
Peter

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r585610 - /tomcat/tc6.0.x/trunk/STATUS

[fhanik]

Author: fhanik
Date: Wed Oct 17 11:00:23 2007
New Revision: 585610

URL: http://svn.apache.org/viewvc?rev=585610&view=rev
Log:
proposed bug fix

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=585610&r1=585609&r2=585610&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Wed Oct 17 11:00:23 2007
@@ -78,3 +78,8 @@
 
   +1: 
   -1: 
+
+* Fix multicasting bind address on multihomed computers
+  http://issues.apache.org/bugzilla/show_bug.cgi?id=43641
+  +1: fhanik
+  -1: 
\ No newline at end of file



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

DO NOT REPLY [Bug 43641] - Using the bind attribute for Membership tag causes Multicast to break

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43641


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #20995|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2007-10-17 10:58 ---
Created an attachment (id=20999)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20999&action=view)
Formatted patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r585606 - in /tomcat/sandbox/gdev6x: build.properties.default java/org/apache/catalina/core/StandardServer.java

[fhanik]

Author: fhanik
Date: Wed Oct 17 10:54:15 2007
New Revision: 585606

URL: http://svn.apache.org/viewvc?rev=585606&view=rev
Log:
Forward port from  6.0

Modified:
tomcat/sandbox/gdev6x/build.properties.default
tomcat/sandbox/gdev6x/java/org/apache/catalina/core/StandardServer.java

Modified: tomcat/sandbox/gdev6x/build.properties.default
URL: 
http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/build.properties.default?rev=585606&r1=585605&r2=585606&view=diff
==
--- tomcat/sandbox/gdev6x/build.properties.default (original)
+++ tomcat/sandbox/gdev6x/build.properties.default Wed Oct 17 10:54:15 2007
@@ -42,7 +42,7 @@
 jdt.home=${base.path}/eclipse/plugins
 jdt.lib=${jdt.home}
 jdt.jar=${jdt.lib}/org.eclipse.jdt.core_3.2.3.v_686_R32x.jar
-jdt.loc=http://sunsite.informatik.rwth-aachen.de/eclipse/downloads/drops/R-3.2.2-200702121330/eclipse-JDT-3.2.2.zip
+jdt.loc=http://sunsite.informatik.rwth-aachen.de/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
 
 # - Tomcat native library -
 tomcat-native.home=${base.path}/tomcat-native-1.1.10

Modified: 
tomcat/sandbox/gdev6x/java/org/apache/catalina/core/StandardServer.java
URL: 
http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/java/org/apache/catalina/core/StandardServer.java?rev=585606&r1=585605&r2=585606&view=diff
==
--- tomcat/sandbox/gdev6x/java/org/apache/catalina/core/StandardServer.java 
(original)
+++ tomcat/sandbox/gdev6x/java/org/apache/catalina/core/StandardServer.java Wed 
Oct 17 10:54:15 2007
@@ -360,7 +360,7 @@
 if( port==-1 ) {
 while( true ) {
 try {
-Thread.sleep( 10 );
+Thread.sleep( 1 );
 } catch( InterruptedException ex ) {
 }
 if( stopAwait ) return;
@@ -746,6 +746,9 @@
 
 // Notify our interested LifecycleListeners
 lifecycle.fireLifecycleEvent(AFTER_STOP_EVENT, null);
+
+if (port == -1)
+stopAwait();
 
 }
 



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

svn commit: r585604 - in /tomcat/tc6.0.x/trunk: STATUS java/org/apache/coyote/http11/Http11NioProtocol.java

[fhanik]

Author: fhanik
Date: Wed Oct 17 10:51:44 2007
New Revision: 585604

URL: http://svn.apache.org/viewvc?rev=585604&view=rev
Log:
Fix property setter for keystore type

Modified:
tomcat/tc6.0.x/trunk/STATUS
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=585604&r1=585603&r2=585604&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Wed Oct 17 10:51:44 2007
@@ -52,11 +52,6 @@
   +1: remm, fhanik,funkman, pero
   -1: 
 
-* Fix property setter for keystore type
-  http://issues.apache.org/bugzilla/show_bug.cgi?id=43634
-  +1: fhanik,funkman,remm, pero
-  -1: 
-
 * IcedTea support. Upcoming Linux distributions will package a (working) open 
source JRE,
   available in /usr. As a result, it could now be possible to use a 
"/usr/bin/java" binary
   if one is present and expect results. [tested on Fedora 8 test 3]

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java?rev=585604&r1=585603&r2=585604&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java 
Wed Oct 17 10:51:44 2007
@@ -558,7 +558,9 @@
 public String getKeypass() { return getKeystorePass();}
 public String getKeystoreType() { return ep.getKeystoreType();}
 public void setKeystoreType(String s ) { ep.setKeystoreType(s);}
-
+public String getKeytype() { return getKeystoreType();}
+public void setKeytype(String s ) { setKeystoreType(s);}
+
 public void setTruststoreFile(String f){ep.setTruststoreFile(f);}
 public String getTruststoreFile(){return ep.getTruststoreFile();}
 public void setTruststorePass(String p){ep.setTruststorePass(p);}



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

Re: Tomcat6 BUILDING.txt misunderstood?

[Paul Shemansky]

On 10/17/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> Paul Shemansky wrote:
> > My Fellow Code Monkeys,
.
> > My first day here, I noticed that we
> > are downloading DBCP source files and compiling them with the Tomcat build.
> > In my humble opinion, I think it would be nice to just include a reference
> > to a working version of the DBCP as a Maven dependency.

> we are not only downloading the source files, we are refactoring them
> before compilation as well.
> we are changing the package name to org.apache.tomcat.dbcp so that
> webapps that include commons-dbcp don't cause problems

Thank you for enlightening me.  That makes more sense now.  I still
believe there is room for improvements, though.  And I am eagerly
studying and looking to make some.

> > Should we take a vote on this?  As a proof-of-concept, may I start a
> > Maven2-managed SVN branch somehow?
> >
> do a poll, but in a separate thread, so that people are clear on what
> you are asking them.

I agree. I will start one shortly.

Thank You.

>
> Filip
> > Sincerely,
> > Paul Shemansky
> > Maven 2 Evangelist
> >
> >
> >
> > On 10/17/07, Rémy Maucherat <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, 2007-10-17 at 08:41 -0400, Yoav Shapira wrote:
> >>
> >>> Hi DI,
> >>>
> >>> On 10/17/07, DI Roman Fiedler <[EMAIL PROTECTED]> wrote:
> >>>
>  If misunderstood: Change line to
> Download a Java Development Kit (JDK) release (version 1.5.x) from:
> 
>  If error:
>    search for it?
> 
> >>> It's an error: the build is intended to work with Java 1.5 and later,
> >>> including Java 1.6, but it doesn't right now.  It's our fault and
> >>> we're working on fixing it.  Sorry about that ;)
> >>>
> >> It's impossible to predict if it will work with newer versions. It's
> >> supposed to, but Sun likes to break the JDBC interfaces on each major
> >> upgrade :(
> >>
> >> Rémy
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >
> >
> > 
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.488 / Virus Database: 269.14.13/1074 - Release Date: 
> > 10/16/2007 2:14 PM
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

svn commit: r585542 - /tomcat/sandbox/gdev6x/java/org/apache/coyote/http11/Http11NioProtocol.java

[fhanik]

Author: fhanik
Date: Wed Oct 17 08:42:52 2007
New Revision: 585542

URL: http://svn.apache.org/viewvc?rev=585542&view=rev
Log:
http://issues.apache.org/bugzilla/show_bug.cgi?id=43634

Modified:
tomcat/sandbox/gdev6x/java/org/apache/coyote/http11/Http11NioProtocol.java

Modified: 
tomcat/sandbox/gdev6x/java/org/apache/coyote/http11/Http11NioProtocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/java/org/apache/coyote/http11/Http11NioProtocol.java?rev=585542&r1=585541&r2=585542&view=diff
==
--- tomcat/sandbox/gdev6x/java/org/apache/coyote/http11/Http11NioProtocol.java 
(original)
+++ tomcat/sandbox/gdev6x/java/org/apache/coyote/http11/Http11NioProtocol.java 
Wed Oct 17 08:42:52 2007
@@ -559,7 +559,9 @@
 public String getKeypass() { return getKeystorePass();}
 public String getKeystoreType() { return ep.getKeystoreType();}
 public void setKeystoreType(String s ) { ep.setKeystoreType(s);}
-
+public String getKeytype() { return getKeystoreType();}
+public void setKeytype(String s ) { setKeystoreType(s);}
+
 public void setTruststoreFile(String f){ep.setTruststoreFile(f);}
 public String getTruststoreFile(){return ep.getTruststoreFile();}
 public void setTruststorePass(String p){ep.setTruststorePass(p);}



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

svn commit: r585541 - /tomcat/sandbox/gdev6x/java/org/apache/catalina/core/StandardThreadExecutor.java

[fhanik]

Author: fhanik
Date: Wed Oct 17 08:41:20 2007
New Revision: 585541

URL: http://svn.apache.org/viewvc?rev=585541&view=rev
Log:
http://issues.apache.org/bugzilla/show_bug.cgi?id=43642

Modified:

tomcat/sandbox/gdev6x/java/org/apache/catalina/core/StandardThreadExecutor.java

Modified: 
tomcat/sandbox/gdev6x/java/org/apache/catalina/core/StandardThreadExecutor.java
URL: 
http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/java/org/apache/catalina/core/StandardThreadExecutor.java?rev=585541&r1=585540&r2=585541&view=diff
==
--- 
tomcat/sandbox/gdev6x/java/org/apache/catalina/core/StandardThreadExecutor.java 
(original)
+++ 
tomcat/sandbox/gdev6x/java/org/apache/catalina/core/StandardThreadExecutor.java 
Wed Oct 17 08:41:20 2007
@@ -19,6 +19,7 @@
 
 import java.util.Collection;
 import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.RejectedExecutionException;
 import java.util.concurrent.ThreadFactory;
 import java.util.concurrent.ThreadPoolExecutor;
 import java.util.concurrent.TimeUnit;
@@ -28,7 +29,6 @@
 import org.apache.catalina.LifecycleException;
 import org.apache.catalina.LifecycleListener;
 import org.apache.catalina.util.LifecycleSupport;
-import java.util.concurrent.RejectedExecutionException;
 
 public class StandardThreadExecutor implements Executor {
 
@@ -52,6 +52,8 @@
 protected AtomicInteger activeCount = new AtomicInteger(0);
 
 private LifecycleSupport lifecycle = new LifecycleSupport(this);
+
+protected boolean prestartminSpareThreads = false;
 // -- Constructors
 public StandardThreadExecutor() {
 //empty constructor for the digester
@@ -74,6 +76,10 @@
 activeCount.addAndGet(-1);
 }
 };
+if (prestartminSpareThreads) {
+executor.prestartAllCoreThreads();
+}
+
 taskqueue.setParent( (ThreadPoolExecutor) executor);
 lifecycle.fireLifecycleEvent(AFTER_START_EVENT, null);
 }
@@ -127,6 +133,10 @@
 return name;
 }
 
+public boolean isPrestartminSpareThreads() {
+return prestartminSpareThreads;
+}
+
 public void setThreadPriority(int threadPriority) {
 this.threadPriority = threadPriority;
 }
@@ -154,7 +164,11 @@
 public void setName(String name) {
 this.name = name;
 }
-
+
+public void setPrestartminSpareThreads(boolean prestartminSpareThreads) {
+this.prestartminSpareThreads = prestartminSpareThreads;
+}
+
 /**
  * Add a LifecycleEvent listener to this component.
  *



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

svn commit: r585538 - /tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/membership/McastServiceImpl.java

[fhanik]

Author: fhanik
Date: Wed Oct 17 08:34:53 2007
New Revision: 585538

URL: http://svn.apache.org/viewvc?rev=585538&view=rev
Log:
http://issues.apache.org/bugzilla/show_bug.cgi?id=43641

Modified:

tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/membership/McastServiceImpl.java

Modified: 
tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
URL: 
http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/membership/McastServiceImpl.java?rev=585538&r1=585537&r2=585538&view=diff
==
--- 
tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
 (original)
+++ 
tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
 Wed Oct 17 08:34:53 2007
@@ -29,6 +29,7 @@
 import org.apache.catalina.tribes.Channel;
 import org.apache.catalina.tribes.Member;
 import org.apache.catalina.tribes.MembershipListener;
+import java.net.BindException;
 
 /**
  * A membership implementation using simple multicast.
@@ -182,8 +183,22 @@
 }
 
 protected void setupSocket() throws IOException {
-if (mcastBindAddress != null) socket = new MulticastSocket(new 
InetSocketAddress(mcastBindAddress, port));
-else socket = new MulticastSocket(port);
+if (mcastBindAddress != null) {
+try {
+log.info("Attempting to bind the multicast socket to 
"+address+":"+port);
+socket = new MulticastSocket(new 
InetSocketAddress(address,port));
+} catch (BindException e) {
+/*
+ * On some plattforms (e.g. Linux) it is not possible to bind
+ * to the multicast address. In this case only bind to the
+ * port.
+ */
+log.info("Binding to multicast address, failed. Binding to 
port only.");
+socket = new MulticastSocket(port);
+}
+} else {
+socket = new MulticastSocket(port);
+}
 socket.setLoopbackMode(false); //hint that we don't need loop back 
messages
 if (mcastBindAddress != null) {
if(log.isInfoEnabled())



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

Re: Tomcat6 BUILDING.txt misunderstood?

[Filip Hanik - Dev Lists]

Paul Shemansky wrote:

My Fellow Code Monkeys,

You may have noticed I recommended for a push to change the build to a Maven
2 structure.  Before starting a Mavenization discussion thread, I wanted to
investigate the entire build process.  My first day here, I noticed that we
are downloading DBCP source files and compiling them with the Tomcat build.
In my humble opinion, I think it would be nice to just include a reference
to a working version of the DBCP as a Maven dependency.  
we are not only downloading the source files, we are refactoring them 
before compilation as well.
we are changing the package name to org.apache.tomcat.dbcp so that 
webapps that include commons-dbcp don't cause problems



As I am still
getting acquainted here, I have tried to refrain from rocking the boat, but,
why do we tie ourselves to a build process of another completely separate
and JDK-dependent project?  Tomcat and DBCP should be built separately, and
Tomcat should probably use the pre-built, fully-tested DBCP jar file.  If I
am missing something, please forgive and educate this poor Tomcat Newbie.

I hereby re-announce my willingness to volunteer efforts towards the the
true Mavenization of the Tomcat build.

Should we take a vote on this?  As a proof-of-concept, may I start a
Maven2-managed SVN branch somehow?
  
do a poll, but in a separate thread, so that people are clear on what 
you are asking them.


Filip

Sincerely,
Paul Shemansky
Maven 2 Evangelist



On 10/17/07, Rémy Maucherat <[EMAIL PROTECTED]> wrote:
  

On Wed, 2007-10-17 at 08:41 -0400, Yoav Shapira wrote:


Hi DI,

On 10/17/07, DI Roman Fiedler <[EMAIL PROTECTED]> wrote:
  

If misunderstood: Change line to
   Download a Java Development Kit (JDK) release (version 1.5.x) from:

If error:
  search for it?


It's an error: the build is intended to work with Java 1.5 and later,
including Java 1.6, but it doesn't right now.  It's our fault and
we're working on fixing it.  Sorry about that ;)
  

It's impossible to predict if it will work with newer versions. It's
supposed to, but Sun likes to break the JDBC interfaces on each major
upgrade :(

Rémy



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





  



No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.14.13/1074 - Release Date: 10/16/2007 2:14 PM
  



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

DO NOT REPLY [Bug 43643] - Setting the executor attribute in a connector that does not support the executor attribute causes a

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43643





--- Additional Comments From [EMAIL PROTECTED]  2007-10-17 08:02 ---
Created an attachment (id=20997)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20997&action=view)
Patch against 6.0.14


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 43643] New: - Setting the executor attribute in a connector that does not support the executor attribute causes a

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43643

   Summary: Setting the executor attribute in a connector that does
not support the executor attribute causes a
   Product: Tomcat 6
   Version: 6.0.14
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Setting the executor attribute for a connector that does not support the
executor attribute causes a NullPointerException. Usually elements simply ignore
attributes that do not know. The attached patch fixes this.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 43642] New: - Add prestartminSpareThreads attribute for Executor

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43642

   Summary: Add prestartminSpareThreads attribute for Executor
   Product: Tomcat 6
   Version: 6.0.14
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The attached patch adds the boolean attribute prestartminSpareThreads to the
Executor element. This allows the admin to prestart minspareThreads for this
Executor during the start of Tomcat. The default value is false which is the old
behaviour. A documentation patch for executor.xml can be created if there is
interest in committing this patch.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 43642] - Add prestartminSpareThreads attribute for Executor

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43642





--- Additional Comments From [EMAIL PROTECTED]  2007-10-17 08:01 ---
Created an attachment (id=20996)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20996&action=view)
Patch against 6.0.14


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 43641] - Using the bind attribute for Membership tag causes Multicast to break

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43641





--- Additional Comments From [EMAIL PROTECTED]  2007-10-17 07:59 ---
Created an attachment (id=20995)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20995&action=view)
Patch against 6.0.14


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 43641] New: - Using the bind attribute for Membership tag causes Multicast to break

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43641

   Summary: Using the bind attribute for Membership tag causes
Multicast to break
   Product: Tomcat 6
   Version: 6.0.14
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: Cluster
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using the bind attribute for the Membership tag causes multicast to break. So
something like

   

causes a broken cluster.
The reason for this is that in the case that the bind parameter is set the 
MulticastSocket is bound to the multicast interface. This is wrong as it causes
the respective udp socket to be bound to this interface which stops multicast
from working (tested on Linux and Solaris). It can be tried to bind the
MulticastSocket to the multicast address itself. This does not work on all
platforms. In case it does not work it can be ignored silently and the
MulticastSocket only binds to the port. The attached patch fixes this.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS

[jean-frederic clere]

Rainer Jung wrote:
> jean-frederic clere wrote:
>> Rémy Maucherat wrote:
>>> On Wed, 2007-10-17 at 07:28 -0400, Tim Funk wrote:
 There was a request in bugzilla to pass in a new env variable called
 JAVA_EXE (or similar).

 Could that be an acceptable alternative? Then it would make the bug
 submitter happy since he can symlink my_program_that_i_can_see_in_ps
 to java.
>>> That would be good too, with autodetection :)
>>
>> which java + dirname + testing files should do that easily I will make
>> tries and propose a patch.
> 
> In the unix world "env" is supposed to be more portable than "which" (5
> cents).

There is often an utility name which: /usr/bin/which instead the buildin
which.

> 
> Explicitely set JAVA_*/JRE_* environment variables should have
> preference over java binaries found in the PATH.

For sure ;-)

Cheers

Jean-Frederic

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


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

Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS

[Rainer Jung]

jean-frederic clere wrote:

Rémy Maucherat wrote:

On Wed, 2007-10-17 at 07:28 -0400, Tim Funk wrote:
There was a request in bugzilla to pass in a new env variable called 
JAVA_EXE (or similar).


Could that be an acceptable alternative? Then it would make the bug 
submitter happy since he can symlink my_program_that_i_can_see_in_ps to 
java.

That would be good too, with autodetection :)


which java + dirname + testing files should do that easily I will make
tries and propose a patch.


In the unix world "env" is supposed to be more portable than "which" (5 
cents).


Explicitely set JAVA_*/JRE_* environment variables should have 
preference over java binaries found in the PATH.


Regards,

Rainer

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

Re: Tomcat6 BUILDING.txt misunderstood?

[Paul Shemansky]

My Fellow Code Monkeys,

You may have noticed I recommended for a push to change the build to a Maven
2 structure.  Before starting a Mavenization discussion thread, I wanted to
investigate the entire build process.  My first day here, I noticed that we
are downloading DBCP source files and compiling them with the Tomcat build.
In my humble opinion, I think it would be nice to just include a reference
to a working version of the DBCP as a Maven dependency.  As I am still
getting acquainted here, I have tried to refrain from rocking the boat, but,
why do we tie ourselves to a build process of another completely separate
and JDK-dependent project?  Tomcat and DBCP should be built separately, and
Tomcat should probably use the pre-built, fully-tested DBCP jar file.  If I
am missing something, please forgive and educate this poor Tomcat Newbie.

I hereby re-announce my willingness to volunteer efforts towards the the
true Mavenization of the Tomcat build.

Should we take a vote on this?  As a proof-of-concept, may I start a
Maven2-managed SVN branch somehow?

Sincerely,
Paul Shemansky
Maven 2 Evangelist



On 10/17/07, Rémy Maucherat <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2007-10-17 at 08:41 -0400, Yoav Shapira wrote:
> > Hi DI,
> >
> > On 10/17/07, DI Roman Fiedler <[EMAIL PROTECTED]> wrote:
> > > If misunderstood: Change line to
> > >Download a Java Development Kit (JDK) release (version 1.5.x) from:
> > >
> > > If error:
> > >   search for it?
> >
> > It's an error: the build is intended to work with Java 1.5 and later,
> > including Java 1.6, but it doesn't right now.  It's our fault and
> > we're working on fixing it.  Sorry about that ;)
>
> It's impossible to predict if it will work with newer versions. It's
> supposed to, but Sun likes to break the JDBC interfaces on each major
> upgrade :(
>
> Rémy
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS

[jean-frederic clere]

Rémy Maucherat wrote:
> On Wed, 2007-10-17 at 07:28 -0400, Tim Funk wrote:
>> There was a request in bugzilla to pass in a new env variable called 
>> JAVA_EXE (or similar).
>>
>> Could that be an acceptable alternative? Then it would make the bug 
>> submitter happy since he can symlink my_program_that_i_can_see_in_ps to 
>> java.
> 
> That would be good too, with autodetection :)

which java + dirname + testing files should do that easily I will make
tries and propose a patch.

Cheers

Jean-Frederic

> 
> Rémy
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


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

Re: Tomcat6 BUILDING.txt misunderstood?

[Rémy Maucherat]

On Wed, 2007-10-17 at 08:41 -0400, Yoav Shapira wrote:
> Hi DI,
> 
> On 10/17/07, DI Roman Fiedler <[EMAIL PROTECTED]> wrote:
> > If misunderstood: Change line to
> >Download a Java Development Kit (JDK) release (version 1.5.x) from:
> >
> > If error:
> >   search for it?
> 
> It's an error: the build is intended to work with Java 1.5 and later,
> including Java 1.6, but it doesn't right now.  It's our fault and
> we're working on fixing it.  Sorry about that ;)

It's impossible to predict if it will work with newer versions. It's
supposed to, but Sun likes to break the JDBC interfaces on each major
upgrade :(

Rémy



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

Re: Tomcat6 BUILDING.txt misunderstood?

[DI Roman Fiedler]

Yoav Shapira wrote:

Hi DI,

On 10/17/07, DI Roman Fiedler <[EMAIL PROTECTED]> wrote:
  

If misunderstood: Change line to
   Download a Java Development Kit (JDK) release (version 1.5.x) from:

If error:
  search for it?



It's an error: the build is intended to work with Java 1.5 and later,
including Java 1.6, but it doesn't right now.  It's our fault and
we're working on fixing it.  Sorry about that ;)
  
No problem, maybe just change the line to force 1.5.x until changes are 
done.

Yoav
  



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

svn commit: r585465 - in /tomcat/connectors/trunk/jk: jkstatus/src/share/org/apache/jk/status/JkStatusUpdateLoadbalancerTask.java jkstatus/src/share/org/apache/jk/status/JkStatusUpdateTask.java xdocs/

[pero]

Author: pero
Date: Wed Oct 17 05:42:28 2007
New Revision: 585465

URL: http://svn.apache.org/viewvc?rev=585465&view=rev
Log:
Fix correct parameter validation at JkStatusUpdateTask and 
JkStatusUpdateLoadbalancerTask ant tasks.

Modified:

tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusUpdateLoadbalancerTask.java

tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusUpdateTask.java
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

Modified: 
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusUpdateLoadbalancerTask.java
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusUpdateLoadbalancerTask.java?rev=585465&r1=585464&r2=585465&view=diff
==
--- 
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusUpdateLoadbalancerTask.java
 (original)
+++ 
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusUpdateLoadbalancerTask.java
 Wed Oct 17 05:42:28 2007
@@ -233,14 +233,14 @@
  * lx: max reply timeouts
  * 
  * 
- * lm=1 or Requests
- * lm=2 or Traffic
- * lm=3 or Busyness
- * lm=4 or Sessions
+ * lm=0 or Requests
+ * lm=1 or Traffic
+ * lm=2 or Busyness
+ * lm=3 or Sessions
  * 
  * 
- * ll=1 or Optimistic
- * ll=2 or Pessimistic
+ * ll=0 or Optimistic
+ * ll=1 or Pessimistic
  * 
  * 
  * @return create jkstatus update worker link
@@ -268,7 +268,7 @@
sb.append("<=");
sb.append(recoverWaitTime);
}
-   if (method == null && methodCode > 0 && methodCode < 5) 
{
+   if (method == null && methodCode >= 0 && methodCode < 
4) {
sb.append("&lm=");
sb.append(methodCode);
}
@@ -276,7 +276,7 @@
sb.append("&lm=");
sb.append(method);
}
-   if (lock == null && lockCode > 0 && lockCode < 3) {
+   if (lock == null && lockCode >= 0 && lockCode < 2) {
sb.append("&ll=");
sb.append(lockCode);
}

Modified: 
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusUpdateTask.java
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusUpdateTask.java?rev=585465&r1=585464&r2=585465&view=diff
==
--- 
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusUpdateTask.java
 (original)
+++ 
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusUpdateTask.java
 Wed Oct 17 05:42:28 2007
@@ -282,9 +282,9 @@
 
 /**
  * 
- * 1 active
- * 2 disabled
- * 3 stopped
+ * 0 active
+ * 1 disabled
+ * 2 stopped
  * 
  * @param workerActivation The workerActivation to set.
  * 
@@ -358,12 +358,12 @@
  * load balance example:
  * 
http://localhost/jkstatus?cmd=update&mime=txt&w=lb&lf=false&ls=true
  * worker example:
- * 
http://localhost/jkstatus?cmd=update&mime=txt&w=node1&wn=node01&l=lb&wf=1&wa=1&wx=0
+ * 
http://localhost/jkstatus?cmd=update&mime=txt&w=node1&wn=node01&l=lb&wf=1&wa=2&wx=0
  * 
  * 
- * wa=1 active
- * wa=2 disabled
- * wa=3 stopped
+ * wa=0 active
+ * wa=1 disabled
+ * wa=2 stopped
  * 
  * 
  * 
@@ -443,7 +443,7 @@
 sb.append("&ws=");
 sb.append(workerStopped);
 }
-if (workerActivation > 0 && workerActivation < 4) {
+if (workerActivation >= 0 && workerActivation < 3) {
 sb.append("&wa=");
 sb.append(workerActivation);
 } 

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?rev=585465&r1=585464&r2=585465&view=diff
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Wed Oct 17 
05:42:28 2007
@@ -81,6 +81,10 @@
 possible confusion with custom header names using a standard header 
name
 as a prefix. (rjung)
   
+  
+jkstatus: Fix correct parameter validation at JkStatusUpdateTask and 
+JkStatusUpdateLoadbalancerTask ant tasks. Reported by Christian 
Mittendorf. (pero)
+  
 
   
 



-

Re: Tomcat6 BUILDING.txt misunderstood?

[Yoav Shapira]

Hi DI,

On 10/17/07, DI Roman Fiedler <[EMAIL PROTECTED]> wrote:
> If misunderstood: Change line to
>Download a Java Development Kit (JDK) release (version 1.5.x) from:
>
> If error:
>   search for it?

It's an error: the build is intended to work with Java 1.5 and later,
including Java 1.6, but it doesn't right now.  It's our fault and
we're working on fixing it.  Sorry about that ;)

Yoav

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

Tomcat6 BUILDING.txt misunderstood?

[DI Roman Fiedler]

Hi List,

tomcat6 Building.txt says:

* Download a Java Development Kit (JDK) release (version 1.5.x or later) 
from:


   http://java.sun.com/j2se/

I tried it with 1.6 (which is later than 1.5.x) and it failed. With 1.5 
it worked. Did I misunderstand the line or should 1.6 have worked also?


If misunderstood: Change line to
  Download a Java Development Kit (JDK) release (version 1.5.x) from:

If error:
 search for it?




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

DO NOT REPLY [Bug 43530] - Bad links on Apache Tomcat 6.0 Documentation Index

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43530





--- Additional Comments From [EMAIL PROTECTED]  2007-10-17 05:33 ---
Created an attachment (id=20994)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20994&action=view)
Fixes bad link in documentation, and an invalid ant mkdir command for the
associated documentation.

This should fix one of the links in the reported bug.  However three bad links
were reported.  The other two JavaDoc links seem to have been previously fixed.
However, the changes do not seem to be publishing from the SVN repository to
the main Tomcat 6 Documentation site.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS

[Rémy Maucherat]

On Wed, 2007-10-17 at 07:28 -0400, Tim Funk wrote:
> There was a request in bugzilla to pass in a new env variable called 
> JAVA_EXE (or similar).
> 
> Could that be an acceptable alternative? Then it would make the bug 
> submitter happy since he can symlink my_program_that_i_can_see_in_ps to 
> java.

That would be good too, with autodetection :)

Rémy



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

Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS

[Peter Rossbach]

+1 for that env variable,
but also autodetection must be implemented

Peter



Am 17.10.2007 um 13:28 schrieb Tim Funk:

There was a request in bugzilla to pass in a new env variable  
called JAVA_EXE (or similar).


Could that be an acceptable alternative? Then it would make the bug  
submitter happy since he can symlink  
my_program_that_i_can_see_in_ps to java.


-Tim

Rémy Maucherat wrote:

On Wed, 2007-10-17 at 05:47 +0200, Peter Rossbach wrote:

Hi Remy,

I think the patch is incomplete

this line seem not correct:

+else
+  JRE_HOME=/usr
+fi

better
+else
+  JRE_HOME=/usr/bin/java
+fi

The path to the Java executable is $JRE_HOME/bin/java, so /usr is the
correct value. However, on older distributions (just tested with  
my F7),
it will also pick up gij if it is installed (it does not really  
work).


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

Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS

[Tim Funk]

There was a request in bugzilla to pass in a new env variable called 
JAVA_EXE (or similar).


Could that be an acceptable alternative? Then it would make the bug 
submitter happy since he can symlink my_program_that_i_can_see_in_ps to 
java.


-Tim

Rémy Maucherat wrote:

On Wed, 2007-10-17 at 05:47 +0200, Peter Rossbach wrote:

Hi Remy,

I think the patch is incomplete

this line seem not correct:

+else
+  JRE_HOME=/usr
+fi

better
+else
+  JRE_HOME=/usr/bin/java
+fi


The path to the Java executable is $JRE_HOME/bin/java, so /usr is the
correct value. However, on older distributions (just tested with my F7),
it will also pick up gij if it is installed (it does not really work).



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

Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS

[Peter Rossbach]

Hi Remy,

but is'nt /usr/lib/java the correct value to JRE_HOME ?

Regards
Peter


Am 17.10.2007 um 13:10 schrieb Rémy Maucherat:


On Wed, 2007-10-17 at 05:47 +0200, Peter Rossbach wrote:

Hi Remy,

I think the patch is incomplete

this line seem not correct:

+else
+  JRE_HOME=/usr
+fi

better
+else
+  JRE_HOME=/usr/bin/java
+fi


The path to the Java executable is $JRE_HOME/bin/java, so /usr is the
correct value. However, on older distributions (just tested with my  
F7),

it will also pick up gij if it is installed (it does not really work).

Rémy



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

Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS

[Rémy Maucherat]

On Wed, 2007-10-17 at 05:47 +0200, Peter Rossbach wrote:
> Hi Remy,
> 
> I think the patch is incomplete
> 
> this line seem not correct:
> 
> +else
> +  JRE_HOME=/usr
> +fi
> 
> better
> +else
> +  JRE_HOME=/usr/bin/java
> +fi

The path to the Java executable is $JRE_HOME/bin/java, so /usr is the
correct value. However, on older distributions (just tested with my F7),
it will also pick up gij if it is installed (it does not really work).

Rémy



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