Re: Replacement for Windows service wrapper (procrun)

[calder]

On Fri, Dec 18, 2020, 17:16 Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Mladen,
>
> > I'd love to get some feedback from folks
> > that are using Apache Tomcat on Windows platform.
>
> I don't generally use Windows, so I don't have a horse in this race, but
> I'm curious as to the complaints against procrun versus what SvcBatch
> provides.



Can you give some examples of problems that SvcBatch solves?
>

+1

I think Mark already commented (though my memory is always questionable) on
this subject  : )


It's been a while since I configured a Tomcat on Windows, but it
> generally ends up being something like:
>
> SERVICE.BAT install MyTomcatInstanceName

[Bug 65007] Misleading instructions on import an SSL certificate

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65007

--- Comment #4 from Yuval Levin  ---
I don't know, it was the first time ever for me. I got from GoDaddy one CA
(bundle) and our trusted cert (alias=tomcat). the only way I could do it was to
add the -trustcacerts to the import of our trusted cert (alias=tomcat).
Also, the documentation does not explain the intermediate cert step, it has
only 2 steps, the chain cert (bundle) and the "tomcat" cert.
Somehow, something is missing there.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Replacement for Windows service wrapper (procrun)

[Christopher Schultz]

Mladen,

On 12/18/20 15:10, Mladen Turk wrote:

We use Procrun from Apache Commons Daemon project
as a service wrapper for Apache Tomcat for quite some time.
There are many problems with that package.

I have created a project named SvcBatch
https://github.com/mturk/svcbatch

It can be used for various deployments.
Apache Tomcat can use catalina.bat directly
for running service ... more details at
https://github.com/mturk/svcbatch/blob/master/docs/examples/apachetomcat.md


I'd love to get some feedback from folks
that are using Apache Tomcat on Windows platform.


I don't generally use Windows, so I don't have a horse in this race, but 
I'm curious as to the complaints against procrun versus what SvcBatch 
provides. Can you give some examples of problems that SvcBatch solves?


It's been a while since I configured a Tomcat on Windows, but it 
generally ends up being something like:


SERVICE.BAT install MyTomcatInstanceName

When you need to specify custom JVM options you mostly use the GUI to 
change them after the fact, but you can use %JvmArgs% to specify them, 
too. You can also use %JAVA_HOME%, %CATALINA_HOME%, and %CATALINA_BASE% 
if necessary.


The process for SvcBatch seems to be fairly similar to that of procrun.

-chris

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

[Bug 65007] Misleading instructions on import an SSL certificate

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65007

--- Comment #3 from Christopher Schultz  ---
(In reply to Yuval Levin from comment #2)
> Maybe I had to specify, but this is in the part that explains how to import
> a CA Authority cert.

Good point. Note that -trustcacerts should only be necessary when importing the
CA's intermediate certificate into a trust store. Once the intermediate cert is
in the trust store, importing your server's certificate does not require the
-trustcacerts -- because the intermediate cert is already in your trust store
and therefore already trusted :)

> BTW the documentation of 8.0 has the same explanation.

And 7.0, 9.0, and 10.0. Note that 8.0 reached EOL in 2018.

Patches are always welcome.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65007] Misleading instructions on import an SSL certificate

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65007

--- Comment #2 from Yuval Levin  ---
Maybe I had to specify, but this is in the part that explains how to import a
CA Authority cert.
BTW the documentation of 8.0 has the same explanation.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65007] Misleading instructions on import an SSL certificate

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65007

--- Comment #1 from Christopher Schultz  ---
Perhaps the HOWTO could explain the difference between using -trustcacerts and
not using -trustcacerts, but it's not true that the existing instructions "do
not work" and that adding -trustcacerts will solve the problem.

Whether or not -trustcacerts should be provided on the command-line depends
upon the usage scenario for the user.

For example, if you are importing a self-signed certificate, specifying
-trustcacerts is never necessary. It's very common to use a self-signed
certificate for a Tomcat server, so I suspect this is why the documentation
omits the use of -trustcacerts.

