Tomcat 6 source organisation part 2

[Remy Maucherat <re...@apache.org>]

Hi,

Given the comments, I propose using a single repository with the 
following structure (based on our root "tomcat" repository):
- tc6.0.x/trunk:
   - src/share: all the relevant sources go there
   - webapps: all our current webapps, including the examples webapps 
(note: portions of the source of certain webapps could be included in 
the main source tree)
   - src/native: the current tcnative code
- tc6.0.x/branches
- tc6.0.x/tags

I suppose mod_jk will stay where it is right now. I was also thinking 
about merging commons-modeler in the tomcat.util packages, retaining the 
functionality that we use (AFAIK, there are commons-modeler users out 
there, I saw at least a couple articles over the years).

Any other ideas ?

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Filip Hanik - Dev Lists <de...@hanik.com>]

are all the conf files, startup scripts etc in one place? res?
I was thinking that we still have a src directory, and subdirectories 
under that.

trunk/src/java
trunk/src/native
trunk/webapps

etc

Keith Wannamaker wrote:
> Yes, this will do nicely.
>
> Keith
>
> Costin Manolache wrote:
>> We still need separate dirs for native code and java I think.
>>
>> What about:
>>
>> tc6(.0.x ?)/trunk/java
>> tc6/trunk/native
>> tc6/trunk/webapps
>> tc6/trunk/res
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Keith Wannamaker <Ke...@Apache.org>]

Yes, this will do nicely.

Keith

Costin Manolache wrote:
> We still need separate dirs for native code and java I think.
> 
> What about:
> 
> tc6(.0.x ?)/trunk/java
> tc6/trunk/native
> tc6/trunk/webapps
> tc6/trunk/res
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Yoav Shapira <yo...@apache.org>]

Hola,

> "share" has a long history - I think JDK is organized this way, with
> separate dirs for windows, linux, etc.

Maybe the JDK was organized that way in the past, but doesn't seem to
be that way any more.  Anyways, I don't think it has a purpose
currently.  If something we're not aware of comes screaming at us, we
can add it back in later, but I'm in favor of removing unneeded layers
and directories where possible.

> I assume native would host apr ? Or both apr and jk ? And maybe the
> win installer ?

Yes, yes, and yes IMHO.

Yoav

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Proposal] Small manager improvement

[Rainer Jung <to...@kippdata.de>]

I have a small patch that I think improves the session listing in the 
manager webapp:

The doc says

============================
Session Statistics

Display the default session timeout for a web application, and the 
number of currently active sessions that fall within ten-minute ranges 
of their actual timeout times. For example, after restarting Tomcat and 
then executing one of the JSP samples in the /examples web app, you 
might get something like this:
============================

Actually that's not true and I have the impression the code does 
something not very useful which we can very easily tranform to something 
really useful:

At the moment the code calculates a histogramm of the different 
maxInactiveInterval values for all sessions of a context. Now most 
contexts I know, work with a fixed maxInactiveInterval for all sessions 
   in the context. As a result, all of the sessions are in the same 
histogram class and instead of the possible up to 60 lines of result 
histogram, the code always simply produces a single line showing again 
the total number of sessions - which is already included on the same 
page further down. So no real sense in that.

With a few lines of change we could easily list a histogram of how far 
sessions are away from their idle timeout. That seems to be a much more 
interesting information for monitoring, e.g. it enables to make a well 
informed decision on shrinking or sizing up session timeouts. This would 
also be in better alignment with the documntation of manger. This is 
sugestion 1a.

What I would even like better is instead printing a hitogramm of the 
actual idle time of the sessions. I think for most admins this is a more 
easily understandable metric.

So suggestion 1b: change sessions-function in manager webapp to show a 
histogram of session idle distribution instead of maxActiveTimeout 
distribution.

Suggestion 2: another small fix would allow a manager user to 
prematurely expire all sessions which are idle for a longer time than 
the amount of minutes she types into a text field (before she presses 
the new expire button.

I have a use case for this: some applications work with long running 
sessions (employee applications) that might have relatively big 
sessions. These applications typically have a timeout of several hours 
to allow resumption of work after lunch breaks, meeting etc. Often such 
apps depend on other external applications. When those have a bad day, 
the users of the web app might experience very long response times. So 
they decide to try a new login to the web app. From that point in time 
their old sessions are no longer used, but still stay in memory for 
several more hours. As soon as the external app has another hickup, 
another round of sessions gets lost by the same user behaviour. A well 
informed admin could now react to such a non-standard situation by 
deciding to expire all sessions which are idle longer than the amount of 
minutes she decides, e.g. one hour.

I did all that for TC5 and for 5.5 it's mostly the same. If their is 
interest in it, I would provide patches, including doc patches. I still 
would need spanish and japanese translations for "expire". :)

