You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2002/12/05 13:00:26 UTC
[VOTE] Tomcat modules
Hi,
I plan to reorganize the jakarta-tomcat-catalina repository as follows:
- catalina folder: Catalina core; this depends on the servlet API
- modules folders: Optional functionality and modules (one example is
clustering), but which depends on the Catalina API; this does not
directly depend on the servlet API
Alternately, using another repository (j-t-modules) is possible, but
just using a folder looks simpler, as there is an API dependency.
I propose putting independent modules in j-t-connectors (like eventually
some of the naming features).
<ballot>
+1 [ ]
-1 [ ]
</ballot>
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Tomcat modules
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Remy Maucherat wrote:
>
> <ballot>
> +1 [X ]
> -1 [ ]
> </ballot>
>
> Remy
>
I like the idea of having j-t-module, because it's look like
jakarta-commons. But j-t-connector is fine for now.
-- Jeanfrancois
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: minimal
Posted by Remy Maucherat <re...@apache.org>.
Glenn Nielsen wrote:
> The minimal will need some form of minimal docs, perhaps just the config
> reference
> as an HTML file?
Or an HTML with a small message ("hi, this is mini-tomcat, please go
online for the full docs") a metarefresh to the Tomcat website ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: minimal
Posted by Glenn Nielsen <gl...@mail.more.net>.
The minimal will need some form of minimal docs, perhaps just the config reference
as an HTML file?
Glenn
Costin Manolache wrote:
> Another try:
>
> Required libs:
> - JMX
> - JAAS
> - JNDI
> - digester ( and beanutils, collections it needs ).
> - modeler
> - ant ( required by jasper runtime and startup )
> - commons-logging
> When/if the JNDI-based abstraction of config files is ready we'll not
> need digester - but most likely it'll still be required by
> modeler, and also by jasper, so I don't think we can remove it.
>
> Minimal:
> - subset of catalina ( non-deprecated interfaces and base impl that is
> required for tomcat to work ).
> - coyote
> - tomcat-util
> - http11/jk2
> - all valves/etc that are required for tomcat to operate.
> - naming
> - jasper ( at least jasper runtime - but probably the whole thing ).
>
> Optional:
> - all components with external deps.
> - all components that are not required to get tomcat running
> as a fully-functional servlet container.
> - admin webapp
> - example webapps
> - manager ( since JMX can already do most of the stuff that's there )
> - slide ( if we agree to replace our internal webdav with the real thing )
> - struts ( required by admin, but also as a separate component ).
> - extra taglibs
> - doc webapp
>
> This can changes as we go - this is just to get things started.
> We can add more stuff in the optional - like other jakarta projects,
> log4j, etc.
>
> The "full" distribution will include minimal+optional.
>
> The goal is to keep "minimal" small :-)
>
> Costin
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: minimal
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2002/12/5 11:51 AM, "Costin Manolache" <cm...@yahoo.com> wrote:
> - jasper ( at least jasper runtime - but probably the whole thing ).
Now that we have JSR 154 and JSR 153, can't we make a distribution of Tomcat
that does not include Jasper? That would rock. =)
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: minimal
Posted by Costin Manolache <cm...@yahoo.com>.
Another try:
Required libs:
- JMX
- JAAS
- JNDI
- digester ( and beanutils, collections it needs ).
- modeler
- ant ( required by jasper runtime and startup )
- commons-logging
When/if the JNDI-based abstraction of config files is ready we'll not
need digester - but most likely it'll still be required by
modeler, and also by jasper, so I don't think we can remove it.
Minimal:
- subset of catalina ( non-deprecated interfaces and base impl that is
required for tomcat to work ).
- coyote
- tomcat-util
- http11/jk2
- all valves/etc that are required for tomcat to operate.
- naming
- jasper ( at least jasper runtime - but probably the whole thing ).
Optional:
- all components with external deps.
- all components that are not required to get tomcat running
as a fully-functional servlet container.
- admin webapp
- example webapps
- manager ( since JMX can already do most of the stuff that's there )
- slide ( if we agree to replace our internal webdav with the real thing )
- struts ( required by admin, but also as a separate component ).
- extra taglibs
- doc webapp
This can changes as we go - this is just to get things started.
We can add more stuff in the optional - like other jakarta projects,
log4j, etc.
The "full" distribution will include minimal+optional.
The goal is to keep "minimal" small :-)
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: minimal
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> Jeanfrancois Arcand wrote:
>>
>>
>>> Yep. There is a couple of Realm/Authenticator that can be optional (the
>>> default one should stay in the core module)
>>
>>
>>
>> Speaking of defaults:
>> - Should we make the JAAS realm the default ? Or at least include it
>> in the core ? In my opinion the user.xml Realm should eventually be
>> rewritten as a JAAS plugin - and same for the LDAP/JDBC ones. But
>> I don't have the time, so including both jaas and user.xml in the
>> minimal would be a reasonable solution.
>
+1
>>
>>
>> - I think the vote on JMX passed ( or will pass). Do we agree on
>> requiring JAAS and JNDI ( i.e JDK1.3 or JDK1.2 + jndi.jar + jaas.jar ) ?
>> That would eliminate some of the conditionals and clean up things.
>
+1
>>
>>
>> One major criteria for making things "optional" can be the external
>> dependencies ( on non-required features ). Another thing that can be
>> made "optional" for 5.0 is the deprecated stuff we include only for
>> backward compatibility.
>>
>> My current preference for the list of "required":
>> - JMX
>> - JAAS
>> - JNDI
>> - digester ( and beanutils it needs )
>
+ collections (digester use it)
>>
>
> Ok. If we use a JNDI context to abstract the XML, we could remove the
> digester (or, OTOH, we could use the digester to populate the JNDI
> context). Wasn't that the idea ?
>
>> And components to be included in minimal:
>> - catalina
>
>
> I think we'll be able to remove things in there.
>
>> - coyote
>> - tomcat-util
>> - http11/jk2
>> - all valves/etc that are required for tomcat to operate.
>> - naming
>
What about Struts? Do we want the Admin App included as minimal? If yes,
then Jasper will need to be added to the list
>>
>
> +1.
>
>> For optional:
>> - all components with external deps. - all components that are not
>> required to get tomcat running
>> as a fully-functional servlet container.
>
>>
>
> +1.
+1
Jeanfrancois
>
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: minimal
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Jeanfrancois Arcand wrote:
>
>
>>Yep. There is a couple of Realm/Authenticator that can be optional (the
>>default one should stay in the core module)
>
>
> Speaking of defaults:
>
> - Should we make the JAAS realm the default ? Or at least include it
> in the core ? In my opinion the user.xml Realm should eventually be
> rewritten as a JAAS plugin - and same for the LDAP/JDBC ones. But
> I don't have the time, so including both jaas and user.xml in the
> minimal would be a reasonable solution.
>
> - I think the vote on JMX passed ( or will pass). Do we agree on
> requiring JAAS and JNDI ( i.e JDK1.3 or JDK1.2 + jndi.jar + jaas.jar ) ?
> That would eliminate some of the conditionals and clean up things.
>
> One major criteria for making things "optional" can be the external
> dependencies ( on non-required features ). Another thing that can be
> made "optional" for 5.0 is the deprecated stuff we include only for
> backward compatibility.
>
> My current preference for the list of "required":
> - JMX
> - JAAS
> - JNDI
> - digester ( and beanutils it needs )
Ok. If we use a JNDI context to abstract the XML, we could remove the
digester (or, OTOH, we could use the digester to populate the JNDI
context). Wasn't that the idea ?
> And components to be included in minimal:
> - catalina
I think we'll be able to remove things in there.
> - coyote
> - tomcat-util
> - http11/jk2
> - all valves/etc that are required for tomcat to operate.
> - naming
+1.
> For optional:
> - all components with external deps.
> - all components that are not required to get tomcat running
> as a fully-functional servlet container.
+1.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: minimal
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2002/12/5 10:34 AM, "Costin Manolache" <cm...@yahoo.com> wrote:
> And components to be included in minimal:
> - catalina
> - coyote
> - tomcat-util
> - http11/jk2
> - all valves/etc that are required for tomcat to operate.
> - naming
I'm 100% +1 on a minimal distribution of Tomcat 4 that only includes enough
crud to allow "normal" servlets to run.
I have one with Scarab and it was a PITA to create because I basically had
to trial and error which .jar files needed to be included (and where). Take
a look at Scarab's distribution of Tomcat.
http://scarab.tigris.org/source/browse/scarab/src/tomcat-4.1/
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
minimal
Posted by Costin Manolache <cm...@yahoo.com>.
Jeanfrancois Arcand wrote:
> Yep. There is a couple of Realm/Authenticator that can be optional (the
> default one should stay in the core module)
Speaking of defaults:
- Should we make the JAAS realm the default ? Or at least include it
in the core ? In my opinion the user.xml Realm should eventually be
rewritten as a JAAS plugin - and same for the LDAP/JDBC ones. But
I don't have the time, so including both jaas and user.xml in the
minimal would be a reasonable solution.
- I think the vote on JMX passed ( or will pass). Do we agree on
requiring JAAS and JNDI ( i.e JDK1.3 or JDK1.2 + jndi.jar + jaas.jar ) ?
That would eliminate some of the conditionals and clean up things.
One major criteria for making things "optional" can be the external
dependencies ( on non-required features ). Another thing that can be
made "optional" for 5.0 is the deprecated stuff we include only for
backward compatibility.
My current preference for the list of "required":
- JMX
- JAAS
- JNDI
- digester ( and beanutils it needs )
And components to be included in minimal:
- catalina
- coyote
- tomcat-util
- http11/jk2
- all valves/etc that are required for tomcat to operate.
- naming
For optional:
- all components with external deps.
- all components that are not required to get tomcat running
as a fully-functional servlet container.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: build files ( again )
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Costin Manolache wrote:
>Since we are talking about clean and organized:
>
>Can I (re)move the antcall to jk, http11, jtc from
>j-t-catalina/catalina/build.xml ? j-t5 is the main
>build file and it should call all 'child' build.xml files
>directly.
>
+1
>
>Is anyone else using the "build" target ? Any objections
>to creating all the output in j-t5 ( as done "build" )
>instead of all the different dirs and then copy ?
>
+1. This should speed up the process
>
>Another one: I added a flag "build.tomcat.minimal" and
>split the compile target in catalina/build.xml. One piece
>will build the core stuff, the other will build all
>optional code ( unless minimal is set ). You shouldn't
>notice any change.
>We do have to decide what is optional and what is not.
>
>
Yep. There is a couple of Realm/Authenticator that can be optional (the
default one should stay in the core module)
-- Jeanfrancois
>
>Costin
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: build files ( again )
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Since we are talking about clean and organized:
>
> Can I (re)move the antcall to jk, http11, jtc from
> j-t-catalina/catalina/build.xml ? j-t5 is the main
> build file and it should call all 'child' build.xml files
> directly.
>
> Is anyone else using the "build" target ? Any objections
> to creating all the output in j-t5 ( as done "build" )
> instead of all the different dirs and then copy ?
If it works, yes.
> Another one: I added a flag "build.tomcat.minimal" and
> split the compile target in catalina/build.xml. One piece
> will build the core stuff, the other will build all
> optional code ( unless minimal is set ). You shouldn't
> notice any change.
> We do have to decide what is optional and what is not.
It would be best to build both at the same time, rather than using a
flag. At least that would make my life much easier (the 4.1 style is
painful and error prone when building a binary).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
build files ( again )
Posted by Costin Manolache <cm...@yahoo.com>.
Since we are talking about clean and organized:
Can I (re)move the antcall to jk, http11, jtc from
j-t-catalina/catalina/build.xml ? j-t5 is the main
build file and it should call all 'child' build.xml files
directly.
Is anyone else using the "build" target ? Any objections
to creating all the output in j-t5 ( as done "build" )
instead of all the different dirs and then copy ?
Another one: I added a flag "build.tomcat.minimal" and
split the compile target in catalina/build.xml. One piece
will build the core stuff, the other will build all
optional code ( unless minimal is set ). You shouldn't
notice any change.
We do have to decide what is optional and what is not.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Tomcat modules
Posted by Glenn Nielsen <gl...@mail.more.net>.
+1
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> Remy Maucherat wrote:
>>
>>
>>> Hi,
>>>
>>> I plan to reorganize the jakarta-tomcat-catalina repository as follows:
>>> - catalina folder: Catalina core; this depends on the servlet API
>>> - modules folders: Optional functionality and modules (one example is
>>> clustering), but which depends on the Catalina API; this does not
>>> directly depend on the servlet API
>>>
>>> Alternately, using another repository (j-t-modules) is possible, but
>>> just using a folder looks simpler, as there is an API dependency.
>>>
>>> I propose putting independent modules in j-t-connectors (like eventually
>>> some of the naming features).
>>>
>>> <ballot>
>>> +1 [X] -1 [ ]
>>> </ballot>
>>
>>
>>
>> Some comments: while it is a good idea for the new code ( clustering ),
>> it's probably not worth moving the existing code around. At least not
>> until we decide about the Action and auth*.
>> Code that is independent of catalina core should be in j-t-connectors
>> or j-t-modules. Probably a modules cvs repository would make sense - but
>> there's no problem with using j-t-connectors.
>
>
> Ok, so to paraphrase:
> - Catalina core: stays in j-t-catalina/catalina
> - Modules which use the Catalina API: j-t-catalina/modules (or by
> component name, like j-t-catalina/cluster ?)
> - Rest: j-t-c
>
> I won't bother moving code around for now then (and you like doing that
> way too much, so I'll let you do it if it's needed ;-) ).
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Tomcat modules
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>> Remy Maucherat wrote:
>>
>>
>>>Hi,
>>>
>>>I plan to reorganize the jakarta-tomcat-catalina repository as follows:
>>>- catalina folder: Catalina core; this depends on the servlet API
>>>- modules folders: Optional functionality and modules (one example is
>>>clustering), but which depends on the Catalina API; this does not
>>>directly depend on the servlet API
>>>
>>>Alternately, using another repository (j-t-modules) is possible, but
>>>just using a folder looks simpler, as there is an API dependency.
>>>
>>>I propose putting independent modules in j-t-connectors (like eventually
>>>some of the naming features).
>>>
>>><ballot>
>>>+1 [X]
>>>-1 [ ]
>>></ballot>
>>
>>
>> Some comments: while it is a good idea for the new code ( clustering ),
>> it's probably not worth moving the existing code around. At least
>> not until we decide about the Action and auth*.
>>
>> Code that is independent of catalina core should be in j-t-connectors or
>> j-t-modules. Probably a modules cvs repository would make sense - but
>> there's no problem with using j-t-connectors.
>
> Ok, so to paraphrase:
> - Catalina core: stays in j-t-catalina/catalina
> - Modules which use the Catalina API: j-t-catalina/modules (or by
> component name, like j-t-catalina/cluster ?)
I think j-t-catalina/cluster is better.
> - Rest: j-t-c
Sounds good. j-t-module may be better name - but I don't think it's
worth the effort. Maybe we just extend "connector" to more than
web-server-connector, but external-stuff-connector :-)
> I won't bother moving code around for now then (and you like doing that
> way too much, so I'll let you do it if it's needed ;-) ).
Please do move the cluster and new stuff :-)
I like things to be clear and well organized - but we should first
have a clear decision on what we want. Cluster seems clear -
it'll be optional, well separated - and minimal interface changes in
catalina to support it. ( later on we can support other kinds of
cluster - in addition to javagroup - if we want, in a separate module ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Tomcat modules
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 5 Dec 2002, Remy Maucherat wrote:
>
> Ok, so to paraphrase:
> - Catalina core: stays in j-t-catalina/catalina
> - Modules which use the Catalina API: j-t-catalina/modules (or by
> component name, like j-t-catalina/cluster ?)
Or maybe j-t-catalina/modules/cluster so that the individual modules are
independent of each other but are easily found?
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Tomcat modules
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>Hi,
>>
>>I plan to reorganize the jakarta-tomcat-catalina repository as follows:
>>- catalina folder: Catalina core; this depends on the servlet API
>>- modules folders: Optional functionality and modules (one example is
>>clustering), but which depends on the Catalina API; this does not
>>directly depend on the servlet API
>>
>>Alternately, using another repository (j-t-modules) is possible, but
>>just using a folder looks simpler, as there is an API dependency.
>>
>>I propose putting independent modules in j-t-connectors (like eventually
>>some of the naming features).
>>
>><ballot>
>>+1 [X]
>>-1 [ ]
>></ballot>
>
>
> Some comments: while it is a good idea for the new code ( clustering ),
> it's probably not worth moving the existing code around. At least
> not until we decide about the Action and auth*.
>
> Code that is independent of catalina core should be in j-t-connectors or
> j-t-modules. Probably a modules cvs repository would make sense - but
> there's no problem with using j-t-connectors.
Ok, so to paraphrase:
- Catalina core: stays in j-t-catalina/catalina
- Modules which use the Catalina API: j-t-catalina/modules (or by
component name, like j-t-catalina/cluster ?)
- Rest: j-t-c
I won't bother moving code around for now then (and you like doing that
way too much, so I'll let you do it if it's needed ;-) ).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Tomcat modules
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Hi,
>
> I plan to reorganize the jakarta-tomcat-catalina repository as follows:
> - catalina folder: Catalina core; this depends on the servlet API
> - modules folders: Optional functionality and modules (one example is
> clustering), but which depends on the Catalina API; this does not
> directly depend on the servlet API
>
> Alternately, using another repository (j-t-modules) is possible, but
> just using a folder looks simpler, as there is an API dependency.
>
> I propose putting independent modules in j-t-connectors (like eventually
> some of the naming features).
>
> <ballot>
> +1 [X]
> -1 [ ]
> </ballot>
Some comments: while it is a good idea for the new code ( clustering ),
it's probably not worth moving the existing code around. At least
not until we decide about the Action and auth*.
Code that is independent of catalina core should be in j-t-connectors or
j-t-modules. Probably a modules cvs repository would make sense - but
there's no problem with using j-t-connectors.
Costin
>
> Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Tomcat modules
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat wrote:
> Hi,
>
> I plan to reorganize the jakarta-tomcat-catalina repository as follows:
> - catalina folder: Catalina core; this depends on the servlet API
> - modules folders: Optional functionality and modules (one example is
> clustering), but which depends on the Catalina API; this does not
> directly depend on the servlet API
>
> Alternately, using another repository (j-t-modules) is possible, but
> just using a folder looks simpler, as there is an API dependency.
>
> I propose putting independent modules in j-t-connectors (like eventually
> some of the naming features).
>
> <ballot>
> +1 [ ]
> -1 [ ]
> </ballot>
+0
I'm pretty busy these days so I can't help even if this
and the clustering are of very interest for me.
Regards
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>