If you are importing a certificate you expect to be signed by a local CA (e.g.
a corporate internal one) then you specifically DO NOT want to specify
-trustcacerts as a sanity check against importing a certificate that has been
signed by a globally-trustued CA (e.g. VeriSign).

Would you care to submit a documentation patch which explains the difference,
and when you might want (or need) to include the -trustcacerts command-line
option?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] ChristopherSchultz edited a comment on pull request #395: Replace C-style array declaring with Java-style array declaring

[GitBox]

ChristopherSchultz edited a comment on pull request #395:
URL: https://github.com/apache/tomcat/pull/395#issuecomment-748337399


   Yes, please use Java-style array declaration syntax in new code. If you edit 
existing code which includes C-style array syntax (e.g. `char foo[]`), please 
update it to Java-style. But don't just change them to change them.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [tomcat] ChristopherSchultz commented on pull request #395: Replace C-style array declaring with Java-style array declaring

[GitBox]

ChristopherSchultz commented on pull request #395:
URL: https://github.com/apache/tomcat/pull/395#issuecomment-748337399


   Yes, please use Java-style array declaration syntax in new code.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[Bug 65007] Misleading instructions on import an SSL certificate

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65007

Yuval Levin  changed:

   What|Removed |Added

URL||http://tomcat.apache.org/to
   ||mcat-8.5-doc/ssl-howto.html
   ||#Installing_a_Certificate_f
   ||rom_a_Certificate_Authority

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65007] New: Misleading instructions on import an SSL certificate

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65007

Bug ID: 65007
   Summary: Misleading instructions on import an SSL certificate
   Product: Tomcat 8
   Version: 8.5.x-trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Documentation
  Assignee: dev@tomcat.apache.org
  Reporter: yu...@speechmorphing.com
  Target Milestone: 

In the page
http://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Installing_a_Certificate_from_a_Certificate_Authority

The instructions to "Importing the Certificate" are misleading:
the command:
keytool -import -alias tomcat -keystore 
-file 

Does not work and it should read:
keytool -import -alias tomcat -keystore 
   -trustcacerts -file 

Thanks,
Y.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Replacement for Windows service wrapper (procrun)

[Mladen Turk]

Hi

We use Procrun from Apache Commons Daemon project
as a service wrapper for Apache Tomcat for quite some time.
There are many problems with that package.

I have created a project named SvcBatch
https://github.com/mturk/svcbatch

It can be used for various deployments.
Apache Tomcat can use catalina.bat directly
for running service ... more details at
https://github.com/mturk/svcbatch/blob/master/docs/examples/apachetomcat.md


I'd love to get some feedback from folks
that are using Apache Tomcat on Windows platform.


Regards
--
^TM

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

[GitHub] [tomcat] zzk0 commented on pull request #395: Replace C-style array declaring with Java-style array declaring

[GitBox]

zzk0 commented on pull request #395:
URL: https://github.com/apache/tomcat/pull/395#issuecomment-748166928


   > There are many of those. A quick search shows around 400 occurrences of 
the C-style.
   > I am not sure this is worth it. It will make backporting very hard.
   
   What if we write new code? Should we write the Java-style array?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

Re: Compat versions

[Rémy Maucherat]

On Fri, Dec 18, 2020 at 2:56 PM Romain Manni-Bucau 
wrote:

> Hmm, a few thoughts on this topic:
>
> 1. there is no reason to use reflection in jrecompat (all the java > build
> time version) impl can be generated in ant build using asm or bcel
> 2. all JreCompat are kind of hardcoded SPI, if this API gets a "ordinal" -
> priority - and a "matches(int javaMajor)" then it becomes simple to pick
> only the highest impl matching current java version (ie on java 8 it will
> use the default, on java 12 it will use java12 or 11 or  8 impl, on
> java 17 it will use java 17 impl etc).
>
> So overall it is mainly about making the maintenance of the code easier but
> not about dropping any feature or reducing support list IMHO.
> Build time generation can help a lot with that (@Implement(spi =
> JreCompat.class, since = 12) which would lead to jrecompat12, jrecompat13,
> , jrecompatLast override of an impl for a method - being said playing
> with inheritence between versions enables to drop duplication).
> This kind of tool is not harder than the jakarta migration tool and can
> solve that "fast pace" issue IMHO.
> Requires some build/tool investment but it likely interesting to keep a
> high support level for end user and reduce maintenance cost for tomcat
> itself.
>
> Hope it makes sense.
>