Feedback is highly welcome.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Mario Ivankovits <ma...@ops.co.at>]

Hi!Costin Manolache schrieb:
> The extra src/ is useless in our code organization.
>   
Sure, but it didn't cost anything and it makes clear where to look if
one searches the sources.
Its simply one nice little place for all the great code.

But ok, its my personal preference :-)

---
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Costin Manolache <co...@gmail.com>]

On 3/1/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> >> tc6(.0.x ?)/trunk/java
> >> tc6/trunk/native
> >> tc6/trunk/webapps
> >> tc6/trunk/res
> Isn't it widely used to have:
>
> src/java
> src/tests
> src/native

Widely used doesn't mean it's good in all cases :-)

For most simple native projects, the source was under src/ - with
Makefile at top level, and also an include/, doc/ folder.
This got cut&pasted probably to src/java, src/test, etc

The extra src/ is useless in our code organization.

Costin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
>> tc6(.0.x ?)/trunk/java
>> tc6/trunk/native
>> tc6/trunk/webapps
>> tc6/trunk/res
Isn't it widely used to have:

src/java
src/tests
src/native

Ciao,
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Remy Maucherat <re...@apache.org>]

Costin Manolache wrote:
> We still need separate dirs for native code and java I think.
> 
> What about:
> 
> tc6(.0.x ?)/trunk/java
> tc6/trunk/native
> tc6/trunk/webapps
> tc6/trunk/res

There's a native folder too, and most likely there should be a test 
folder too.

> and the docs webapp at top level, as Yoav suggested.
> 
> "share" has a long history - I think JDK is organized this way, with
> separate dirs for windows, linux, etc.
> 
> I assume native would host apr ? Or both apr and jk ? And maybe the
> win installer ?

Yes, native will host APR. For mod_jk, I don't know, it's really a 
separate project.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Costin Manolache <co...@gmail.com>]

We still need separate dirs for native code and java I think.

What about:

tc6(.0.x ?)/trunk/java
tc6/trunk/native
tc6/trunk/webapps
tc6/trunk/res

and the docs webapp at top level, as Yoav suggested.

"share" has a long history - I think JDK is organized this way, with
separate dirs for windows, linux, etc.

I assume native would host apr ? Or both apr and jk ? And maybe the
win installer ?

Costin



On 3/1/06, Remy Maucherat <re...@apache.org> wrote:
> Hi,
>
> Given the comments, I propose using a single repository with the
> following structure (based on our root "tomcat" repository):
> - tc6.0.x/trunk:
>    - src/share: all the relevant sources go there
>    - webapps: all our current webapps, including the examples webapps
> (note: portions of the source of certain webapps could be included in
> the main source tree)
>    - src/native: the current tcnative code
> - tc6.0.x/branches
> - tc6.0.x/tags
>
> I suppose mod_jk will stay where it is right now. I was also thinking
> about merging commons-modeler in the tomcat.util packages, retaining the
> functionality that we use (AFAIK, there are commons-modeler users out
> there, I saw at least a couple articles over the years).
>
> Any other ideas ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Remy Maucherat <re...@apache.org>]

Yoav Shapira wrote:
>> So let's make it:
>> - tc6.0.x/trunk:
>>    - src: all the relevant sources go there
>>    - webapps: all our current webapps, including the examples webapps
>>    - resources: misc resources, such as configuration files
>> (server.xml), readmes, etc
> 
> OK.
> 
> One other thing: can we put docs under trunk instead of under webapps?
>  We can still package a docs webapp into the same place on the distro
> as now, I like that part.  But for people navigating the repository or
> downloading our source distros, it's not obvious to find docs under
> webapps...

That's a good idea, I think.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Yoav Shapira <yo...@apache.org>]

