That's an excellent works from Guillaume who is digging
in Sun licenses terms for one or two months and who is
today one of the few specialists in Sun licenses as he
could read and decode all of these ;)
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
That's an excellent works from Guillaume who is digging
in Sun licenses terms for one or two months and who is
today one of the few specialists in Sun licenses as he
could read and decode all of these ;)
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
>I am rebuilding from source. These JARs are included in the source
>distribution in the lib/ directory and are just copied to the final
>compiled tree. The sources for those classes are in the
>jakarta-tomcat-connectors archive - I don't understand why.
You could compile them from jtc, here is ho
>EmbeddedManager depends on jmxri.jar. Currently, I have this jar in
>jboss-contrib, in preparation for being an external
>dependancy. However,
>jboss can't build unless catalina(tomcat4) is install, and
>catalina can't
>build unless jboss is installed.
Replace jmxri by openjmx (www.openjmx.or
>Great, I will check these out soon.
>
>> - The package currently uses the included JARs from the
>> jakarta-tomcat-connectors project. This means that the
>package would have
>> to go into non-free if I don't change this.
Why didn't you rebuilt it from source since TC 4.0.2 in LE mode
no mor
>I am rebuilding from source. These JARs are included in the source
>distribution in the lib/ directory and are just copied to the final
>compiled tree. The sources for those classes are in the
>jakarta-tomcat-connectors archive - I don't understand why.
You could compile them from jtc, here is h
>EmbeddedManager depends on jmxri.jar. Currently, I have this jar in
>jboss-contrib, in preparation for being an external
>dependancy. However,
>jboss can't build unless catalina(tomcat4) is install, and
>catalina can't
>build unless jboss is installed.
Replace jmxri by openjmx (www.openjmx.o
>Great, I will check these out soon.
>
>> - The package currently uses the included JARs from the
>> jakarta-tomcat-connectors project. This means that the
>package would have
>> to go into non-free if I don't change this.
Why didn't you rebuilt it from source since TC 4.0.2 in LE mode
no mo
You could now put Tomcat 4 on Debian since Apache
produce a 'light version' on release 4.0.2 which
didn't make Sun problematic jar mandatory :)
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fing
>Two quick observations... Please correct me if I'm wrong...
>
>If memory serves, the JSSE problem will solve itself at the
>release of JDK-1.4.
Yes, it will included, also with the others problematic jars.
>I recall reading that this package should be included as part
>of this java release.
>
>I meant the man who will make the Debian package of Tomcat. According
>to the Debian philosophy, it means making different packages and
>dependencies. The packages with license problems will not be IN a
>package but an installer package may be a good solution (the
>[end-]user
>Two quick observations... Please correct me if I'm wrong...
>
>If memory serves, the JSSE problem will solve itself at the
>release of JDK-1.4.
Yes, it will included, also with the others problematic jars.
>I recall reading that this package should be included as part
>of this java release.
>I meant the man who will make the Debian package of Tomcat. According
>to the Debian philosophy, it means making different packages and
>dependencies. The packages with license problems will not be IN a
>package but an installer package may be a good solution (the
>[end-]use
>> We have some discussions around the packaging of these kind of API,
>> which are mandatory for TC 4.x on tomcat-dev and Sun employees
>> clearly indicate that WE SHOULDN'T PROVIDE ANY PACKAGING OF SUCH JAR
>> (RPM/DEB), see Licence
>
>Hi Henri,
>
>Ifollowed somediscussions
>> We have some discussions around the packaging of these kind of API,
>> which are mandatory for TC 4.x on tomcat-dev and Sun employees
>> clearly indicate that WE SHOULDN'T PROVIDE ANY PACKAGING OF SUCH JAR
>> (RPM/DEB), see Licence
>
>Hi Henri,
>
>Ifollowed somediscussions
>> Yes, sure it is. The ftp admins might even allow a real package for
>> non-free but nobody has volunteered yet.
>
>It is possible to make a non-free package for jndi and so?
>
>Well, Stefan, I won't bother you with simple package questions, I've
>just subscribe to some Debian-dev mailing li
>> Yes, sure it is. The ftp admins might even allow a real package for
>> non-free but nobody has volunteered yet.
>
>It is possible to make a non-free package for jndi and so?
>
>Well, Stefan, I won't bother you with simple package questions, I've
>just subscribe to some Debian-dev mailing l
364F 80E6
>-Original Message-
>From: GOMEZ Henri
>Sent: Monday, December 03, 2001 10:45 AM
>To: debian-java@lists.debian.org
>Subject: RE: [summary] Re: policy proposition for javadoc installation
>
>
>>Tollef Fog Heen wrote:
>>
>>> Debian do
904A 364F 80E6
>-Original Message-
>From: GOMEZ Henri
>Sent: Monday, December 03, 2001 10:45 AM
>To: [EMAIL PROTECTED]
>Subject: RE: [summary] Re: policy proposition for javadoc installation
>
>
>>Tollef Fog Heen wrote:
>>
>>> Debian do
>GOMEZ> Consider that you could have a web application, .war, which
>GOMEZ> will be exploded by tomcat at runtime so you need for some
>GOMEZ> dirs, logs, work, webapps write access !!!
>
>An application server has no legitimate reason to change the code it's
>executing. Expanding a WAR file is an
>GOMEZ> Consider that you could have a web application, .war, which
>GOMEZ> will be exploded by tomcat at runtime so you need for some
>GOMEZ> dirs, logs, work, webapps write access !!!
>
>An application server has no legitimate reason to change the code it's
>executing. Expanding a WAR file is an
>Stefan> So static parts inside the /mywebapp directoy were served by
>Stefan> Apache directly and dynamic parts (JSP pags and servlets) were
>Stefan> passed to Tomcat using mod_jk. This changed in Tomcat 3.3: All
>Stefan> files inside /mywebapp are handled by Tomcat now, like in this
>Stefan> exam
>GOMEZ> Yep, I added also in tomcat bin wrapper a :
>
>GOMEZ> chown -R tcuser:tcuser /var/tomcat/
>
>GOMEZ> to make sure that tomcat is running with the rigth profile
>
>That is not a good idea. The tomcat user should not own any files
>(besides logfiles and so on). If someone manages to break into
>Stefan> So static parts inside the /mywebapp directoy were served by
>Stefan> Apache directly and dynamic parts (JSP pags and servlets) were
>Stefan> passed to Tomcat using mod_jk. This changed in Tomcat 3.3: All
>Stefan> files inside /mywebapp are handled by Tomcat now, like in this
>Stefan> exa
>GOMEZ> Yep, I added also in tomcat bin wrapper a :
>
>GOMEZ> chown -R tcuser:tcuser /var/tomcat/
>
>GOMEZ> to make sure that tomcat is running with the rigth profile
>
>That is not a good idea. The tomcat user should not own any files
>(besides logfiles and so on). If someone manages to break int
>> I consider that a bug, and should probably file one. tomcat
>should not run as
>> the same user as apache, for security reasons.
>
>In previous versions the auto-generated config file looked like this:
>
>JkMount /mywebapp/*.jsp ajp12
>
> AllowOverride None
> deny from all
>
>
> AllowOverri
>> I consider that a bug, and should probably file one. tomcat
>should not run as
>> the same user as apache, for security reasons.
>
>In previous versions the auto-generated config file looked like this:
>
>JkMount /mywebapp/*.jsp ajp12
>
> AllowOverride None
> deny from all
>
>
> AllowOverr
>Tollef Fog Heen wrote:
>
>> Debian doesn't use RPM as part of the package management
>> infrastructure, and any limitations of RPM is therefore irrelevant to
>> how Debian should handle javadoc, and (in general) Debian policy.
>>
>> So, again: why should Debian policy care about RPM systems?
>
>
Yes, in my RPM, i use differents users for apache,
tomcat 3.3 and tomcat 4.0
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-Origina
>Tollef Fog Heen wrote:
>
>> Debian doesn't use RPM as part of the package management
>> infrastructure, and any limitations of RPM is therefore irrelevant to
>> how Debian should handle javadoc, and (in general) Debian policy.
>>
>> So, again: why should Debian policy care about RPM systems?
>
>
Yes, in my RPM, i use differents users for apache,
tomcat 3.3 and tomcat 4.0
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-Origin
>| > - directories names in /usr/share/doc use version number
>(on rpm systems, i
>| > don't know for Debian), so it is yet another problem
>|
>| I had forgotten that feature of rpm. Maybe that's a reason to use
>| /usr/share/javadoc , at least on rpm systems.
>
>Why should Debian policy care a
>| > - directories names in /usr/share/doc use version number
>(on rpm systems, i
>| > don't know for Debian), so it is yet another problem
>|
>| I had forgotten that feature of rpm. Maybe that's a reason to use
>| /usr/share/javadoc , at least on rpm systems.
>
>Why should Debian policy care
>On Wed, Nov 28, 2001 at 04:15:59PM +0100, GOMEZ Henri wrote:
>
>> Did you take a look at my RPM for TC 3.3 and 4.0 ?
>
>To be honest, no. I think there are quite some differences between
>the .deb and .rpm, e.g. I'll stick with TOMCAT_HOME=/usr/share/tomcat
>and s
>On Tue, Nov 27, 2001 at 07:14:50PM +0100, Guillaume Rousse wrote:
>> Initial proposition had two points:
>> 1) always split javadoc-generated documentation in another package
>> 2) standardize javadoc location to cross-link generated documentation
>> There have been opposition againt 1), so lets'
>On Wed, Nov 28, 2001 at 04:15:59PM +0100, GOMEZ Henri wrote:
>
>> Did you take a look at my RPM for TC 3.3 and 4.0 ?
>
>To be honest, no. I think there are quite some differences between
>the .deb and .rpm, e.g. I'll stick with TOMCAT_HOME=/usr/share/tomcat
>and s
>On Tue, Nov 27, 2001 at 07:14:50PM +0100, Guillaume Rousse wrote:
>> Initial proposition had two points:
>> 1) always split javadoc-generated documentation in another package
>> 2) standardize javadoc location to cross-link generated documentation
>> There have been opposition againt 1), so lets'
Did you take a look at my RPM for TC 3.3 and 4.0 ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-Original Message-
>From: Stefa
Did you take a look at my RPM for TC 3.3 and 4.0 ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-Original Message-
>From: Stef
>ist it possible to perform a "quick update" to tomcat 3.3.x???
It will be good for users, since tomcat 3.3 is replacing Tomcat 3.2.x
as Reference Implementation of Servlet 2.2/JSP 1.1.
>i found the follwing in a mailing-list (after some hours of searching)
>
>...
>Your email does not indicate wh
>ist it possible to perform a "quick update" to tomcat 3.3.x???
It will be good for users, since tomcat 3.3 is replacing Tomcat 3.2.x
as Reference Implementation of Servlet 2.2/JSP 1.1.
>i found the follwing in a mailing-list (after some hours of searching)
>
>...
>Your email does not indicate w
>I got a message from Henri suggesting that I look at going to
>tomcat 3.3 and then building the
>connectors from jakarta-tomcat-connectors for ajp14.
Warning ajp14 in jtc is a currently under developpement
and don't expect a release before some weeks. For Tomcat 3.3
, you should consider ajp13 a
>I got a message from Henri suggesting that I look at going to
>tomcat 3.3 and then building the
>connectors from jakarta-tomcat-connectors for ajp14.
Warning ajp14 in jtc is a currently under developpement
and don't expect a release before some weeks. For Tomcat 3.3
, you should consider ajp13
>- should we contact FHS about this new directory (/usr/share/javadoc) ?
Yes
>- is cross-linking of javadoc an interesting/achievable feature ?
>When building foo package, depending of bar package, add -linkoffline
>/usr/share/javadoc/bar option to javadoc would provide
>cross-linked api
>docu
>- should we contact FHS about this new directory (/usr/share/javadoc) ?
Yes
>- is cross-linking of javadoc an interesting/achievable feature ?
>When building foo package, depending of bar package, add -linkoffline
>/usr/share/javadoc/bar option to javadoc would provide
>cross-linked api
>doc
Hi to all,
I'm working on RPM for java stuff, and have discussed
with some of you months ago on tomcat lists.
Question:
Where did you put the javadoc ?
I was thinking at /usr/share/javadoc, but I'd like to have your
opinion :)
ie:
/usr/share/javadoc/ant/
/usr/share/javadoc/tomcat/
/usr/share
>J> I hope this is not TOO stupid of a question but Tomcat uses
>J> port 8007 for communications with apache. Is there a way, or does
>J> it already exist, to tcp wrap this port? I have noticed that MANY
>J> other daemon or daemon like apckages support this function. Java on
>J> the other hand
Hi to all,
I'm working on RPM for java stuff, and have discussed
with some of you months ago on tomcat lists.
Question:
Where did you put the javadoc ?
I was thinking at /usr/share/javadoc, but I'd like to have your
opinion :)
ie:
/usr/share/javadoc/ant/
/usr/share/javadoc/tomcat/
/usr/shar
>J> I hope this is not TOO stupid of a question but Tomcat uses
>J> port 8007 for communications with apache. Is there a way, or does
>J> it already exist, to tcp wrap this port? I have noticed that MANY
>J> other daemon or daemon like apckages support this function. Java on
>J> the other hand
>I hope this is not TOO stupid of a question but
>
>Tomcat uses port 8007 for communications with apache.
Tomcat listen on port 8007 for ajp12 protocol
and 8009 for ajp13.
>Is there a way, or does it already exist, to tcp wrap this port?
Not really, tomcat do the real listen !
>I have noti
>I hope this is not TOO stupid of a question but
>
>Tomcat uses port 8007 for communications with apache.
Tomcat listen on port 8007 for ajp12 protocol
and 8009 for ajp13.
>Is there a way, or does it already exist, to tcp wrap this port?
Not really, tomcat do the real listen !
>I have not
51 matches
Mail list logo