This is more than what I expected to do.

But ok, I got the main feedback from you and Chris, the compatibility
should be kept per branch. I have a hard time seeing us give any support to
users running on Java 13 (just an example) though, but ok it doesn't need
to be made more difficult.

Rémy


>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 18 déc. 2020 à 14:33, Christopher Schultz <
> ch...@christopherschultz.net> a écrit :
>
> > Rémy,
> >
> > On 12/18/20 08:20, Rémy Maucherat wrote:
> > > On Fri, Dec 18, 2020 at 12:19 PM Martin Grigorov  >
> > > wrote:
> > >
> > >> On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat 
> > wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I'd like to refactor the compat classes to align with the LTS
> versions:
> > >>> - Move Jre9Compat to Jre11Compat
> > >>> - I'll probably refactor out GraalCompat
> > >>> - For the upcoming Java 12+ features, they will all go to a new
> > >> Jre17Compat
> > >>>
> > >>
> > >> s/Java 12+/Java 17+/, right ?
> > >>
> > >
> > > I mean: for any features that are only present in Java 12 to 17 that we
> > > would want to use in Tomcat, then they will all be implemented through
> > > reflection in a Jre17Compat class. Example, if UDS support is added, it
> > > will go into that class even though previously it would have been in
> > > Jre16Compat.
> > >
> > > Effectively, this drops guaranteed support for all Java non LTS
> releases
> > > except the most recent one, so you either have to use one of the LTS or
> > the
> > > most recent Java.
> >
> > I don't see a reason to restrict users in this way.
> >
> > If a feature is added in Java 9, why not put it in a Java9Compat class
> > and allow it to work on Java 9, 10, etc.? I realize that may add more
> > JavaXCompat classes but I really don't see a particular reason to
> > restrict or misrepresent Java versions.
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>

Re: Compat versions

[Romain Manni-Bucau]

Hmm, a few thoughts on this topic:

1. there is no reason to use reflection in jrecompat (all the java > build
time version) impl can be generated in ant build using asm or bcel
2. all JreCompat are kind of hardcoded SPI, if this API gets a "ordinal" -
priority - and a "matches(int javaMajor)" then it becomes simple to pick
only the highest impl matching current java version (ie on java 8 it will
use the default, on java 12 it will use java12 or 11 or  8 impl, on
java 17 it will use java 17 impl etc).

So overall it is mainly about making the maintenance of the code easier but
not about dropping any feature or reducing support list IMHO.
Build time generation can help a lot with that (@Implement(spi =
JreCompat.class, since = 12) which would lead to jrecompat12, jrecompat13,
, jrecompatLast override of an impl for a method - being said playing
with inheritence between versions enables to drop duplication).
This kind of tool is not harder than the jakarta migration tool and can
solve that "fast pace" issue IMHO.
Requires some build/tool investment but it likely interesting to keep a
high support level for end user and reduce maintenance cost for tomcat
itself.

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 18 déc. 2020 à 14:33, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> Rémy,
>
> On 12/18/20 08:20, Rémy Maucherat wrote:
> > On Fri, Dec 18, 2020 at 12:19 PM Martin Grigorov 
> > wrote:
> >
> >> On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> I'd like to refactor the compat classes to align with the LTS versions:
> >>> - Move Jre9Compat to Jre11Compat
> >>> - I'll probably refactor out GraalCompat
> >>> - For the upcoming Java 12+ features, they will all go to a new
> >> Jre17Compat
> >>>
> >>
> >> s/Java 12+/Java 17+/, right ?
> >>
> >
> > I mean: for any features that are only present in Java 12 to 17 that we
> > would want to use in Tomcat, then they will all be implemented through
> > reflection in a Jre17Compat class. Example, if UDS support is added, it
> > will go into that class even though previously it would have been in
> > Jre16Compat.
> >
> > Effectively, this drops guaranteed support for all Java non LTS releases
> > except the most recent one, so you either have to use one of the LTS or
> the
> > most recent Java.
>
> I don't see a reason to restrict users in this way.
>
> If a feature is added in Java 9, why not put it in a Java9Compat class
> and allow it to work on Java 9, 10, etc.? I realize that may add more
> JavaXCompat classes but I really don't see a particular reason to
> restrict or misrepresent Java versions.
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Compat versions