> So let's make it:
> - tc6.0.x/trunk:
>    - src: all the relevant sources go there
>    - webapps: all our current webapps, including the examples webapps
>    - resources: misc resources, such as configuration files
> (server.xml), readmes, etc

OK.

One other thing: can we put docs under trunk instead of under webapps?
 We can still package a docs webapp into the same place on the distro
as now, I like that part.  But for people navigating the repository or
downloading our source distros, it's not obvious to find docs under
webapps...

Yoav

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Ian Darwin <ia...@darwinsys.com>]

>
> So let's make it:
> - tc6.0.x/trunk:
>   - src: all the relevant sources go there
>   - webapps: all our current webapps, including the examples webapps
>   - resources: misc resources, such as configuration files 
> (server.xml), readmes, etc
+1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Keith Wannamaker <Ke...@Apache.org>]

We should keep the java sources separate from the native sources by one 
more level under src/, aka the share directory (or something- I always 
thought it referenced "share"d across platforms as simply opposed to 
specific "native" code).

Keith

Remy Maucherat wrote:
> Yoav Shapira wrote:
>> I've been meaning to ask this for years now: what's the purpose of the
>> "share" directory under src?  We share all our source by definition,
>> so it just seems like an extra layer...
> 
> I have no idea what "share" means either ;)
> 
> So let's make it:
> - tc6.0.x/trunk:
>   - src: all the relevant sources go there
>   - webapps: all our current webapps, including the examples webapps
>   - resources: misc resources, such as configuration files (server.xml), 
> readmes, etc
> 
> Rémy
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Remy Maucherat <re...@apache.org>]

Yoav Shapira wrote:
> I've been meaning to ask this for years now: what's the purpose of the
> "share" directory under src?  We share all our source by definition,
> so it just seems like an extra layer...

I have no idea what "share" means either ;)

So let's make it:
- tc6.0.x/trunk:
   - src: all the relevant sources go there
   - webapps: all our current webapps, including the examples webapps
   - resources: misc resources, such as configuration files 
(server.xml), readmes, etc

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Yoav Shapira <yo...@apache.org>]

I've been meaning to ask this for years now: what's the purpose of the
"share" directory under src?  We share all our source by definition,
so it just seems like an extra layer...

Yoav

On 3/1/06, Remy Maucherat <re...@apache.org> wrote:
> Hi,
>
> Given the comments, I propose using a single repository with the
> following structure (based on our root "tomcat" repository):
> - tc6.0.x/trunk:
>    - src/share: all the relevant sources go there
>    - webapps: all our current webapps, including the examples webapps
> (note: portions of the source of certain webapps could be included in
> the main source tree)
>    - src/native: the current tcnative code
> - tc6.0.x/branches
> - tc6.0.x/tags
>
> I suppose mod_jk will stay where it is right now. I was also thinking
> about merging commons-modeler in the tomcat.util packages, retaining the
> functionality that we use (AFAIK, there are commons-modeler users out
> there, I saw at least a couple articles over the years).
>
> Any other ideas ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


--
Yoav Shapira
Senior Architect
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Florian Fray <fr...@itcf.biz>]

Hi Remy!

> Ok, so I'll (try to) create the structure (not the one in this mail), 
> but how is it done in SVN ? Is it all simply folders without anything 
> special ?

A simple bunch of "svn mkdir" commands will do its job.
There's nothing special about it.

Regards

Florian
 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat 6 source organisation part 2

[Remy Maucherat <re...@apache.org>]

Remy Maucherat wrote:
> Hi,
> 
> Given the comments, I propose using a single repository with the 
> following structure (based on our root "tomcat" repository):
> - tc6.0.x/trunk:
>   - src/share: all the relevant sources go there
>   - webapps: all our current webapps, including the examples webapps 
> (note: portions of the source of certain webapps could be included in 
> the main source tree)
>   - src/native: the current tcnative code
> - tc6.0.x/branches
> - tc6.0.x/tags
> 
> I suppose mod_jk will stay where it is right now. I was also thinking 
> about merging commons-modeler in the tomcat.util packages, retaining the 
> functionality that we use (AFAIK, there are commons-modeler users out 
> there, I saw at least a couple articles over the years).
> 
> Any other ideas ?

Ok, so I'll (try to) create the structure (not the one in this mail), 
but how is it done in SVN ? Is it all simply folders without anything 
special ?

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org