[Christopher Schultz]

Rémy,

On 12/18/20 08:20, Rémy Maucherat wrote:

On Fri, Dec 18, 2020 at 12:19 PM Martin Grigorov 
wrote:


On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat  wrote:


Hi,

I'd like to refactor the compat classes to align with the LTS versions:
- Move Jre9Compat to Jre11Compat
- I'll probably refactor out GraalCompat
- For the upcoming Java 12+ features, they will all go to a new

Jre17Compat




s/Java 12+/Java 17+/, right ?



I mean: for any features that are only present in Java 12 to 17 that we
would want to use in Tomcat, then they will all be implemented through
reflection in a Jre17Compat class. Example, if UDS support is added, it
will go into that class even though previously it would have been in
Jre16Compat.

Effectively, this drops guaranteed support for all Java non LTS releases
except the most recent one, so you either have to use one of the LTS or the
most recent Java.


I don't see a reason to restrict users in this way.

If a feature is added in Java 9, why not put it in a Java9Compat class 
and allow it to work on Java 9, 10, etc.? I realize that may add more 
JavaXCompat classes but I really don't see a particular reason to 
restrict or misrepresent Java versions.


-chris

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

Re: Compat versions

[Rémy Maucherat]

On Fri, Dec 18, 2020 at 12:19 PM Martin Grigorov 
wrote:

> On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat  wrote:
>
> > Hi,
> >
> > I'd like to refactor the compat classes to align with the LTS versions:
> > - Move Jre9Compat to Jre11Compat
> > - I'll probably refactor out GraalCompat
> > - For the upcoming Java 12+ features, they will all go to a new
> Jre17Compat
> >
>
> s/Java 12+/Java 17+/, right ?
>

I mean: for any features that are only present in Java 12 to 17 that we
would want to use in Tomcat, then they will all be implemented through
reflection in a Jre17Compat class. Example, if UDS support is added, it
will go into that class even though previously it would have been in
Jre16Compat.

Effectively, this drops guaranteed support for all Java non LTS releases
except the most recent one, so you either have to use one of the LTS or the
most recent Java.


>
>
> > class, which will actually be useable in the meantime by the latest Java
> > milestone release from which the interesting features come from
> >
> > Although not fully accurate, this is more maintainable as the interim non
> > LTS Java releases quickly come and go and are not good platforms for
> > Tomcat.
> >
>
> +1
>

Rémy

>
>
>
> >
> > Rémy
> >
>

Re: Compat versions

[Martin Grigorov]

On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat  wrote:

> Hi,
>
> I'd like to refactor the compat classes to align with the LTS versions:
> - Move Jre9Compat to Jre11Compat
> - I'll probably refactor out GraalCompat
> - For the upcoming Java 12+ features, they will all go to a new Jre17Compat
>

s/Java 12+/Java 17+/, right ?


> class, which will actually be useable in the meantime by the latest Java
> milestone release from which the interesting features come from
>
> Although not fully accurate, this is more maintainable as the interim non
> LTS Java releases quickly come and go and are not good platforms for
> Tomcat.
>

+1



>
> Rémy
>

Compat versions

[Rémy Maucherat]

Hi,

I'd like to refactor the compat classes to align with the LTS versions:
- Move Jre9Compat to Jre11Compat
- I'll probably refactor out GraalCompat
- For the upcoming Java 12+ features, they will all go to a new Jre17Compat
class, which will actually be useable in the meantime by the latest Java
milestone release from which the interesting features come from

Although not fully accurate, this is more maintainable as the interim non
LTS Java releases quickly come and go and are not good platforms for Tomcat.

Rémy