Re: EE 8 / 9 TCK status

2020-11-17 Thread Romain Manni-Bucau
Hi JL,

did you check
https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs out?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 17 nov. 2020 à 10:16, Jean-Louis MONTEIRO  a
écrit :

> Hello community,
>
> I'm working on the TCK in the TomEE project which leverages Tomcat.
> I was running the TCK and I realized JSTL/JSP/Servlet/WebSockets aren't
> 100% green.
>
> I'm questioning my setup. That's why I wanted to ask if you guys spent time
> running the TCK against Tomcat. And if yes, is Tomcat 100% compatible?
>
> --
> Jean-Louis
>


Re: Application-accesible Executors

2020-09-22 Thread Romain Manni-Bucau
Le mar. 22 sept. 2020 à 08:54, Martin Grigorov  a
écrit :

> Hi Chris,
>
> On Fri, Sep 18, 2020 at 7:10 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > All,
> >
> > I've recently been thinking about application uses of servlet-async and
> > Websocket for long-running operations, or really for any interactions
> > where you want to allow the request-processing thread to go back into
> > the pool, but the application is still doing useful things and therefore
> > needs its own thread.
> >
> > I'm thinking of something like SwingUtilities.invokeLater, though that
> > does something very specific that is AWT-related, of course.
> >
> > I don't believe there is a (JavaEE/JakartaEE) standard for this, so I'm
> > interested in what others think might be a good idea from a Tomcat
> > standpoint.
> >
>
> I haven't used Java EE since version 5 but I do remember it having such
> utilities:
> https://docs.oracle.com/javaee/7/tutorial/concurrency-utilities.htm
>
>
> >
> >
> > It's fairly easy to do something like this in one's own web application,
> > maybe using a ServletContextListener:
> >
> > public class ExecutorProvider
> >   implements ServletContextListener
> > {
> >   public static final EXECUTOR_SERVICE_KEY = "executor-service";
> >
> >   private ExecutorService _svc;
> >
> >   public void contextInitialized(ServletContext ctx) {
> > _svc = Executors.newFixedThreadPool(10); // ?
> >
> > ctx.setAttribute(EXECUTOR_SERVICE_KEY, _svc);
> >   }
> >
> >   public void contextDestroyed(ServletContext ctx) {
> > ctx.removeAttribute(EXECUTOR_SERVICE_KEY);
> > _svc.shutdown();
> >   }
> > }
> >
> > Then in a servlet, etc. you could:
> >
> >
> >
> ((ExecutorService)ctx.getAttribute(ExecutorProvider.EXECUTOR_SERVICE_KEY)).submit(new
> > Runnable() {
> > public void run() {
> > // your code goes here
> > }
> > });
> >
> > I'm wondering if there is scope here for Tomcat to provide this kind of
> > service for applications that want to opt-into one. Maybe the above is
> > so trivial as to not be worth it at all. But maybe it would be a nice
> >
>
> I agree - it is trivial.
> But also: does it work for everyone's use case ?
> Some will need a fixed pool for CPU bound tasks, others will need a cached
> pool for IO bound tasks, and others may need a scheduled pool ... And then
> you'll need to provide a way to name the threads ...
> Of course you can introduce pools of all types but is it easier to define
> them in XML (server.xml, context.xml) or in Java code (as you did above) ?
>

Hmm, a few points:

1. You are right, I think the only thing the mentionned impl does not
handle is the cached executor service but it is trivial to add (but has the
pitfall to make the app less deterministic), everything else is there.
2. Java code definition is trivial by nature (since it is java code) and
XML support is there too (tomee flavor:
https://tomee.apache.org/admin/configuration/resources.html#_managedexecutorservice,
tomcat one too since tomcat has a XML factory support - setters, factory
method etc, same as for datasources). Indeed it does not bring a specific
XML support (and I have to admit it is a very good thing) but it is coded
to be "XML factory friendly" so we are all good there, in particular in
Tomcat.
3. Assuming you don't go with the standard and share an impl @asf, wouldn't
you just redo exactly the same thing? Sounds like it is the proposed path
anyway, no? So probably better to make a single community rather than split
it since this part is pretty simple and stable IMHO.

Indeed, just my opinion but from my experience it is always trivial to
launch a new project, it is way harder to make it last in time in terms of
community, here spec helps and we can easily make it usable outside a full
EE container (ie just servlet container scope).


>
> My 2c
> Martin
>
>
> > service to provide to web applications, or maybe across multiple web
> > applications in some kind of group. Or it might survive context restarts
> > for some reason.
> >
> > Having this provided by Tomcat would allow admins to maybe override the
> > sizes of the thread pools and other details that the application then
> > wouldn't need to worry about.
> >
> > It might even tie-into Tomcat's utility-executor if that makes any sense
> > 0-- though we'd have to make sure it executes in the right ClassLoader
> > and/or security context.
> >
> > Any thoughts on this? Or is it really such a trivial thing as to not
> > really be useful to anyone. Maybe simply providing a
> > ServletContextListener class like the one above (with obvious robustness
> > improvements) that anyone could configure for their own application
> > would be sufficient/useful to users.
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>


Re: WsFilter is missing destroy method

2020-09-21 Thread Romain Manni-Bucau
Hi Ralph,

Did you check your api jar was matching tomcat impl version? destroy is in
the interface (default method):
https://github.com/apache/tomcat/blob/9.0.x/java/javax/servlet/Filter.java#L119
So without more details it sounds you have a dependency conflict or
outdated import.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 22 sept. 2020 à 07:22, Ralph Goers  a écrit :

> I don’t understand why
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63528 <
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63528> was closed with the
> comment “bugzilla is not a support forum”.  Where else is one supposed to
> report bugs in Tomcat as this is a legitimate bug?  It seems that WsFilter
> and GenericFilter were modified around the same time and at various points
> in time one or the other had a destroy method, but in the end neither did
> and it results in an error whenever the embedded tomcat in Spring Boot
> shuts down. This bug still exists in 9.0.38.
>
> Ralph


Re: Application-accesible Executors

2020-09-18 Thread Romain Manni-Bucau
Hi Chris,

Isn't it EE concurrency utilities?
executors are injectable and designed to be used by the app and managed by
the container.
you can find an impl (for sample purposes) in
https://github.com/apache/tomee/tree/master/container/openejb-core/src/main/java/org/apache/openejb/threads,
then it is just a matter of defining it as resources in tomcat and do a
lookup in any init method to get it I think, we can.
Code is trivially extractable from tomee if it is what you have in mind and
Apache Geronimo can be a "shared" home for such lib by "design".

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 18 sept. 2020 à 18:10, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> All,
>
> I've recently been thinking about application uses of servlet-async and
> Websocket for long-running operations, or really for any interactions
> where you want to allow the request-processing thread to go back into
> the pool, but the application is still doing useful things and therefore
> needs its own thread.
>
> I'm thinking of something like SwingUtilities.invokeLater, though that
> does something very specific that is AWT-related, of course.
>
> I don't believe there is a (JavaEE/JakartaEE) standard for this, so I'm
> interested in what others think might be a good idea from a Tomcat
> standpoint.
>
>
> It's fairly easy to do something like this in one's own web application,
> maybe using a ServletContextListener:
>
> public class ExecutorProvider
>   implements ServletContextListener
> {
>   public static final EXECUTOR_SERVICE_KEY = "executor-service";
>
>   private ExecutorService _svc;
>
>   public void contextInitialized(ServletContext ctx) {
> _svc = Executors.newFixedThreadPool(10); // ?
>
> ctx.setAttribute(EXECUTOR_SERVICE_KEY, _svc);
>   }
>
>   public void contextDestroyed(ServletContext ctx) {
> ctx.removeAttribute(EXECUTOR_SERVICE_KEY);
> _svc.shutdown();
>   }
> }
>
> Then in a servlet, etc. you could:
>
>
> ((ExecutorService)ctx.getAttribute(ExecutorProvider.EXECUTOR_SERVICE_KEY)).submit(new
> Runnable() {
> public void run() {
> // your code goes here
> }
> });
>
> I'm wondering if there is scope here for Tomcat to provide this kind of
> service for applications that want to opt-into one. Maybe the above is
> so trivial as to not be worth it at all. But maybe it would be a nice
> service to provide to web applications, or maybe across multiple web
> applications in some kind of group. Or it might survive context restarts
> for some reason.
>
> Having this provided by Tomcat would allow admins to maybe override the
> sizes of the thread pools and other details that the application then
> wouldn't need to worry about.
>
> It might even tie-into Tomcat's utility-executor if that makes any sense
> 0-- though we'd have to make sure it executes in the right ClassLoader
> and/or security context.
>
> Any thoughts on this? Or is it really such a trivial thing as to not
> really be useful to anyone. Maybe simply providing a
> ServletContextListener class like the one above (with obvious robustness
> improvements) that anyone could configure for their own application
> would be sufficient/useful to users.
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: [tomcat] branch master updated: Simpler way to determine Graal runtime

2020-07-23 Thread Romain Manni-Bucau
Hmm, for me you have 3 modes:

1. Plain vm -> we dont care
2. Native image generator (
https://github.com/oracle/graal/blob/901ad5cf25d145909d1eca36cbb86765697dcc0b/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/NativeImageGenerator.java#L506
so it is set)
3. Native run -> substitution works

Optional case 4 is the javaagent but this one is not needed normally for
tomcat or is a dev thing so does not need to be implicit (we can set the
property if still used but i suspect once a first flavor is generated it is
no more used and just integrated in tomcat then updated manually).

Do I miss something?

Le jeu. 23 juil. 2020 à 03:02, Filip Hanik  a écrit :

> Hi Romain,
>
> > -Original Message-
> > From: Romain Manni-Bucau 
> > Sent: Wednesday, July 22, 2020 12:48 PM
> > To: Tomcat Developers List 
> > Subject: Re: [tomcat] branch master updated: Simpler way to determine
> Graal
> > runtime
> >
> > Thinking out loud: cant you substitute it to be hardcoded to true in
> native
> > mode? This way you get the best of both.
>
> This works for when you compile it to native code. Remy was talking about
> when running under the Substrate VM as a Java application. That's when I
> experience test failures and prompted me to look into a change.
> If I understand it correctly, the substrate VM doesn't pick up those
> substitutions when running in Java mode.
>
> Filip
>
> >
> > Le mer. 22 juil. 2020 à 20:17, Filip Hanik  > <mailto:fha...@vmware.com> > a écrit :
> >
> >
> >   Thanks Remy,
> >
> >
> >
> >   I ran into some failures when running the test suite using the
> substrate
> > VM, but it makes more sense to adjust those tests.
> >
> >   I’ll revert these today
> >
> >
> >
> >   Filip
> >
> >
> >
> >   From: Rémy Maucherat  > <mailto:r...@apache.org> >
> > Sent: Wednesday, July 22, 2020 12:10 AM
> >   To: Tomcat Developers List  > <mailto:dev@tomcat.apache.org> >
> >   Subject: Re: [tomcat] branch master updated: Simpler way to
> > determine Graal runtime
> >
> >
> >
> >   On Tue, Jul 21, 2020 at 11:16 PM  > <mailto:fha...@apache.org> > wrote:
> >
> >   This is an automated email from the ASF dual-hosted git
> > repository.
> >
> >   fhanik pushed a commit to branch master
> >   in repository
> > https://gitbox.apache.org/repos/asf/tomcat.git
> > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitb
> > o
> > x.apache.org%2Frepos%2Fasf%2Ftomcat.git=02%7C01%7Cfhanik%40v
> > mware.c
> > om%7C5bb8217a67084dc6f0e308d82e791421%7Cb39138ca3cee4b4aa4d6c
> > d83d9dd62f0
> > %7C0%7C0%7C637310444856257107=T20lk9hPTLaJGtrD5ZLD3OVzkC
> > amedtpcKo2
> > V4MwXtg%3D=0>
> >
> >
> >   The following commit(s) were added to refs/heads/master by
> > this push:
> >new 098c4c8  Simpler way to determine Graal runtime
> >   098c4c8 is described below
> >
> >   commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
> >   Author: Filip Hanik  > <mailto:fha...@pivotal.io> >
> >   AuthorDate: Tue Jul 21 14:04:57 2020 -0700
> >
> >   Simpler way to determine Graal runtime
> >
> >   Also, allows to mock the behavior
> >
> > https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.h
> > t
> > ml#PROPERTY_IMAGE_CODE_KEY
> > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.g
> > raalvm.org%2Fsdk%2Fjavadoc%2Forg%2Fgraalvm%2Fnativeimage%2FImageI
> > nfo.htm
> > l%23PROPERTY_IMAGE_CODE_KEY=02%7C01%7Cfhanik%40vmware.co
> > m%7C5bb8217
> > a67084dc6f0e308d82e791421%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7
> > C0%7C0%7C6
> > 37310444856267104=vHbmuRW5YP1%2B2a6romOsuaxaUHqMqF9G4
> > ob7aXlSYbY%3D
> > =0>
> >   ---
> >java/org/apache/jasper/runtime/JspRuntimeLibrary.java |
> > 16 +---
> >java/org/apache/naming/NamingContext.java |
> > 15 +--
> >java/org/apache/tomcat/util/compat/GraalCompat.java   |
> > 15 +--
> >3 files changed, 3 insertions(+), 43 deletions(-)
> >
> >   diff --git
> > a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> > b/java/org/apache/jasper/runtime/JspRuntimeLibra

Re: [tomcat] branch master updated: Simpler way to determine Graal runtime

2020-07-22 Thread Romain Manni-Bucau
Thinking out loud: cant you substitute it to be hardcoded to true in native
mode? This way you get the best of both.

Le mer. 22 juil. 2020 à 20:17, Filip Hanik  a écrit :

> Thanks Remy,
>
>
>
> I ran into some failures when running the test suite using the substrate
> VM, but it makes more sense to adjust those tests.
>
> I’ll revert these today
>
>
>
> Filip
>
>
>
> *From:* Rémy Maucherat 
> *Sent:* Wednesday, July 22, 2020 12:10 AM
> *To:* Tomcat Developers List 
> *Subject:* Re: [tomcat] branch master updated: Simpler way to determine
> Graal runtime
>
>
>
> On Tue, Jul 21, 2020 at 11:16 PM  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> fhanik pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 098c4c8  Simpler way to determine Graal runtime
> 098c4c8 is described below
>
> commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
> Author: Filip Hanik 
> AuthorDate: Tue Jul 21 14:04:57 2020 -0700
>
> Simpler way to determine Graal runtime
>
> Also, allows to mock the behavior
>
> https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.html#PROPERTY_IMAGE_CODE_KEY
> 
> ---
>  java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 16
> +---
>  java/org/apache/naming/NamingContext.java | 15 +--
>  java/org/apache/tomcat/util/compat/GraalCompat.java   | 15 +--
>  3 files changed, 3 insertions(+), 43 deletions(-)
>
> diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> index cfb6e75..f27ce3b 100644
> --- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> +++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> @@ -56,21 +56,7 @@ import org.apache.tomcat.InstanceManager;
>   */
>  public class JspRuntimeLibrary {
>
> -public static final boolean GRAAL;
> -
> -static {
> -boolean result = false;
> -try {
> -Class nativeImageClazz =
> Class.forName("org.graalvm.nativeimage.ImageInfo");
> -result =
> nativeImageClazz.getMethod("inImageCode").invoke(null) != null;
> -// Note: This will also be true for the Graal substrate VM
>
>
>
> As the comment says, this must also be true when running on the substrate
> VM (= building a native image) and from what I can see this is not the
> case. Basically the code paths used on Graal must be consistent.
>
> So it's simpler but it doesn't seem to work at this time, so you need to
> revert this commit. You could get out of this by saying the user can just
> set the system property, but this makes things more error prone so it's a
> bad idea as the previous solution worked just fine.
>
>
>
> I see an enhancement to fix this as the agent would set the system
> property: https://github.com/oracle/graal/issues/2395
> 
>
> But the Oracle folks said "no" because they can. As usual :D
>
>
>
> Rémy
>
>
>
> -} catch (ClassNotFoundException e) {
> -// Must be Graal
> -} catch (ReflectiveOperationException | IllegalArgumentException
> e) {
> -// Should never happen
> -}
> -GRAAL = result;
> -}
> +public static final boolean GRAAL =
> System.getProperty("org.graalvm.nativeimage.imagecode") != null;
>
>  /**
>   * Returns the value of the jakarta.servlet.error.exception request
> diff --git a/java/org/apache/naming/NamingContext.java
> b/java/org/apache/naming/NamingContext.java
> index 0471279..40f4085 100644
> --- a/java/org/apache/naming/NamingContext.java
> +++ b/java/org/apache/naming/NamingContext.java
> @@ -792,20 +792,7 @@ public class NamingContext implements Context {
>  // -- Protected
> Methods
>
>
> -private static final boolean GRAAL;
> -
> -static {
> -boolean result = false;
> -try {
> -Class nativeImageClazz 

Re: Jakarta EE APIs

2020-07-22 Thread Romain Manni-Bucau
Le mer. 22 juil. 2020 à 18:29, Mark Thomas  a écrit :

> On 22/07/2020 17:11, Romain Manni-Bucau wrote:
> > Hi Mark,
> >
> > Another option is to use Apache Geronimo specs (and update/create
> > missing ones - think new mail one is not yet there for ex).
>
> This is a distinct disadvantage.
>

You mean not having it handy?
Think it is 1-1 with current option except it solves the fact to have it
within tomcat.



> > Advantage would be we wouldn't lose all the work around OSGi and jpms
> > eclipse does not - and will not probably - handle (at least for the
> > first part).
>
> As compile time only JARs OSGi and JPMS are not a factor.
>
> > It also cleans up the legal work for Tomcat as a small side bonus.
>
> They are all EPLv2 licensed and compile time only so there isn't any
> legal work required.
>

Didnt check recently but think you still must bundle their license and do
some notice work.


> Mark
>
>
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 22 juil. 2020 à 17:53, Mark Thomas  > <mailto:ma...@apache.org>> a écrit :
> >
> > On 22/07/2020 15:53, Mark Thomas wrote:
> > > Hi all,
> > >
> > > We currently have implementations for all of the Jakarta APIs that
> > ship with Tomcat and partial implementations for 5 additional
> > Jakarta APIs that are compile time only dependencies.
> > >
> > > I was checking those partial implementations earlier today when I
> > noticed the Jakarta Mail API needed updating to use generics. I
> > started on that but paused when it looked like a number of new
> > (dummy) classes would be required.
> > >
> > > Considering alternative options, I wondered about depending on the
> > Jakarta API JARs directly. This would be a return to the 5.5.x era
> > approach without  hopefully, the issue that JARs could be difficult
> > to obtain.
> > >
> > > I have this implemented locally. It removes about 1000 lines of
> > .java files (although just under 10% of them are actual code) and
> > adds about 100 lines of build file config and anither 50 of IDE
> > configuration.
> > >
> > > With the Jakarta JARs being readily available in Maven Central I
> > think the primary issue that led to the current approach is no
> > longer a concern.
> > >
> > > Thoughts on switching to using the JARs directly? I can provide a
> > PR if that is helpful.
> >
> > For clarity, I'm only proposing to do this for Tomcat 10 where at
> least
> > one of these APIs has changes other than just a package rename. I
> don't
> > see the benefit in doing this for Tomact 9 and earlier.
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > <mailto:dev-unsubscr...@tomcat.apache.org>
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > <mailto:dev-h...@tomcat.apache.org>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: Jakarta EE APIs

2020-07-22 Thread Romain Manni-Bucau
Hi Mark,

Another option is to use Apache Geronimo specs (and update/create missing
ones - think new mail one is not yet there for ex).
Advantage would be we wouldn't lose all the work around OSGi and jpms
eclipse does not - and will not probably - handle (at least for the first
part).
It also cleans up the legal work for Tomcat as a small side bonus.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 22 juil. 2020 à 17:53, Mark Thomas  a écrit :

> On 22/07/2020 15:53, Mark Thomas wrote:
> > Hi all,
> >
> > We currently have implementations for all of the Jakarta APIs that ship
> with Tomcat and partial implementations for 5 additional Jakarta APIs that
> are compile time only dependencies.
> >
> > I was checking those partial implementations earlier today when I
> noticed the Jakarta Mail API needed updating to use generics. I started on
> that but paused when it looked like a number of new (dummy) classes would
> be required.
> >
> > Considering alternative options, I wondered about depending on the
> Jakarta API JARs directly. This would be a return to the 5.5.x era approach
> without  hopefully, the issue that JARs could be difficult to obtain.
> >
> > I have this implemented locally. It removes about 1000 lines of .java
> files (although just under 10% of them are actual code) and adds about 100
> lines of build file config and anither 50 of IDE configuration.
> >
> > With the Jakarta JARs being readily available in Maven Central I think
> the primary issue that led to the current approach is no longer a concern.
> >
> > Thoughts on switching to using the JARs directly? I can provide a PR if
> that is helpful.
>
> For clarity, I'm only proposing to do this for Tomcat 10 where at least
> one of these APIs has changes other than just a package rename. I don't
> see the benefit in doing this for Tomact 9 and earlier.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: JAX-RPC and Tomcat 10

2020-07-21 Thread Romain Manni-Bucau
Yes, was thinking to tomee in particular since it does not use tomcat as a
lib but really as the container so if the container fails then it can
become hard if not "disabl-able" somehow (at least with subclassing or
something programmatic).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 21 juil. 2020 à 15:39, Mark Thomas  a écrit :

> On 21/07/2020 14:26, Romain Manni-Bucau wrote:
> > Hi Mark,
> >
> > e) c as default + add a toggle to behave as a? (thinking to container
> > extending tomcat where this shouldn't fail probably)
>
> So keep the attributes in ContextService and friends that record the
> JAX-RPC so they are accessible to downstream projects that still want to
> support JAX-RPC? Are there any such projects? TomEE?
>
> Mark
>
>
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 21 juil. 2020 à 14:34, Mark Thomas  > <mailto:ma...@apache.org>> a écrit :
> >
> > All,
> >
> > JAX-RPC has been removed in Jakarta EE 9.
> >
> > Implementations are free to continue supporting it if they wish.
> >
> > My preference would be to remove JAX-RPS support in Tomcat 10.
> >
> > I am working on this at the moment and am wondering how to handle the
> > JAX-RPC elements we can't entirely remove.
> >
> > There is a chain of references from web-app_5_0.xsd to
> > jakartaee_web_services_client_2_0.xsd which still has a number of
> > JAX-RPC specific attributes defined for "service-ref":
> >
> > - jaxrpc-mapping-file
> > - handler
> > - handler-chains
> >
> > (a double check I have identified all the JAX-RPC specific attributes
> > would be appreciated)
> >
> > This appears to be a consequence of the same element being used for
> > JAX-RPC and JAX-WS.
> >
> > Assuming there is consensus to remove JAX-RPC support then the
> question
> > arises what do we do if we observe one of the JAX-RPC specific
> > attributes above? Possible options include:
> >
> > a) Ignore it and carry on
> > b) Log a warning but otherwise ignore it and carry on
> > c) Log an error and fail the deployment
> > d) Something else
> >
> > I'm currently leaning towards option c.
> >
> > Thoughts?
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > <mailto:dev-unsubscr...@tomcat.apache.org>
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > <mailto:dev-h...@tomcat.apache.org>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: JAX-RPC and Tomcat 10

2020-07-21 Thread Romain Manni-Bucau
Hi Mark,

e) c as default + add a toggle to behave as a? (thinking to container
extending tomcat where this shouldn't fail probably)

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 21 juil. 2020 à 14:34, Mark Thomas  a écrit :

> All,
>
> JAX-RPC has been removed in Jakarta EE 9.
>
> Implementations are free to continue supporting it if they wish.
>
> My preference would be to remove JAX-RPS support in Tomcat 10.
>
> I am working on this at the moment and am wondering how to handle the
> JAX-RPC elements we can't entirely remove.
>
> There is a chain of references from web-app_5_0.xsd to
> jakartaee_web_services_client_2_0.xsd which still has a number of
> JAX-RPC specific attributes defined for "service-ref":
>
> - jaxrpc-mapping-file
> - handler
> - handler-chains
>
> (a double check I have identified all the JAX-RPC specific attributes
> would be appreciated)
>
> This appears to be a consequence of the same element being used for
> JAX-RPC and JAX-WS.
>
> Assuming there is consensus to remove JAX-RPC support then the question
> arises what do we do if we observe one of the JAX-RPC specific
> attributes above? Possible options include:
>
> a) Ignore it and carry on
> b) Log a warning but otherwise ignore it and carry on
> c) Log an error and fail the deployment
> d) Something else
>
> I'm currently leaning towards option c.
>
> Thoughts?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: Native Image - Reflectionless Concept

2020-07-20 Thread Romain Manni-Bucau
I think a xml-less tomcat is awaited since servlet 3 - graal or not - but
agree risk is a bit higher.
That said path is different so wonder if skipping a temp solution can not
be worth after all for the community.

Le lun. 20 juil. 2020 à 17:58, Filip Hanik  a écrit :

>
> On 7/20/20 8:47 AM, Romain Manni-Bucau wrote:
>
>
>
> Le lun. 20 juil. 2020 à 17:41, Filip Hanik  a écrit :
>
>> Thanks for chiming in:
>> On 7/16/20 6:46 AM, Romain Manni-Bucau wrote:
>>
>> Hi everyone,
>>
>> I think the generation is the sanest option since code stay clean but it
>> shouldn't be done in tomcat IMHO but in user code and with a nice wrapper
>> (mvn tomcat:dump/gradle tomcatDump etc, or whatever name you like ;)).
>>
>> That's always an option, but it would become an external artifact and
>> easily end up out of sync.
>>
>
> Was thinking to keep the dumper in tomcat code base and the plugin to
> consume it so it would stay in sync, but agree it is a small risk.
>
>
>> This build phase would dump the descriptors in plain java and would load
>> them with an unique - ie single for the whole webapp - plain SPI -
>> ServiceLoader - maybe?
>>
>> The goal of this artifact was to reduce the size and classes from a full
>> tomcat (already available in tomcat-embed-core), down to a code base where
>> XML/digester/descriptors aren't used, hence tomcat-embed-programmatic
>>
>> This kind of build tool assumes you have all the runtime state in the
>> build - which is typically the case for graalvm - so you can completely
>> dump StandardContext state after start phase there and just reload it from
>> the precomputed model.
>> Only trick is about file paths which must either be recomputed or be
>> configurable to another base but it does not sound crazy.
>>
>> The less tool-ed option would be to extract all "reflectionfull" code in
>> methods and use graalvm substitutions to drop them and use plain java
>> instead (with a good naming convention, it can be generated as well).
>> Keeps the duplication but at least the main code stays clean and
>> optimizations stays together.
>>
>> That's pretty much what we're doing right now. Many of these feel like
>> hacks simply to mitigate how GraalVM/AOT does code initialization (all code
>> loaded initialized at startup)
>>
>
> Reviewing the hacks, all can be done cleanly if extracted in methods.
> Pushing the logic next step - I don't know if worth it but trying to use
> this picture to explain:
>
> 1. A noxml module can be done with protected methods/extension-points for
> XML loading - even usable in java standalone mode
> 2. Current tomcat can extend noxml module
> 3. Graal can be based on 1
>
> This would benefit both jvm and graal users at the end.
> Today 1 is possible with some hacks on tomcat embedded but it is highly
> not natural so this can be an opportunity to make it a feature maybe?
>
> I believe that tomcat-embed-programmatic is a viable interim solution,
> it's a low risk. The question for you, and the rest of the community, is
> the reward itself enough? ie, is it worth it?
>
> There is some talk about making "native-ness" part of the Java itself, and
> that could change a lot of assumptions. Making it a feature, refactoring
> code to satisfy 1, is a bit more intrusive at this point in time. I believe
> it introduces more risk than reward.
>
>
> Filip
>
>
>
>
>> Filip
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat  a écrit :
>>
>>> On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik  wrote:
>>>
>>>> for discussion, all feedback and questions welcome:
>>>>
>>>>
>>>> I've created a concept of having Apache Tomcat, embedded, run without
>>>> reflection in a native image.
>>>> This concept creates a jar, tomcat-embedded-programmatic.jar, that can
>>>> be fine tuned to only include what is needed in a default configuration
>>>> when an embedded tomcat instance is used and configured programatically.
>>>>
>>>> Steps to run Apache Tomcat using Java 8 without reflection
>>>&

Re: Native Image - Reflectionless Concept

2020-07-20 Thread Romain Manni-Bucau
Le lun. 20 juil. 2020 à 17:41, Filip Hanik  a écrit :

> Thanks for chiming in:
> On 7/16/20 6:46 AM, Romain Manni-Bucau wrote:
>
> Hi everyone,
>
> I think the generation is the sanest option since code stay clean but it
> shouldn't be done in tomcat IMHO but in user code and with a nice wrapper
> (mvn tomcat:dump/gradle tomcatDump etc, or whatever name you like ;)).
>
> That's always an option, but it would become an external artifact and
> easily end up out of sync.
>

Was thinking to keep the dumper in tomcat code base and the plugin to
consume it so it would stay in sync, but agree it is a small risk.


> This build phase would dump the descriptors in plain java and would load
> them with an unique - ie single for the whole webapp - plain SPI -
> ServiceLoader - maybe?
>
> The goal of this artifact was to reduce the size and classes from a full
> tomcat (already available in tomcat-embed-core), down to a code base where
> XML/digester/descriptors aren't used, hence tomcat-embed-programmatic
>
> This kind of build tool assumes you have all the runtime state in the
> build - which is typically the case for graalvm - so you can completely
> dump StandardContext state after start phase there and just reload it from
> the precomputed model.
> Only trick is about file paths which must either be recomputed or be
> configurable to another base but it does not sound crazy.
>
> The less tool-ed option would be to extract all "reflectionfull" code in
> methods and use graalvm substitutions to drop them and use plain java
> instead (with a good naming convention, it can be generated as well).
> Keeps the duplication but at least the main code stays clean and
> optimizations stays together.
>
> That's pretty much what we're doing right now. Many of these feel like
> hacks simply to mitigate how GraalVM/AOT does code initialization (all code
> loaded initialized at startup)
>

Reviewing the hacks, all can be done cleanly if extracted in methods.
Pushing the logic next step - I don't know if worth it but trying to use
this picture to explain:

1. A noxml module can be done with protected methods/extension-points for
XML loading - even usable in java standalone mode
2. Current tomcat can extend noxml module
3. Graal can be based on 1

This would benefit both jvm and graal users at the end.
Today 1 is possible with some hacks on tomcat embedded but it is highly not
natural so this can be an opportunity to make it a feature maybe?


> Filip
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat  a écrit :
>
>> On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik  wrote:
>>
>>> for discussion, all feedback and questions welcome:
>>>
>>>
>>> I've created a concept of having Apache Tomcat, embedded, run without
>>> reflection in a native image.
>>> This concept creates a jar, tomcat-embedded-programmatic.jar, that can
>>> be fine tuned to only include what is needed in a default configuration
>>> when an embedded tomcat instance is used and configured programatically.
>>>
>>> Steps to run Apache Tomcat using Java 8 without reflection
>>>
>>>1. Make sure you have native-image (from the graal installation) on
>>>your path
>>>2. git clone -b feature/embed-minimal-programmatic-jar-file-master
>>>g...@github.com:fhanik/tomcat.git
>>>3. cd tomcat/res/graal/
>>>4. ./build-tomcat-native-image.sh && ./graal-measure.sh
>>>
>>> Should yield an output similar to (Graal 20.1):
>>> SUCCESS: the servlet is working
>>> RSS memory: 20.7M
>>> Image size: 20.5M
>>>
>>>
>>> or using an older graal, 19.2
>>> SUCCESS: the servlet is working
>>> RSS memory: 18.0M
>>> Image size: 16.7M
>>>
>>>
>>> This also leaves a file named ${java.io.tmpdir}/
>>> XReflectionIntrospectionUtils.java so that you can review the solution
>>> to IntrospectionUtils.java
>>>
>>> Goals of this concept
>>>
>>>1. Do not break anything
>>>2. Create a new and optimized for size artifact,
>>>tomcat-embedded-programmatic
>>>3. Remove reflection by introspecting classes that are currently
>>>passed into Intro

Re: Native Image - Reflectionless Concept

2020-07-16 Thread Romain Manni-Bucau
Hi everyone,

I think the generation is the sanest option since code stay clean but it
shouldn't be done in tomcat IMHO but in user code and with a nice wrapper
(mvn tomcat:dump/gradle tomcatDump etc, or whatever name you like ;)).
This build phase would dump the descriptors in plain java and would load
them with an unique - ie single for the whole webapp - plain SPI -
ServiceLoader - maybe?
This kind of build tool assumes you have all the runtime state in the build
- which is typically the case for graalvm - so you can completely dump
StandardContext state after start phase there and just reload it from the
precomputed model.
Only trick is about file paths which must either be recomputed or be
configurable to another base but it does not sound crazy.

The less tool-ed option would be to extract all "reflectionfull" code in
methods and use graalvm substitutions to drop them and use plain java
instead (with a good naming convention, it can be generated as well).
Keeps the duplication but at least the main code stays clean and
optimizations stays together.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat  a écrit :

> On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik  wrote:
>
>> for discussion, all feedback and questions welcome:
>>
>>
>> I've created a concept of having Apache Tomcat, embedded, run without
>> reflection in a native image.
>> This concept creates a jar, tomcat-embedded-programmatic.jar, that can be
>> fine tuned to only include what is needed in a default configuration when
>> an embedded tomcat instance is used and configured programatically.
>>
>> Steps to run Apache Tomcat using Java 8 without reflection
>>
>>1. Make sure you have native-image (from the graal installation) on
>>your path
>>2. git clone -b feature/embed-minimal-programmatic-jar-file-master
>>g...@github.com:fhanik/tomcat.git
>>3. cd tomcat/res/graal/
>>4. ./build-tomcat-native-image.sh && ./graal-measure.sh
>>
>> Should yield an output similar to (Graal 20.1):
>> SUCCESS: the servlet is working
>> RSS memory: 20.7M
>> Image size: 20.5M
>>
>>
>> or using an older graal, 19.2
>> SUCCESS: the servlet is working
>> RSS memory: 18.0M
>> Image size: 16.7M
>>
>>
>> This also leaves a file named ${java.io.tmpdir}/
>> XReflectionIntrospectionUtils.java so that you can review the solution
>> to IntrospectionUtils.java
>>
>> Goals of this concept
>>
>>1. Do not break anything
>>2. Create a new and optimized for size artifact,
>>tomcat-embedded-programmatic
>>3. Remove reflection by introspecting classes that are currently
>>passed into IntrospectionUtils.set/getProperty by generating
>>setters/getters at build time
>>
>> How it's done
>>
>>1. I've build out a small introspection tool in the package
>>org.apache.tomcat.util.xreflect
>>2. During build time, it analyses a set of known classes that are
>>used with IntrospectionUtils.java, and generates
>>XReflectionIntrospectionUtils.java
>>3. When it packages tomcat-embed-programmatic.jar it uses the
>>generated code when calling setProperty and getProperty
>>
>> A PR would look like this:
>>
>> https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1
>>
>>
> Well, this is a bit complex and hard to maintain (like, for example,
> storeconfig), so that's a downside.
>
> So starting with Tomcat and its initial server.xml, the process would be:
> server.xml -> equivalent Tomcat embedded code -> equivalent Tomcat
> embedded code with custom IntrospectionUtils code
> The concrete benefits may be limited though.
>
> I looked at more code generation for web.xml since the digester is nice
> for that, but the benefit becomes even more questionable. It is harder to
> manage, and the generated classes have to be loaded dynamically [unless
> even more code is generated]. If there are tons of fragments, there is a
> good intuitive reason why it becomes useless. so I didn't want to do it. I
> prefer if things remain a bit EE-ish, ultimately.
>
> Rémy
>
>


Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

2020-07-14 Thread Romain Manni-Bucau
Le mar. 14 juil. 2020 à 15:50, Merlin Beedell  a
écrit :

> Thank you for the responses.
> I can confirm that changing the certificate by replacing the file(s) with
> the ones with the same name & password but with an updated certificate
> inside does indeed work.  The reason I thought otherwise because (I thought
> that) the useful Presentation by C Schultz said it re-read the config -
> allowing changes to the cipher list and TLS types to be altered at the same
> time.
> I had tested by swapping between 2 pfx certificates that I thought were
> different - stupid rookie mistake, the certificates were indeed the same.
> I created a new self-signed one and that worked straight away.
>
> I presume that I can the 'set' commands in the manager webapp to alter the
> allowed TLS levels?
>
> Final Question: If the "Bean Name" can be different depending on various
> configurations - how should I query to get the correct name if trying to
> create a 'generic' process to do this?
>


Assuming you have a single server in the JVM you can use a mbean query and
replace the name by "*" I think.


>
> Merlin Beedell
> 0800 280 0525 / +44 (0)207 045 0520
> DDI: +44 (0)207 045 0528
> Mob: +44 (0)7876 226865
> Cryoserver: A focused, flexible email archive delivered by experts
>
> -Original Message-
> From: Christopher Schultz 
> Sent: 13 July 2020 11:44 PM
> To: dev@tomcat.apache.org
> Subject: Re: Support for LetsEncrypt certs, and update process, in Tomcat
> without restart.
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Merlin,
>
> On 7/13/20 06:09, Merlin Beedell wrote:
> > Hi all,
> >
> > Thank you for your valuable assistance and suggestions so far.
> >
> >
> >
> > I did eventually try this (again, using ‘groovy’ as a simple-to-use
> > scriptable wrapper to Java), which looks like it
> > works:
> >
> >
> >
> > @Grab(group='com.github.groovy-wslite', module='groovy-wslite',
> > version='1.1.3')
> >
> >
> >
> > import wslite.rest.*
> >
> > import wslite.http.auth.*
> >
> >
> >
> > RESTClient client = new
> > RESTClient("http://localhost:8080/manager;) //or
> > https://localhost/manager
> >
> > client.authorization = new
> > HTTPBasicAuthorization("tomcat-users-name",
> > "and-corresponding-password")
> >
> >
> >
> > def path =
> >
> "/jmxproxy/?invoke=Catalina:type=ProtocolHandler,port=443=reloadSslHo
> stConfigs"
> >
> > def response
> >
> > response = client.get(path: path)
> >
> > println response.text
> >
> >
> >
> > And it returns (for example): “*OK - Operation reloadSslHostConfigs
> > without return value*”
> >
> > If the certificate file now no longer exists or is corrupted – we get
> > an error response. Thus we know this action provokes the certificate
> > file to be re-read.
> >
> > /However/
> >
> > If the connector section in server.xml is edited to point to a new
> > certificate path/filename, it is ignored.  The current certificate
> > config continues to be used.
> >
> > If the certificate file is replaced by a new certificate, the end-user
> > does not see any change – a fresh browser will still see the old
> > certificate.
> >
> >
> >
> > So: Is there some /other/ action that I need to invoke after the
> > reloadSslHostConfigs?  Or to invoke it under a different “mbean name”?
> >
> > When I change the bean name to include *address=127.0.0.1* as per your
> > curl example
> > (Catalina:type=ProtocolHandler,port=443,address=127.0.0.1) it errors.
> >
> > For example – under the Catalina:type=Connector,port=443 – I see
> > operations “destroy / pause / resume / stop / start / init”.
> >
> > And under the ProtocolHandler I see “findSslHostConfigs / start /
> > destroy / pause / resume / getProperty / closeServerSocketGraceful /
> > findupgradeProtocols / init”
> >
> > Would these help?
> >
> >
> >
> > The connector config (simple self-signed cert in this case – not yet
> > changed to a letsencrypt one) looks similar to this:
> >
> >  > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> >
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementatio
> n">
> >
> >  > className="org.apache.coyote.http2.Http2Protocol">
> >
> >
> >
>  > ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
> > honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
> >
> >  > certificateKeystoreFile="C:\opt\certificates\keystore"
> > certificateKeystorePassword="passphrase"
> > certificateKeystoreType="JKS">
> >
> > 
> >
> > 
> >
> >
> >
> > And I am trying to reset it to a PKCS12 keystore:
> >
> >  > certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
> > certificateKeystorePassword="newpass"
> > certificateKeystoreType="PKCS12">
> >
> >
> >
> > I’m at a loss to know what to do – other than to abandon SSL
> > termination in tomcat and use a proxy to do it instead – that I really
> > wish I could avoid.
> >
> >
> >
> > Some of my findings from trying to refresh the Tomcat SSL config at
> > runtime and trying to decipher the documentation and
> > suggestions:
> >
> > 1. The remote JMX 

Re: [ANN] New committer: Raymond Augé

2020-07-02 Thread Romain Manni-Bucau
Congrats Ray, well deserved!

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 2 juil. 2020 à 17:39, Coty Sutherland  a
écrit :

> Congrats and welcome!
>
> On Thu, Jul 2, 2020 at 10:40 AM Mark Thomas  wrote:
>
>> On behalf of the Tomcat committers I am pleased to announce that
>> Raymond Augé (rotty3000) has been voted in as a new Tomcat committer.
>>
>> Please join me in welcoming him.
>>
>> Kind regards,
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>


Re: Changing the name of the default branch in our git repos

2020-06-16 Thread Romain Manni-Bucau
Hi,

Do you know if there would be a redirect of existing PR and "existing"
references to master or does it break the ecosystem for a while - if so I'm
not sure it is worth it ?
If it does not break anything "latest" does not sound that bad and likely
avoids this superior/inferior thought people can have as with master or
main and it sounds more modern than trunk ;).

Indeed, just my 2 cents ;).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 16 juin 2020 à 17:36, Martin Grigorov  a
écrit :

> Hi,
>
> On Tue, Jun 16, 2020 at 11:02 AM Mark Thomas  wrote:
>
>> All,
>>
>> You may have seen the recent discussions both inside and outside the ASF
>> about the user of "master" as the name of the default git branch. If you
>> haven't, the short version is that the name can be traced back to
>> master/slave and its associations with human slavery.
>>
>> I'd like to propose that the Apache Tomcat project renames the master
>> branch in all of the project repositories.
>>
>> I think there are two front runners for the new name:
>>
>> - main - this looks to be the name GitHub and a number of OSS projects
>>  will be switching to
>>
>> - trunk - reflects the Subversion heritage of both the project and the
>>   ASF
>>
>> Other options I have seen suggested include "default", "dev", "develop".
>> Other suggestions welcome.
>>
>> Personally, I am leaning towards main as that looks to be the choice of
>> the majority and using the majority choice will make it (a little bit)
>> easier for new community members to find their way around the project.
>>
>> In terms of impact, changing the name is going to break stuff. It is
>> really creating a new branch and deleting the old one.
>>
>> Deleting a branch triggers the automatic closure of github PRs against
>> that branch. However if we create "$new_branch" we can edit the PRs to
>> use "$new_branch" before we delete master. Given the small number of
>> open PRs that is easily done.
>>
>> CI systems will need to be updated (buildbot, gump). That should be
>> relatively simple.
>>
>> Docs will need to be updated (relatively simple).
>>
>> Committers and contributors will rebase any local branches to $new_branch
>>
>> Having thought about what is involved, renaming the default branch
>> doesn't look as problematic as I thought it might be. This looks like
>> something that could be done in around an hour for all our repos.
>>
>> Thoughts?
>>
>
> I, personally, do not see any relation between technical nomenclature and
> social problems in real life.
> I have many colored skin friends and colleagues and I've never heard
> anyone making such associations.
> I am Bulgarian. Until not so long ago we were ruled for 5 centuries by
> Ottomans but I do not feel like a slave and I don't find 'master' branch
> name anyhow related to slavery.
> I am -0 on such change and any other change that comes from politics.
>
> But if we are going to change the branch name then I suggest '10.0.x'.
> This way it will be consistent with all other branches.
>
> Martin
>
>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>


Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

2020-06-11 Thread Romain Manni-Bucau
This one was more intended to System.exit but it got aligned with mw impl
so it is quite close.

Le jeu. 11 juin 2020 à 19:40, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Romain,
>
> On 6/11/20 13:34, Romain Manni-Bucau wrote:
> > @Chris:
> https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/
> java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java
> <https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java>
> ?
>
> Thanks!
>
> Stupid GitHub. I searched all your repositories for "encrypt" and it
> didn't find "letsencrypt". I guess "search" means "prefix match".
> *facepalm*
>
> > it is more or less what we have in meecrowave except meecrowave
> > can hotreload whereas this (pre reloadSslHostConfig method) impl
> > does not.
>
> Your LetsEncryptManager seems to call reloadSslHostConfigs. What does
> Meecrowave do differently?
>
> - -chris
>
> > Le jeu. 11 juin 2020 à 19:20, Christopher Schultz
> >  > <mailto:ch...@christopherschultz.net>> a écrit :
> >
> > Merlin,
> >
> > On 6/10/20 12:32, Merlin Beedell wrote:
> >> Well thanks Christopher - that presentation link was just what I
> >> needed (well - it was your presentation after all!). Really
> >> good. Ideally this could be written into the Tomcat standard
> >> Documentation, as it will crop up quite a bit.
> >
> >> In summary, 3 steps:
> >
> >> 1. Fetch cert update (requires port 80).
> >
> >> – certbot-auto renew
> >
> >> 2. Reformat for Tomcat usage [might be natively handled in later
> >> Tomcat releases?]
> >
> >> – openssl pkcs12 -export -in [cert] -inkey [key] -certfile
> >> [chain] -out [p12file]
> >
> >> 3. Use JMX to flush/reload the SSH Host config (including cipher
> >> list & protocol level) at runtime.
> >
> >> https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandl
> e
> >
> >>
> r,port=8443,address=
> > <https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandl
> er,port=8443,address=
> <https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443,address=>
> >"127.0.0.1"=reloadSslHostConfigs
> >
> >  While
> >
> > "[documentation] patches are always welcome", I don't think I'd
> > want to put this into the Tomcat user's manual. If we add
> > information about Let's Encrypt, why not DigiCert? VeriSign?
> > GoDaddy? WhoeeverElseCA ?
> >
> > I could see this being something useful in the Tomcat Wiki.
> >
> > At least one person who has seen my presentation has said "we, I
> > was hoping there was just a letsencrypt='true' configuration flag".
> > I like the outside-in approach certbot takes with their Apache
> > plugins, rather than an inside-out approach where the server
> > actually has a plug-in for let's encrypt (or similar).
> >
> > Romain @ TomEE has written a WAR file that implements this
> > inside-out approach as a generic ACME servlet (context listener?),
> > but I can't seem to find his code anywhere...
> >
> > -chris
> >
> >> -Original Message-
> >
> >> From: Christopher Schultz  > <mailto:ch...@christopherschultz.net>>
> >
> >> Sent: 08 June 2020 9:14 PM
> >
> >> To: Tomcat Developers List  > <mailto:dev@tomcat.apache.org>>; Merlin Beedell
> >> mailto:mbeed...@cryoserver.com>>
> >
> >> Subject: Re: Support for LetsEncrypt certs, and update process,
> >> in Tomcat without restart.
> >
> >
> >
> >> Hash: SHA256
> >
> >
> >
> >> Merlin,
> >
> >
> >
> >> On 6/8/20 10:17, Merlin Beedell wrote:
> >
> >>> I am getting a lot of flack from some senior devs who insist
> >>> that
> >
> >>> Tomcat must be put behind a Proxy – HA Proxy or Nginx, which
> >>> will
> >
> >>> handle the SSL offloading etc.
> >
> >
> >
> >>> While this seems sensible for multi-server environments, they
> >>> want it
> >
> >>> for single server too.  But Tomcat can do all the things that
> >>> are
> >
> >>> required:
> >
> >
> >
> >>> * Certificate handling. * 

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

2020-06-11 Thread Romain Manni-Bucau
@Chris:
https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java
?
it is more or less what we have in meecrowave except meecrowave can
hotreload whereas this (pre reloadSslHostConfig method) impl does not.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 11 juin 2020 à 19:20, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Merlin,
>
> On 6/10/20 12:32, Merlin Beedell wrote:
> > Well thanks Christopher - that presentation link was just what I
> > needed (well - it was your presentation after all!). Really good.
> > Ideally this could be written into the Tomcat standard
> > Documentation, as it will crop up quite a bit.
> >
> > In summary, 3 steps:
> >
> > 1. Fetch cert update (requires port 80).
> >
> > – certbot-auto renew
> >
> > 2. Reformat for Tomcat usage [might be natively handled in later
> > Tomcat releases?]
> >
> > – openssl pkcs12 -export -in [cert] -inkey [key] -certfile [chain]
> >  -out [p12file]
> >
> > 3. Use JMX to flush/reload the SSH Host config (including cipher
> > list & protocol level) at runtime.
> >
> > https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandle
> r,port=8443,address=
> <https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443,address=>
> "127.0.0.1"=reloadSslHostConfigs
>
> While
> >
> "[documentation] patches are always welcome", I don't think I'd
> want to put this into the Tomcat user's manual. If we add information
> about Let's Encrypt, why not DigiCert? VeriSign? GoDaddy? WhoeeverElseCA
> ?
>
> I could see this being something useful in the Tomcat Wiki.
>
> At least one person who has seen my presentation has said "we, I was
> hoping there was just a letsencrypt='true' configuration flag". I like
> the outside-in approach certbot takes with their Apache plugins,
> rather than an inside-out approach where the server actually has a
> plug-in for let's encrypt (or similar).
>
> Romain @ TomEE has written a WAR file that implements this inside-out
> approach as a generic ACME servlet (context listener?), but I can't
> seem to find his code anywhere...
>
> - -chris
>
> > -Original Message-
> >
> > From: Christopher Schultz 
> >
> > Sent: 08 June 2020 9:14 PM
> >
> > To: Tomcat Developers List ; Merlin Beedell
> >  
> >
> > Subject: Re: Support for LetsEncrypt certs, and update process, in
> >  Tomcat without restart.
> >
> >
> >
> > Hash: SHA256
> >
> >
> >
> > Merlin,
> >
> >
> >
> > On 6/8/20 10:17, Merlin Beedell wrote:
> >
> >> I am getting a lot of flack from some senior devs who insist
> >> that
> >
> >> Tomcat must be put behind a Proxy – HA Proxy or Nginx, which
> >> will
> >
> >> handle the SSL offloading etc.
> >
> >
> >
> >> While this seems sensible for multi-server environments, they
> >> want it
> >
> >> for single server too.  But Tomcat can do all the things that
> >> are
> >
> >> required:
> >
> >
> >
> >> * Certificate handling. * TLS level and Cipher restrictions *
> >> CORS
> >
> >> handling (though this could be simpler!)
> >
> >
> >
> >> But now with the requirement for LetsEncrypt certificates, we
> >> find
> >
> >> that Tomcat has to be restarted every 3 months.  Indeed – any
> >> changes
> >
> >> to the above require tomcat restarts – and that is found to be
> >
> >> unacceptable.
> >
> >
> >
> > Nonsense.
> >
> >
> >
> > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> >
> >
> >
> > Updating CORS configuration may require a redeployment of your web
> >  application, but it does not require Tomcat to be shut-down.
> >
> >
> >
> > There are other reasons to use a reverse proxy in front of Tomcat,
> >  but none of the above are good reasons.
> >
> >
> >
> >> So what I really want to underst

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

2020-06-08 Thread Romain Manni-Bucau
Hi Merlin,

you can reload the certificates already (think it is in JMX but you can
also do it programmatically through a listener or valve - which is
convenient to handle the let's encrypt public part), you can have a look to
https://github.com/apache/openwebbeans-meecrowave/blob/master/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptReloadLifecycle.java#L155
for
an impl.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 8 juin 2020 à 16:17, Merlin Beedell  a
écrit :

> I am getting a lot of flack from some senior devs who insist that Tomcat
> must be put behind a Proxy – HA Proxy or Nginx, which will handle the SSL
> offloading etc.
>
> While this seems sensible for multi-server environments, they want it for
> single server too.  But Tomcat can do all the things that are required:
>
>- Certificate handling.
>- TLS level and Cipher restrictions
>- CORS handling (though this could be simpler!)
>
> But now with the requirement for LetsEncrypt certificates, we find that
> Tomcat has to be restarted every 3 months.  Indeed – any changes to the
> above require tomcat restarts – and that is found to be unacceptable.
>
>
>
> So what I really want to understand is if Tomcat has any plans to include
> the ability to restart an https connector WITHOUT needing to restart the
> whole of Tomcat.  Better still, a hook that would help refresh certificates
> – like LetsEncrypt.
>
>
> https://stackoverflow.com/questions/43571572/programmatically-update-certificates-in-tomcat-8-without-server-restart
>
>
>
> Merlin Beedell
>
>
>


Re: API Change - Connector.java Constructor

2020-04-16 Thread Romain Manni-Bucau
Doesn't the same applies? It is a finite product (and not too big). The
only choice to do is how to expose it I guess.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 16 avr. 2020 à 14:34, Rémy Maucherat  a écrit :

> On Thu, Apr 16, 2020 at 1:42 PM Romain Manni-Bucau 
> wrote:
>
>> Hi all,
>>
>> Just wanted to shout a proposal - hoping to not be too much "off".
>>
>> I guess the target of bypassing reflection is mainly for what tomcat
>> delivers - ie not the user/vendor extensions - so it means everything is
>> there at build time, so why not generating the reflection-free API?
>> Idea would be the following one: for each class "missing" setters (to
>> bypass reflection), generate a $Accessors class extending the
>> root one but with the accessors (the nested class enables to have access to
>> private fields).
>> Small trick: some $Accessors class must have multiple flavors, I'm
>> thinking to transitive reflection (protocol handler) but since all the
>> settable model is known at build time it is very doable.
>> Simplest sounds using a first compilation pass, generation then compile
>> new classes but using an annotation processor sounds doable as well.
>>
>> At the end, this means that then you can be fully reflection free using
>> the generated classes instead of the standard one.
>>
>> Hope it makes sense and it is not too late.
>>
>
> The get/set are methods that could/would be removed of course, but I
> haven't even done it at all right now. The problem is the object creation
> and how and when they get tied together.
>
> Rémy
>
>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le mer. 15 avr. 2020 à 18:26, Rémy Maucherat  a écrit :
>>
>>> On Fri, Apr 10, 2020 at 6:32 PM Filip Hanik  wrote:
>>>
>>>>
>>>>
>>>> On Fri, Apr 10, 2020 at 1:28 AM Rémy Maucherat  wrote:
>>>>
>>>>>
>>>>>
>>>>>> This configuration gives the impression that the Endpoint is a child
>>>>>> of the Connector.
>>>>>> But the Connector truly only needs the ProtocolHandler interface to
>>>>>> function. The injected object would then be better to an instance of a
>>>>>> ProtocolHandler
>>>>>>
>>>>>> The XML can of course be configured to instantiate and inject the
>>>>>> ProtocolHandler handler directly into the Connector
>>>>>> In this setting, it doesn't make sense to have any properties on the
>>>>>> Connector, since the Connector receives the protocol handler already
>>>>>> configured.
>>>>>>
>>>>>> 
>>>>>> >>>>> maxHeaderCount="10" >
>>>>>>   >>>>> port="8443" SSLEnabled="true"
>>>>>>
>>>>>>  
>>>>>> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation">
>>>>>>   >>>>> directSslBuffer="true" />
>>>>>>   
>>>>>> >>>>> certificateKeyFile="${catalina.home}/conf/key.pem"
>>>>>>
>>>>>>  certificateFile="${catalina.home}/conf/cert.pem"
>>>>>>  type="RSA" />
>>>>>>   
>>>>>>   
>>>>>>   >>>>> className="org.apache.coyote.http2.Http2Protocol" />
>>>>>>>>>>> 
>>>>>>
>>>>>
>>>>> Either way, I experimented a bit and it's not doable. Too many
>>>>> intrusive changes and impossibility to be compatible.
>>>>>
>>>>
>>>> Sounds good.
>>>>
>>>
>>> I started working on it more to make a real attempt and see how it
>>> behaves in practice. Even though the changes are problematic [the biggest
>>> Catalina/Tomcat API break ever, surpassing the TLS configuration changes
>>> earlier], the Connector is still the biggest problem for duplicated
>>> properties and random hacks, including reflection abuse. That's a goal/todo
>>> for 10 so it is worth doing it to put it on review to know if it exceeds
>>> the pain threshold of most.
>>>
>>> Rémy
>>>
>>>
>>>>
>>>> Filip
>>>>
>>>


Re: API Change - Connector.java Constructor

2020-04-16 Thread Romain Manni-Bucau
Hi all,

Just wanted to shout a proposal - hoping to not be too much "off".

I guess the target of bypassing reflection is mainly for what tomcat
delivers - ie not the user/vendor extensions - so it means everything is
there at build time, so why not generating the reflection-free API?
Idea would be the following one: for each class "missing" setters (to
bypass reflection), generate a $Accessors class extending the
root one but with the accessors (the nested class enables to have access to
private fields).
Small trick: some $Accessors class must have multiple flavors, I'm thinking
to transitive reflection (protocol handler) but since all the settable
model is known at build time it is very doable.
Simplest sounds using a first compilation pass, generation then compile new
classes but using an annotation processor sounds doable as well.

At the end, this means that then you can be fully reflection free using the
generated classes instead of the standard one.

Hope it makes sense and it is not too late.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 15 avr. 2020 à 18:26, Rémy Maucherat  a écrit :

> On Fri, Apr 10, 2020 at 6:32 PM Filip Hanik  wrote:
>
>>
>>
>> On Fri, Apr 10, 2020 at 1:28 AM Rémy Maucherat  wrote:
>>
>>>
>>>
>>>> This configuration gives the impression that the Endpoint is a child of
>>>> the Connector.
>>>> But the Connector truly only needs the ProtocolHandler interface to
>>>> function. The injected object would then be better to an instance of a
>>>> ProtocolHandler
>>>>
>>>> The XML can of course be configured to instantiate and inject the
>>>> ProtocolHandler handler directly into the Connector
>>>> In this setting, it doesn't make sense to have any properties on the
>>>> Connector, since the Connector receives the protocol handler already
>>>> configured.
>>>>
>>>> 
>>>> >>> maxHeaderCount="10" >
>>>>   >>> port="8443" SSLEnabled="true"
>>>>
>>>>  
>>>> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation">
>>>>   >>> />
>>>>   
>>>> >>> certificateKeyFile="${catalina.home}/conf/key.pem"
>>>>
>>>>  certificateFile="${catalina.home}/conf/cert.pem"
>>>>  type="RSA" />
>>>>   
>>>>   
>>>>   >>> className="org.apache.coyote.http2.Http2Protocol" />
>>>>>>> 
>>>>
>>>
>>> Either way, I experimented a bit and it's not doable. Too many intrusive
>>> changes and impossibility to be compatible.
>>>
>>
>> Sounds good.
>>
>
> I started working on it more to make a real attempt and see how it behaves
> in practice. Even though the changes are problematic [the biggest
> Catalina/Tomcat API break ever, surpassing the TLS configuration changes
> earlier], the Connector is still the biggest problem for duplicated
> properties and random hacks, including reflection abuse. That's a goal/todo
> for 10 so it is worth doing it to put it on review to know if it exceeds
> the pain threshold of most.
>
> Rémy
>
>
>>
>> Filip
>>
>


Re: [tomcat-jakartaee-migration] branch master updated: Add javax.(decorator|enterprise|inject) as ones which should be migrated

2020-03-13 Thread Romain Manni-Bucau
Hi everyone,

Shouldnt tomcat tool stay aligned on tomcat stack?

Maven shade or gradle fatjar plugins solve this issue with relocation for
all users and all namespaces so not a big deal to not handle more than
tomcat IMO, otherwise all hybrid cases (between ~servlet and ee) will be
broken IMHO.

Le ven. 13 mars 2020 à 11:00, Martin Grigorov  a
écrit :

> Hi Rémy,
>
> On Thu, Mar 12, 2020 at 6:58 PM Rémy Maucherat  wrote:
>
>> On Thu, Mar 12, 2020 at 3:10 PM  wrote:
>>
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> mgrigorov pushed a commit to branch master
>>> in repository
>>> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
>>>
>>>
>>> The following commit(s) were added to refs/heads/master by this push:
>>>  new 8dd0dde  Add javax.(decorator|enterprise|inject) as ones which
>>> should be migrated
>>> 8dd0dde is described below
>>>
>>> commit 8dd0dde9e030e8168141184b3e51de1d674aee0b
>>> Author: Martin Tzvetanov Grigorov 
>>> AuthorDate: Thu Mar 12 16:09:04 2020 +0200
>>>
>>> Add javax.(decorator|enterprise|inject) as ones which should be
>>> migrated
>>>
>>> Those are needed for CDI applications
>>>
>>
>> Well, it's needed if there is a jakarta implementation of CDI [do you
>> have one ? ...]. Right now that's not the case and it will mess things up
>> since it's possible to use Tomcat 10 with a javax CDI and a converted
>> webapp.
>> See the modules/owb wrapper for example.
>>
>
>> So it's a bit messy and this would need to be configurable for now.
>>
>
> Here is how I understand it:
> 1) if you deploy in EE server, like Wildfly and Glassfish, then both
> cdi-api.jar and the CDI impl (like weld-servlet.jar) are provided by the EE
> server and they are not part of the application, so nothing will be migrated
> 2) if you deploy in web container, like Tomcat & Jetty, then cdi-api.jar
> and weld-servlet.jar should be in the application's WEB-INF/lib/, so both
> are migrated and everything works
>
> In both cases one is supposed to deploy in Jakarta EE 9 container, i.e.
> jakarta packages are prefered than javax ones.
>
> Do you see a use case that is not supported at the moment ?
>
> Martin
>
>
>>
>> Rémy
>>
>>
>>> ---
>>>  src/main/java/org/apache/tomcat/jakartaee/Util.java | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> index 21e0fbf..701134d 100644
>>> --- a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> +++ b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> @@ -23,7 +23,8 @@ import java.util.regex.Pattern;
>>>  public class Util {
>>>
>>>  private static Pattern PATTERN = Pattern.compile(
>>> -
>>> "javax([/\\.](annotation|ejb|el|mail|persistence|security[/\\.]auth[/\\.]message|servlet|transaction|websocket))");
>>> +
>>> "javax([/\\.](annotation|decorator|ejb|el|enterprise|inject|mail|persistence|security[/\\.]auth[/\\"
>>> ++ ".]message|servlet|transaction|websocket))");
>>>
>>>  /**
>>>   * Get the extension of a filename
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>>


Re: Enabling http to https redirects for tomcat.apache.org

2020-02-25 Thread Romain Manni-Bucau
+1 with some light (1 month?) notice time in case anyone uses http directly
intentionally, will avoid some security breaches http can get, in
particular on subdomains.

Le mar. 25 févr. 2020 à 21:45, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 2/25/20 14:34, Mark Thomas wrote:
> > On 25/02/2020 15:53, Felix Schumacher wrote:
> >> Hi all,
> >>
> >> as more and more browsers are marking http as unsecure, we
> >> should redirect all http requests to tomcat.apache.org to https.
> >
> > I really don't like this.
> >
> > I'm happy to support https for those people that want to use it but
> > I see no need to require https for everybody for
> > tomcat.apache.org.
> >
> > We should not be dictating to our users what security / privacy /
> > caching / performance / etc. trade-offs are appropriate for them.
> > We should support as many options as possible and let our users
> > decided.
> >
> > I'm not quite -1 on this but I am close.
>
> https://www.troyhunt.com/heres-why-your-static-website-needs-https/
>
> - -chris
>
> >> We can enable that by adding a rewrite rule to the .htaccess file
> >> in the xdocs folder of our site repo.
> >>
> >> For JMeter we used the following fragment:
> >>
> >> RewriteEngine On
> >>
> >> # Redirect http to https # From Cordova PMC Member raphinesse #
> >> https://s.apache.org/An8s
> >>
> >> # If we receive a forwarded http request from a proxy...
> >> RewriteCond %{HTTP:X-Forwarded-Proto} =http [OR]
> >>
> >> # ...or just a plain old http request directly from the client
> >> RewriteCond %{HTTP:X-Forwarded-Proto} ="" RewriteCond %{HTTPS}
> >> !=on
> >>
> >> # Redirect to https version RewriteRule ^
> >> https://%{HTTP_HOST}%{REQUEST_URI} [L]
> >>
> >> Anything against adding this to our .htaccess file?
> >
> >
> >>
> >> Felix
> >>
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>
> >
> >
> > -
> >
> >
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5Vh3kACgkQHPApP6U8
> pFgktRAAh34aN6pyZaMz2n/Bha81mbNjglrMcxkrEswqMCJM0/8Wbw8hgB+3JArQ
> dfIYipA2KTtjEzRgGU74qGcvDnEpTcoWi+csvmU7nwExt2RClmMF/5KqvYi67QZZ
> l0klgHATRjNPrPOkvZy8Op0fFS6/bnXzvESS/lusz6aLrqiXRxqDVyDgCiBxzrXr
> m2VLdE/re1CyFzcNcNmHUAUNs37/0E2WB1d11OvblE3I9eRb1Vk+FHtsfkDmNEoX
> 0RE7sQlr12ElMQ3OYOHsErxrxgTD2J/+CXqbMra8sWQ4pgEZPMX/7k5bGyr3IpTh
> sOiSR9KNShfJtjKXp2ngJJKbEgDpr4SOYAh5FwGyUKmxflw+nqbc/Zd5bA6H4GNH
> 27p0Ec2ArCSDM4vlIeYbtBo8xqAuq2ArVywyUVrWog4mk0Hita2OHnp6Y8CFcZwR
> hVv2fuFzd9/zueHG1TvLpB86Mr40MS8j2OelAACixECkV8CAo+64hXLLELgl5XXd
> wu6J60tKXXgTlcQcoa0h9nm27D3YKLBUnH6CuOxjUGxVHwH6Bmc2OdR5l+FRNHkl
> 35MEkqCXThXc62/G/sBW4/Kd7bF/A0wYXT8dKYb6p/s4GXZ9yM3sgjQr9N/b0sP0
> RukK+6i6vgtsY7xf8eSVtUAgYNyV4ndxpQyYBiyRHVh06nfGgHQ=
> =qS1l
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

2020-02-06 Thread Romain Manni-Bucau
+1 (non binding)

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 6 févr. 2020 à 09:58, Martin Grigorov  a
écrit :

> Hi,
>
> I have a question about
> https://github.com/apache/tomcat-jakartaee-migration
> <https://github.com/apache/tomcat-jakartaee-migration/blob/master/src/main/scripts/migrate.sh>
>  tool:
> How is it supposed to be used ?
> It's README does not explain this.
>
> I've found
> https://github.com/apache/tomcat-jakartaee-migration/blob/master/src/main/scripts/migrate.sh
>  and
> from it I've figured:
>
> java -cp target/jakartaee-migration-0.0.2-SNAPSHOT-shaded.jar
> org.apache.tomcat.jakartaee.Migration
> ~/devel/apache-tomcat-10.0.0.0-M1/webapps/we.war we.war
>
> but it fails with NPE:
>
> Feb 06, 2020 10:56:35 AM org.apache.tomcat.jakartaee.Migration execute
> INFO: Performing migration from source
> [/home/martin/devel/apache-tomcat-10.0.0.0-M1/webapps/we.war] to
> destination [/home/martin/git/apache/tomcat-jakartaee-migration/we.war]
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.tomcat.jakartaee.Migration.execute(Migration.java:87)
> at org.apache.tomcat.jakartaee.Migration.main(Migration.java:198)
>
> Martin
>
>
> On Wed, Feb 5, 2020 at 9:22 PM Mark Thomas  wrote:
>
>> The proposed Apache Tomcat 10.0.0.0-M1 release is now available for
>> voting. This is the first release of 10.0.0.x and is based on 9.0.31.
>>
>> The major changes compared to 9.0.31  are:
>>
>> - Complete the javax to jakarta package rename
>>
>> - Remove duplication of configuration between HTTP/1.1 and HTTP/2.
>>   HTTP/2 will now inherit values from HTTP/1.1.
>>
>> - Remove deprecated code
>>
>> Along with lots of other bug fixes and improvements.
>>
>> For full details, see the changelog:
>> https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html
>>
>> It can be obtained from:
>> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0.0-M1/
>> The Maven staging repo is:
>> https://repository.apache.org/content/repositories/orgapachetomcat-1244/
>> The tag is:
>> https://github.com/apache/tomcat/tree/10.0.0.0-M1
>> 9797ba13e0e554c3b8e990f2dc4f846d2bdccf6d
>>
>> The proposed 10.0.0.0-M1 release is:
>> [ ] Broken - do not release
>> [ ] Alpha  - go ahead and release as 10.0.0.0-M1
>>
>> I opted to only include alpha here as there are still some potentially
>> significant changes on the TOMCAT-NEXT list.
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>


Re: javax -> jakarta rename

2019-12-25 Thread Romain Manni-Bucau
I see a lot of value to the runtime solution cause it is the only one
enabling an ops only migration so for all the softwares in "run only" phase
it is the only option. However the agent or transformer is the least
invasive solution cause it does not require to patch core libs and will
avoid app dependencies conflicts/issues (assuming asm is already there as
in tomee/meecrowave or shaded with relocation).

Just my 2 cts

Le mer. 25 déc. 2019 à 04:47, Adam Rauch  a écrit :

>
> On 12/21/2019 11:49 AM, Mark Thomas wrote:
> > On 21/12/2019 17:45, Adam Rauch wrote:
> >
> > 
> >
> >> Yes, I see that 9.x javax.* will be supported for a long time and I'm
> >> all in favor of killing off deprecated EE libraries. I want to encourage
> >> our users to migrate to Tomcat 10.x and future releases as quickly as
> >> possible, but I'm concerned that 9.x to 10.x will be a very difficult
> >> transition for those who deploy webapps like the one we develop. With
> >> the current plan, I don't see a scenario where our users can upgrade to
> >> the next release of Tomcat, test that change, and then upgrade our
> >> webapp. Because of the package rename, they will need to be upgraded in
> >> lockstep, which has never been the case before. I see the value of a
> >> short-term "transition" release that helps ease this burden by
> >> supporting webapps using either package, but if others don't, then never
> >> mind.
> > I think the ideal migration strategy is going to vary for different
> > users. Personally, I think an approach that largely mirrors what the
> > Jakarta projects are going (i.e. just the package rename, nothing else)
> > and doing that for the container and the app at the same time is the way
> > to go in the majority of cases but I appreciate that that is just my
> view.
> >
> >> Maybe I've misunderstood the migration tool, but it looks like a great
> >> tool for developers like me, not a tool that will directly help
> >> non-developers who deploy pre-built Tomcat webapps.
> > The idea is that anyone can take a Java EE 8 app that runs on Tomcat 9,
> > run it through this migration tool and then run the migrated app on
> > Tomcat 10. We aren't there yet (I've only tested a JSTL API and
> > implementation) but my intention is to use apps like Jira to test it.
> >
> >> As for Romain's question about doing the transformations in the
> >> classloader, I started with a classloader approach (my classloader
> >> responded to requests for "javax.servlet.*" classes with their
> >> "jakarta.servlet.*" counterparts). I backed away because these classes
> >> then needed to be manipulated so they'd match the javax interfaces'
> >> expectations, but I haven't used ASM before.
> > This is one of the approaches considered in previous discussions. It is,
> > essentially, what the migration tool does. I think it is better to do
> > this conversion in advance rather than take the performance hit in a
> > running application. It is actually fairly simple to do as you only need
> > to modify the String constants.
> >
> >> And this part of the
> >> problem (my webapp requesting javax classes that no longer exist in
> >> Tomcat) was easily solved by simply including those classes in my jar.
> >> The more interesting problem was adapting the objects passed in the
> >> hand-offs between jakarta-only Tomcat and javax-only webapp (e.g.,
> >> Filter, Servlet, FilterChain); I'm not sure a classloader would help
> >> there. But if someone can come up with a simpler classloader (or dynamic
> >> proxy, et al)-based approach, then I'm all for it.
> > I spent a bit of time thinking about this but didn't get as far as
> > coding it. I came to the conclusion it could get very messy once you
> > start wrapping requests and dispatching them and decided to focus on the
> > migration tool instead.
> >
> > Overall, I think it is good that there are a range of tools supporting a
> > range of approaches. As users start the migration progress, hopefully
> > we'll get some feedback and we can refine the tools and/or the
> approaches.
> >
> > I'd encourage you to put your code somewhere where others can look at it
> > (GitHub being the obvious choice these days) and I'd ask you to consider
> > using the Apache License v2 as that makes it very easy to integrate into
> > Tomcat at some point in the future if that turns out to be the best
> > thing to do.
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail:dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail:dev-h...@tomcat.apache.org
>
> Mark,
>
> Thanks very much for your response. I agree the ideal migration strategy
> will vary and a build-based (or post-build) tool should work for most
> developers. But if there's sufficient demand for a run-time migration
> layer, I believe the implementation would be fairly straightforward and
> the result reasonably efficient.
>
> All of my proof-of-concept code is available on Github:
> 

Re: javax -> jakarta rename

2019-12-21 Thread Romain Manni-Bucau
Hi Adam,

Did you evaluate a class transformer added to tomcat classloader?
This can stay quite light and enables the same while not using app loader -
standard tomcat mode. For app loader case integrations can do the work
easily (spring and friends) since they all have asm or equivalent.

Hope it makes sense.


Le sam. 21 déc. 2019 à 07:36, Adam Rauch  a écrit :

> I've watched with great interest the recent list discussions surrounding
> javax -> jakarta renaming and the draft release numbering plan. I'm
> curious: Would the Tomcat team consider making a Tomcat release that
> supports BOTH the javax and jakarta package names?
>
> Please hear me out before dismissing this as completely insane. Shortly
> after Mark published his Tomcat "jakarta" branch, I built it and fired
> up our very large webapp (LabKey Server). Of course, it didn't run,
> given it was compiled against the javax API (I see approximately 25,000
> references to javax.servlet.* in our code). As an experiment, I then
> built a jar that restores javax.* implementation classes that we care
> about and added some new classes that adapt the jakarta packaged objects
> coming from Tomcat to the javax packaged objects that our webapp
> expects. I dropped that jar into /lib, without touching any
> Tomcat or LabKey code, and our webapp started up, with Filters initing
> and filtering, Servlets servicing, requests being served, pages
> rendering, etc. The work is incomplete (e.g., most of our pre-compiled
> JSPs were unhappy with this initial attempt... though I have ideas
> there), but it provides a reasonable proof of concept, IMO. You can
> inspect the prototype layer here:
> https://github.com/labkey-adam/jakarta-javax
>
> Why bother offering a Tomcat release that supports both package names?
> To provide a much needed transition option for those who deploy Tomcat
> webapps. I'm not particularly concerned about my team's development
> effort to accommodate the rename (search & replace, upgrade Spring and
> other dependencies). I'm much more concerned about the hundreds of
> organizations that deploy our webapp. As we've transitioned our clients
> through all previous Tomcat upgrades, we've never required a
> simultaneous upgrade of both Tomcat and LabKey; we've always offered
> them the ability to upgrade our product and its dependencies
> independently, over the course of months or even years. A major Tomcat
> release upgrade may be a fairly trivial task to you and me, but it's a
> very big deal to the research organizations that use our system,
> particularly given their need to adhere to strict healthcare compliance
> regulations and validation procedures.
>
> I'd be curious to hear if other developers have concerns about their
> customers' ability to make this transition and if there's interest in
> exploring a dual-package release (or sanctioned add-on). I'd be happy to
> help with the development and testing of such a solution.
>
> Thanks,
> Adam
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: [VOTE] Release Apache Tomcat 9.0.30

2019-12-09 Thread Romain Manni-Bucau
+1 (non binding)

Le lun. 9 déc. 2019 à 16:18, Coty Sutherland  a écrit :

> On Sat, Dec 7, 2019 at 12:24 PM Mark Thomas  wrote:
>
>> The proposed Apache Tomcat 9.0.30 release is now available for voting.
>>
>> The major changes compared to the 9.0.29 release are:
>>
>> - Correct multiple regressions in the static resource caching related to
>>   using URLs provided for cached resources
>>
>> - Improvements to the Realm interface and implementations
>>
>> - Bug fixes and improvements to the CORS filter
>>
>> Along with lots of other bug fixes and improvements.
>>
>> For full details, see the changelog:
>> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>>
>> It can be obtained from:
>> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.30/
>> The Maven staging repo is:
>> https://repository.apache.org/content/repositories/orgapachetomcat-1240/
>> The tag is:
>> https://github.com/apache/tomcat/tree/9.0.30
>> 4fab4cc012d0c31852e957d198cb0549f3d6074c
>>
>> The proposed 9.0.30 release is:
>> [ ] Broken - do not release
>> [x] Stable - go ahead and release as 9.0.30
>>
>
> +1
>
>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>


Re: Embedded and default MIME types

2019-12-04 Thread Romain Manni-Bucau
+1 to align both, really reduces diff in tests and prod

Le mer. 4 déc. 2019 à 19:23, Mark Thomas  a écrit :

> On 04/12/2019 18:11, Christopher Schultz wrote:
> > Mark,
> >
> > On 12/4/19 13:02, Mark Thomas wrote:
> >> Hi all,
> >
> >> I was looking at this as an off-shoot of looking at BZ 63985.
> >
> >> Currently, there are 844 MIME mappings in conf/web.xml that are
> >> not included in Tomcat.DEFAULT_MIME_MAPPINGS. Fixing it isn't too
> >> hard. The 844 figure comes from a unit test I could easily tweak to
> >> generate the code needed to paste in to add these.
> >
> >> The question is, do we want to keep these in sync?
> >
> >> If the answer is yes I can get this fixed fairly quickly and add
> >> some unit tests to ensure that they stay in sync.
> >
> >> Thoughts?
> >
> > What about reading them from a file instead of hard-coding them?
> >
> > That same file can be used at build-time to generate the actual
> > contents of the conf/web.xml that we ship as a binary.
>
> We could. I'm not convinced the savings of only maintaining a single
> file going forwards is worth the extra work to do that.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: RewriteMap parsing

2019-11-01 Thread Romain Manni-Bucau
Hi Felix

Overall it looks good but I'd do two minor changes:

1. Only lookup providers once per context (ServiceLoader result being
cached per parser instance)
2. Likely lazy load the parsing after context startup to ensure ioc can be
used (spring web or cdi lookups)

Hope it makes sense

Le ven. 1 nov. 2019 à 18:31, Felix Schumacher <
felix.schumac...@internetallee.de> a écrit :

>
> Am 01.11.19 um 14:24 schrieb Romain Manni-Bucau:
>
>
>
> Le ven. 1 nov. 2019 à 11:26, Felix Schumacher <
> felix.schumac...@internetallee.de> a écrit :
>
>>
>> Am 01.11.19 um 11:11 schrieb Romain Manni-Bucau:
>>
>> Through the spi IMHO and if it can be ambiguous use an ordinal or
>> priority to let it be overriden maybe?
>>
>> Do we want users to be able to overwrite our functions? Is the "int:"
>> namespace free for everyone?
>>
> I think so, like enabling to enrich it (often implemented as a delegation)
>
>
>
> Should we break the context startup in case of duplicate functions in the
>> registry?
>>
>
> If they have the same priority I think so.
>
>
> I have submitted a PR that tries to implement the discussed features:
> https://github.com/apache/tomcat/pull/221
>
> Felix
>
>
>
> Felix
>>
>>
>> Le ven. 1 nov. 2019 à 10:46, Felix Schumacher <
>> felix.schumac...@internetallee.de> a écrit :
>>
>>>
>>> Am 28.10.19 um 23:06 schrieb Romain Manni-Bucau:
>>>
>>> +1 for quotes
>>>
>>> Can the "function" support be pluggable either with an explicit registry
>>> or a SPI? Would be awesome to enrich it in "super tomcat" instances
>>> (thinking to meecrowave, tomee and maybe spring boot).
>>>
>>> The function support is already pluggable (by the configuration file :),
>>> but I thought about adding SPI.
>>>
>>> It is unclear to me, how to determine the namespace ("int:" in the httpd
>>> example), should it be given by the Service Provider? Would "int" be
>>> reserved for our own functions? How could we achieve such a reservation
>>> mechnism?
>>>
>>> Felix
>>>
>>>
>>> Le lun. 28 oct. 2019 à 21:43, Mark Thomas  a écrit :
>>>
>>>>
>>>>
>>>> On 27/10/2019 11:27, Felix Schumacher wrote:
>>>> > Hi all,
>>>> >
>>>> > while looking at the RewriteMap configuration, I noticed, that parsing
>>>> > of the RewriteMap directive is a bit minimal. Parameters are split at
>>>> > whitespace (no quotes will be recognized) and only the first of the
>>>> > optional parameters will be used.
>>>> >
>>>> > Should this be changed? If so, should we introduce quoting
>>>> capabilities
>>>> > to gather the "one" optional parameter, or allow multiple parameters?
>>>> >
>>>> > Version "quote":
>>>> >
>>>> > RewriteMap m1 example.MyMap "some params"
>>>> >
>>>> > Version "multiple"
>>>> >
>>>> > RewriteMap m2 example.OtherMap one two three
>>>> >
>>>> > Or should it be a combination?
>>>>
>>>> That is probably the most flexible option. I'd lean towards this option
>>>> but would be happy to support the majority view if different.
>>>>
>>>> > "quote" would be sort of compatible with the current interface, as we
>>>> > still have only one parameter. "multiple" would be a nicer interface
>>>> for
>>>> > the implementer of the map.
>>>> >
>>>> > Another thing I noticed, is that the httpd rewrite map feature has a
>>>> few
>>>> > builtin maps, that could be useful to supply with our implementation.
>>>> > Any thoughts on supplying those? (I thought about the maps
>>>> > int:[toupper,tolower,escape,unescape], txt:, rnd: and possibly a new
>>>> one
>>>> > called jdbc:{jndi-connection}:{sql statement with placeholder}. For
>>>> > these elements a quote detection would be a must)
>>>>
>>>> I don't recall any requests for these on the users list but maybe that
>>>> is because the feature isn't that well known.
>>>>
>>>> Mark
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>>
>>>>


Re: RewriteMap parsing

2019-11-01 Thread Romain Manni-Bucau
Le ven. 1 nov. 2019 à 11:26, Felix Schumacher <
felix.schumac...@internetallee.de> a écrit :

>
> Am 01.11.19 um 11:11 schrieb Romain Manni-Bucau:
>
> Through the spi IMHO and if it can be ambiguous use an ordinal or priority
> to let it be overriden maybe?
>
> Do we want users to be able to overwrite our functions? Is the "int:"
> namespace free for everyone?
>
I think so, like enabling to enrich it (often implemented as a delegation)



Should we break the context startup in case of duplicate functions in the
> registry?
>

If they have the same priority I think so.


Felix
>
>
> Le ven. 1 nov. 2019 à 10:46, Felix Schumacher <
> felix.schumac...@internetallee.de> a écrit :
>
>>
>> Am 28.10.19 um 23:06 schrieb Romain Manni-Bucau:
>>
>> +1 for quotes
>>
>> Can the "function" support be pluggable either with an explicit registry
>> or a SPI? Would be awesome to enrich it in "super tomcat" instances
>> (thinking to meecrowave, tomee and maybe spring boot).
>>
>> The function support is already pluggable (by the configuration file :),
>> but I thought about adding SPI.
>>
>> It is unclear to me, how to determine the namespace ("int:" in the httpd
>> example), should it be given by the Service Provider? Would "int" be
>> reserved for our own functions? How could we achieve such a reservation
>> mechnism?
>>
>> Felix
>>
>>
>> Le lun. 28 oct. 2019 à 21:43, Mark Thomas  a écrit :
>>
>>>
>>>
>>> On 27/10/2019 11:27, Felix Schumacher wrote:
>>> > Hi all,
>>> >
>>> > while looking at the RewriteMap configuration, I noticed, that parsing
>>> > of the RewriteMap directive is a bit minimal. Parameters are split at
>>> > whitespace (no quotes will be recognized) and only the first of the
>>> > optional parameters will be used.
>>> >
>>> > Should this be changed? If so, should we introduce quoting capabilities
>>> > to gather the "one" optional parameter, or allow multiple parameters?
>>> >
>>> > Version "quote":
>>> >
>>> > RewriteMap m1 example.MyMap "some params"
>>> >
>>> > Version "multiple"
>>> >
>>> > RewriteMap m2 example.OtherMap one two three
>>> >
>>> > Or should it be a combination?
>>>
>>> That is probably the most flexible option. I'd lean towards this option
>>> but would be happy to support the majority view if different.
>>>
>>> > "quote" would be sort of compatible with the current interface, as we
>>> > still have only one parameter. "multiple" would be a nicer interface
>>> for
>>> > the implementer of the map.
>>> >
>>> > Another thing I noticed, is that the httpd rewrite map feature has a
>>> few
>>> > builtin maps, that could be useful to supply with our implementation.
>>> > Any thoughts on supplying those? (I thought about the maps
>>> > int:[toupper,tolower,escape,unescape], txt:, rnd: and possibly a new
>>> one
>>> > called jdbc:{jndi-connection}:{sql statement with placeholder}. For
>>> > these elements a quote detection would be a must)
>>>
>>> I don't recall any requests for these on the users list but maybe that
>>> is because the feature isn't that well known.
>>>
>>> Mark
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>>


Re: RewriteMap parsing

2019-11-01 Thread Romain Manni-Bucau
Through the spi IMHO and if it can be ambiguous use an ordinal or priority
to let it be overriden maybe?

Le ven. 1 nov. 2019 à 10:46, Felix Schumacher <
felix.schumac...@internetallee.de> a écrit :

>
> Am 28.10.19 um 23:06 schrieb Romain Manni-Bucau:
>
> +1 for quotes
>
> Can the "function" support be pluggable either with an explicit registry
> or a SPI? Would be awesome to enrich it in "super tomcat" instances
> (thinking to meecrowave, tomee and maybe spring boot).
>
> The function support is already pluggable (by the configuration file :),
> but I thought about adding SPI.
>
> It is unclear to me, how to determine the namespace ("int:" in the httpd
> example), should it be given by the Service Provider? Would "int" be
> reserved for our own functions? How could we achieve such a reservation
> mechnism?
>
> Felix
>
>
> Le lun. 28 oct. 2019 à 21:43, Mark Thomas  a écrit :
>
>>
>>
>> On 27/10/2019 11:27, Felix Schumacher wrote:
>> > Hi all,
>> >
>> > while looking at the RewriteMap configuration, I noticed, that parsing
>> > of the RewriteMap directive is a bit minimal. Parameters are split at
>> > whitespace (no quotes will be recognized) and only the first of the
>> > optional parameters will be used.
>> >
>> > Should this be changed? If so, should we introduce quoting capabilities
>> > to gather the "one" optional parameter, or allow multiple parameters?
>> >
>> > Version "quote":
>> >
>> > RewriteMap m1 example.MyMap "some params"
>> >
>> > Version "multiple"
>> >
>> > RewriteMap m2 example.OtherMap one two three
>> >
>> > Or should it be a combination?
>>
>> That is probably the most flexible option. I'd lean towards this option
>> but would be happy to support the majority view if different.
>>
>> > "quote" would be sort of compatible with the current interface, as we
>> > still have only one parameter. "multiple" would be a nicer interface for
>> > the implementer of the map.
>> >
>> > Another thing I noticed, is that the httpd rewrite map feature has a few
>> > builtin maps, that could be useful to supply with our implementation.
>> > Any thoughts on supplying those? (I thought about the maps
>> > int:[toupper,tolower,escape,unescape], txt:, rnd: and possibly a new one
>> > called jdbc:{jndi-connection}:{sql statement with placeholder}. For
>> > these elements a quote detection would be a must)
>>
>> I don't recall any requests for these on the users list but maybe that
>> is because the feature isn't that well known.
>>
>> Mark
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>


Re: RewriteMap parsing

2019-10-28 Thread Romain Manni-Bucau
+1 for quotes

Can the "function" support be pluggable either with an explicit registry or
a SPI? Would be awesome to enrich it in "super tomcat" instances (thinking
to meecrowave, tomee and maybe spring boot).

Le lun. 28 oct. 2019 à 21:43, Mark Thomas  a écrit :

>
>
> On 27/10/2019 11:27, Felix Schumacher wrote:
> > Hi all,
> >
> > while looking at the RewriteMap configuration, I noticed, that parsing
> > of the RewriteMap directive is a bit minimal. Parameters are split at
> > whitespace (no quotes will be recognized) and only the first of the
> > optional parameters will be used.
> >
> > Should this be changed? If so, should we introduce quoting capabilities
> > to gather the "one" optional parameter, or allow multiple parameters?
> >
> > Version "quote":
> >
> > RewriteMap m1 example.MyMap "some params"
> >
> > Version "multiple"
> >
> > RewriteMap m2 example.OtherMap one two three
> >
> > Or should it be a combination?
>
> That is probably the most flexible option. I'd lean towards this option
> but would be happy to support the majority view if different.
>
> > "quote" would be sort of compatible with the current interface, as we
> > still have only one parameter. "multiple" would be a nicer interface for
> > the implementer of the map.
> >
> > Another thing I noticed, is that the httpd rewrite map feature has a few
> > builtin maps, that could be useful to supply with our implementation.
> > Any thoughts on supplying those? (I thought about the maps
> > int:[toupper,tolower,escape,unescape], txt:, rnd: and possibly a new one
> > called jdbc:{jndi-connection}:{sql statement with placeholder}. For
> > these elements a quote detection would be a must)
>
> I don't recall any requests for these on the users list but maybe that
> is because the feature isn't that well known.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: [VOTE] Private branches in the official Tomcat git repository

2019-10-12 Thread Romain Manni-Bucau
Le sam. 12 oct. 2019 à 15:57, Konstantin Kolinko  a
écrit :

> пт, 11 окт. 2019 г. в 17:21, Rémy Maucherat :
> >
> > Hi,
> >
> > This vote is to regulate the use of branches in the official Tomcat
> repository beyond branches that are approved by the community such as 8.5.x
> and 7.0.x. It is possible to do development in private branches directly in
> the official Tomcat repository, as an alternative to using forks and pull
> requests.
> >
> > Should private branches be allowed in the official Tomcat git repository
> ?
> > [x] Yes
> > [ ] No
>
> Certainly Yes. We must be able to conduct our business without relying
> on GitHub and without relying on its pull requests.
>
> If we call them not "private" branches, but "feature" branches - your
> email concerns will be the same, but many projects are using feature
> branches.
>
>
> I agree that titling a commit as "First draft" is a bad naming. I
> would like to see more elaborated commit message, with more context in
> it.
>
> If you remember when we were using Subversion, feature branches were
> used several times. E.g. I used them to backport testing framework to
> Tomcat 6. It generated a lot of emails, but their Subject line
> contained the root path of the commit, and in Subversion such path
> includes a branch name.
>
> > As a big github user, i expect main repo to not have unofficially
> supported code.
>
> Technically, the only supported code are the official releases that
> have passed a vote. Anything else is a work in progress.
>

Read it as "external corrupted code".
While only committers can push branches it is fine for me.


> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: [VOTE] Private branches in the official Tomcat git repository

2019-10-12 Thread Romain Manni-Bucau
[No] (non binding). As a big github user, i expect main repo to not have
unofficially supported code. I work with this kind of setup (for CI) and it
is a mess at all layers compared to natural PR structure IMHO.

Le sam. 12 oct. 2019 à 02:05, Chuck Caldarale  a écrit :

> On Oct 11, 2019, at 09:20, Rémy Maucherat  wrote:
>
> > This vote is to regulate the use of branches in the official Tomcat
> > repository beyond branches that are approved by the community
> > such as 8.5.x and 7.0.x. It is possible to do development in private
> > branches directly in the official Tomcat repository, as an alternative
> > to using forks and pull requests.
>
> > Should private branches be allowed in the official Tomcat git repository
> ?
> [ ] Yes
> [x] No
>
> I’m not a committer, so my vote doesn’t really count, but I am a long-time
> Tomcat user and occasional contributer (less these days due to work
> priorities). I find the use of personal branches in the public repository
> to be at best annoying.
>
>   - Chuck
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: PooledConnection#connectUsingDriver, Thread.currentThread().getContextClassLoader() is null

2019-08-02 Thread Romain Manni-Bucau
Finally managed to reproduce it in a test:
https://github.com/apache/tomcat/pull/183

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 30 juil. 2019 à 14:21, Romain Manni-Bucau  a
écrit :

> Yes, got caught by PooledConnection.class.getClassLoader() which tries to
> load the driver from tomcat/lib first (common.loader actually) so if you
> put your driver there it will work in your case. Stays the bug when the
> driver is only in the webapp.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mar. 30 juil. 2019 à 13:30, Clemens Wyss DEV  a
> écrit :
>
>> > recent tomcat version
>>
>> 9.0.22 has the same class loading code as 8.5.35
>>
>>
>> https://jar-download.com/artifacts/org.apache.tomcat/tomcat-jdbc/9.0.22/source-code/org/apache/tomcat/jdbc/pool/PooledConnection.java
>>
>> driver = (java.sql.Driver)
>>
>> ClassLoaderUtil.*loadClass*(
>>
>> poolProperties.getDriverClassName(),
>>
>> PooledConnection.*class*.getClassLoader(),
>>
>> Thread.*currentThread*
>> ().getContextClassLoader()
>>
>> ).getConstructor().newInstance();
>>
>>
>>
>>
>>
>> *Von:* Romain Manni-Bucau 
>> *Gesendet:* Montag, 29. Juli 2019 09:35
>> *An:* Tomcat Developers List 
>> *Betreff:* Re: PooledConnection#connectUsingDriver,
>> Thread.currentThread().getContextClassLoader() is null
>>
>>
>>
>> Can you give a try on a more recent tomcat version? Seems it works with
>> master version since the tomcat-jdbc module classloader is tried first
>> before the tccl?
>>
>> Tested with:
>>
>>
>>
>> *public class *PooledConnectionTest {
>> @Test
>> *public void *avoidNPEWhenTcclIsNull() *throws *SQLException {
>> *final *PoolProperties poolProperties = *new *PoolProperties();
>> poolProperties.setDriverClassName(*"org.h2.Driver"*);
>> poolProperties.setUsername(*"sa"*);
>> poolProperties.setPassword(*""*);
>> 
>> poolProperties.setUrl(*"jdbc:h2:mem:PooledConnectionTest_avoidNPEWhenTcclIsNull"*);
>> poolProperties.setMaxIdle(1);
>> poolProperties.setMinIdle(1);
>> poolProperties.setInitialSize(1);
>> poolProperties.setMaxActive(1);
>>
>> ensureDataSourceIsValid(poolProperties);
>>
>> *final *Thread thread = Thread.*currentThread*();
>> *final *ClassLoader testLoader = thread.getContextClassLoader();
>> thread.setContextClassLoader(*null*);
>> *try *{
>> ensureDataSourceIsValid(poolProperties);
>> } *finally *{
>> thread.setContextClassLoader(testLoader);
>> }
>> }
>>
>> *private void *ensureDataSourceIsValid(*final *PoolProperties 
>> poolProperties) *throws *SQLException {
>> *final *DataSource dataSource = *new *DataSource(poolProperties);
>> *try *(*final *Connection connection = dataSource.getConnection()) {
>> *assertTrue*(connection.isValid(5));
>> } *finally *{
>> dataSource.close();
>> }
>> }
>> }
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>>
>>
>>
>> Le lun. 29 juil. 2019 à 07:36, Clemens Wyss DEV  a
>> écrit :
>>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=63612
>>
>>

Re: PooledConnection#connectUsingDriver, Thread.currentThread().getContextClassLoader() is null

2019-07-30 Thread Romain Manni-Bucau
Yes, got caught by PooledConnection.class.getClassLoader() which tries to
load the driver from tomcat/lib first (common.loader actually) so if you
put your driver there it will work in your case. Stays the bug when the
driver is only in the webapp.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 30 juil. 2019 à 13:30, Clemens Wyss DEV  a
écrit :

> > recent tomcat version
>
> 9.0.22 has the same class loading code as 8.5.35
>
>
> https://jar-download.com/artifacts/org.apache.tomcat/tomcat-jdbc/9.0.22/source-code/org/apache/tomcat/jdbc/pool/PooledConnection.java
>
> driver = (java.sql.Driver)
>
> ClassLoaderUtil.*loadClass*(
>
> poolProperties.getDriverClassName(),
>
> PooledConnection.*class*.getClassLoader(),
>
> Thread.*currentThread*
> ().getContextClassLoader()
>
> ).getConstructor().newInstance();
>
>
>
>
>
> *Von:* Romain Manni-Bucau 
> *Gesendet:* Montag, 29. Juli 2019 09:35
> *An:* Tomcat Developers List 
> *Betreff:* Re: PooledConnection#connectUsingDriver,
> Thread.currentThread().getContextClassLoader() is null
>
>
>
> Can you give a try on a more recent tomcat version? Seems it works with
> master version since the tomcat-jdbc module classloader is tried first
> before the tccl?
>
> Tested with:
>
>
>
> *public class *PooledConnectionTest {
> @Test
> *public void *avoidNPEWhenTcclIsNull() *throws *SQLException {
> *final *PoolProperties poolProperties = *new *PoolProperties();
> poolProperties.setDriverClassName(*"org.h2.Driver"*);
> poolProperties.setUsername(*"sa"*);
> poolProperties.setPassword(*""*);
> 
> poolProperties.setUrl(*"jdbc:h2:mem:PooledConnectionTest_avoidNPEWhenTcclIsNull"*);
> poolProperties.setMaxIdle(1);
> poolProperties.setMinIdle(1);
> poolProperties.setInitialSize(1);
> poolProperties.setMaxActive(1);
>
> ensureDataSourceIsValid(poolProperties);
>
> *final *Thread thread = Thread.*currentThread*();
> *final *ClassLoader testLoader = thread.getContextClassLoader();
> thread.setContextClassLoader(*null*);
> *try *{
> ensureDataSourceIsValid(poolProperties);
> } *finally *{
> thread.setContextClassLoader(testLoader);
> }
> }
>
> *private void *ensureDataSourceIsValid(*final *PoolProperties 
> poolProperties) *throws *SQLException {
>     *final *DataSource dataSource = *new *DataSource(poolProperties);
> *try *(*final *Connection connection = dataSource.getConnection()) {
> *assertTrue*(connection.isValid(5));
> } *finally *{
> dataSource.close();
> }
> }
> }
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
>
>
>
> Le lun. 29 juil. 2019 à 07:36, Clemens Wyss DEV  a
> écrit :
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63612
>
>
> > with a small project reproducing it?
>
> Unfortunately not easily extractable/reproducible
>
> Maybe :
>
> th = new Thread() {
> @Override
>
> public void run() {
> « do something that requires a connection from the pool »
>
> }
> } ;
> th.set getContextClassLoader( null ) ;
> th.run() ;
>
>
>
> *Von:* Romain Manni-Bucau 
> *Gesendet:* Donnerstag, 25. Juli 2019 08:06
> *An:* Tomcat Developers List 
> *Betreff:* Re: PooledConnection#connectUsingDriver,
> Thread.currentThread().getContextClassLoader() is null
>
>
>
>
>
> Le jeu. 25 juil. 2019 à 07:46, Clemens Wyss DEV  a
> écrit :
>
> < mais c'était rapide  >
> >+1
> should/can I file a bug?
>
>
>
> Guess so, with a small project reproducing it?
>
>
>
>
> > init at bootstrap the pool (initial size) to ensure it is in one tomcat
> classloader
> how would you achieve this? By setti

Re: PooledConnection#connectUsingDriver, Thread.currentThread().getContextClassLoader() is null

2019-07-29 Thread Romain Manni-Bucau
Can you give a try on a more recent tomcat version? Seems it works with
master version since the tomcat-jdbc module classloader is tried first
before the tccl?
Tested with:

public class PooledConnectionTest {
@Test
public void avoidNPEWhenTcclIsNull() throws SQLException {
final PoolProperties poolProperties = new PoolProperties();
poolProperties.setDriverClassName("org.h2.Driver");
poolProperties.setUsername("sa");
poolProperties.setPassword("");

poolProperties.setUrl("jdbc:h2:mem:PooledConnectionTest_avoidNPEWhenTcclIsNull");
poolProperties.setMaxIdle(1);
poolProperties.setMinIdle(1);
poolProperties.setInitialSize(1);
poolProperties.setMaxActive(1);

ensureDataSourceIsValid(poolProperties);

final Thread thread = Thread.currentThread();
final ClassLoader testLoader = thread.getContextClassLoader();
thread.setContextClassLoader(null);
try {
ensureDataSourceIsValid(poolProperties);
} finally {
thread.setContextClassLoader(testLoader);
}
}

private void ensureDataSourceIsValid(final PoolProperties
poolProperties) throws SQLException {
final DataSource dataSource = new DataSource(poolProperties);
try (final Connection connection = dataSource.getConnection()) {
assertTrue(connection.isValid(5));
} finally {
dataSource.close();
}
}
}


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 29 juil. 2019 à 07:36, Clemens Wyss DEV  a
écrit :

> https://bz.apache.org/bugzilla/show_bug.cgi?id=63612
>
>
> > with a small project reproducing it?
>
> Unfortunately not easily extractable/reproducible
>
> Maybe :
>
> th = new Thread() {
> @Override
>
> public void run() {
> « do something that requires a connection from the pool »
>
> }
> } ;
> th.set getContextClassLoader( null ) ;
> th.run() ;
>
>
>
> *Von:* Romain Manni-Bucau 
> *Gesendet:* Donnerstag, 25. Juli 2019 08:06
> *An:* Tomcat Developers List 
> *Betreff:* Re: PooledConnection#connectUsingDriver,
> Thread.currentThread().getContextClassLoader() is null
>
>
>
>
>
> Le jeu. 25 juil. 2019 à 07:46, Clemens Wyss DEV  a
> écrit :
>
> < mais c'était rapide  >
> >+1
> should/can I file a bug?
>
>
>
> Guess so, with a small project reproducing it?
>
>
>
>
> > init at bootstrap the pool (initial size) to ensure it is in one tomcat
> classloader
> how would you achieve this? By setting «initialSize» to «maxSize» in
> PoolProperties?
>
>
>
> 1 should be sufficient, however tomcat-jdbc (vs dbcp2 for instance) loads
> it per connection and not once for all the pool (
> https://github.com/apache/tomcat/blob/master/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PooledConnection.java#L196)
> which is likely 1. Bad for perf but moreover 2. Buggy if the classloader
> changes between usages of a connection in apps. Loader, driver should be
> loaded once and potentially the datasource be duplicated per app if needed
> (driver in the app) IMHO. This would also fix your NPE transitively ;).
>
>
>
>
>
>
>
>
> --
> Von: Romain Manni-Bucau 
> Gesendet: Donnerstag, 25. Juli 2019 07:30
> An: Tomcat Developers List 
> Betreff: Re: PooledConnection#connectUsingDriver,
> Thread.currentThread().getContextClassLoader() is null
>
> +1, there is no real other option AFAIK until you init at bootstrap the
> pool (initial size) to ensure it is in one tomcat classloader.
>
> Le jeu. 25 juil. 2019 à 07:08, Clemens Wyss DEV  clemens...@mysign.ch> a écrit :
> I tried posting this in the tomcat-users-ml, but I guess it rather fits
> here:
> --
> Context:
> Debian GNU/Linux 9 \n \l
> java version 1.8.0_162
> Tomcat 8.5.35
>
> From time to time we are facing the follwing exception (call stack):
> ...
> Caused by: java.sql.SQLException: Unable to load class:
> org.mariadb.jdbc.Driver from ClassLoader:http://java.net
> .URLClassLoader@4c873330;ClassLoader:null
> at
> org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:292)
> at
> org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:212)
>

Re: PooledConnection#connectUsingDriver, Thread.currentThread().getContextClassLoader() is null

2019-07-25 Thread Romain Manni-Bucau
Le jeu. 25 juil. 2019 à 07:46, Clemens Wyss DEV  a
écrit :

> < mais c'était rapide  >
> >+1
> should/can I file a bug?
>

Guess so, with a small project reproducing it?


> > init at bootstrap the pool (initial size) to ensure it is in one tomcat
> classloader
> how would you achieve this? By setting «initialSize» to «maxSize» in
> PoolProperties?
>

1 should be sufficient, however tomcat-jdbc (vs dbcp2 for instance) loads
it per connection and not once for all the pool (
https://github.com/apache/tomcat/blob/master/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PooledConnection.java#L196)
which is likely 1. Bad for perf but moreover 2. Buggy if the classloader
changes between usages of a connection in apps. Loader, driver should be
loaded once and potentially the datasource be duplicated per app if needed
(driver in the app) IMHO. This would also fix your NPE transitively ;).




> ------
> Von: Romain Manni-Bucau 
> Gesendet: Donnerstag, 25. Juli 2019 07:30
> An: Tomcat Developers List 
> Betreff: Re: PooledConnection#connectUsingDriver,
> Thread.currentThread().getContextClassLoader() is null
>
> +1, there is no real other option AFAIK until you init at bootstrap the
> pool (initial size) to ensure it is in one tomcat classloader.
>
> Le jeu. 25 juil. 2019 à 07:08, Clemens Wyss DEV  clemens...@mysign.ch> a écrit :
> I tried posting this in the tomcat-users-ml, but I guess it rather fits
> here:
> --
> Context:
> Debian GNU/Linux 9 \n \l
> java version 1.8.0_162
> Tomcat 8.5.35
>
> From time to time we are facing the follwing exception (call stack):
> ...
> Caused by: java.sql.SQLException: Unable to load class:
> org.mariadb.jdbc.Driver from ClassLoader:http://java.net
> .URLClassLoader@4c873330;ClassLoader:null
> at
> org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:292)
> at
> org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:212)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:736)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:668)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:198)
> at
> org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:132)
> at org.apache.torque.Torque.getConnection(Torque.java:924)
> ... 53 common frames omitted
> Caused by: java.lang.ClassNotFoundException: Unable to load class:
> org.mariadb.jdbc.Driver from ClassLoader:http://java.net
> .URLClassLoader@4c873330;ClassLoader:null
> at
> org.apache.tomcat.jdbc.pool.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:56)
> at
> org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:280)
> ... 59 common frames omitted
> Caused by: java.lang.ClassNotFoundException: Classloader is null
> at
> org.apache.tomcat.jdbc.pool.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:40)
> ... 60 common frames omitted
>
> According to the code (in PooledConnection# connectUsingDriver)
> Thread.currentThread().getContextClassLoader() returns null
>
> Googling for " Thread.currentThread().getContextClassLoader() is null" the
> common demoniator seems to be `getContextClassLoader can be null`. If this
> is true there should be
> a) a null-check in PooledConnection# connectUsingDriver
> b) if null, then there should be a fallback-Classloader (the system class
> laoder?)
>
> WDYT ?
>
> Or any ideas why the given exception pops up from time to time
>
> Thx
> Clemens
>
>
> -
> To unsubscribe, e-mail: mailto:dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: mailto:dev-h...@tomcat.apache.org
>


Re: PooledConnection#connectUsingDriver, Thread.currentThread().getContextClassLoader() is null

2019-07-24 Thread Romain Manni-Bucau
+1, there is no real other option AFAIK until you init at bootstrap the
pool (initial size) to ensure it is in one tomcat classloader.

Le jeu. 25 juil. 2019 à 07:08, Clemens Wyss DEV  a
écrit :

> I tried posting this in the tomcat-users-ml, but I guess it rather fits
> here:
>
> Context:
> Debian GNU/Linux 9 \n \l
> java version 1.8.0_162
> Tomcat 8.5.35
>
> From time to time we are facing the follwing exception (call stack):
> ...
> Caused by: java.sql.SQLException: Unable to load class:
> org.mariadb.jdbc.Driver from ClassLoader:java.net.URLClassLoader@4c873330
> ;ClassLoader:null
> at
> org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:292)
> at
> org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:212)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:736)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:668)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:198)
> at
> org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:132)
> at org.apache.torque.Torque.getConnection(Torque.java:924)
> ... 53 common frames omitted
> Caused by: java.lang.ClassNotFoundException: Unable to load class:
> org.mariadb.jdbc.Driver from ClassLoader:java.net.URLClassLoader@4c873330
> ;ClassLoader:null
> at
> org.apache.tomcat.jdbc.pool.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:56)
> at
> org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:280)
> ... 59 common frames omitted
> Caused by: java.lang.ClassNotFoundException: Classloader is null
> at
> org.apache.tomcat.jdbc.pool.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:40)
> ... 60 common frames omitted
>
> According to the code (in PooledConnection# connectUsingDriver)
> Thread.currentThread().getContextClassLoader() returns null
>
> Googling for " Thread.currentThread().getContextClassLoader() is null" the
> common demoniator seems to be `getContextClassLoader can be null`. If this
> is true there should be
> a) a null-check in PooledConnection# connectUsingDriver
> b) if null, then there should be a fallback-Classloader (the system class
> laoder?)
>
> WDYT ?
>
> Or any ideas why the given exception pops up from time to time
>
> Thx
> Clemens
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: CDI support improvements

2019-06-17 Thread Romain Manni-Bucau
Le lun. 17 juin 2019 à 16:17, Rémy Maucherat  a écrit :

> On Mon, Jun 17, 2019 at 10:52 AM Romain Manni-Bucau 
> wrote:
>
>> Hi Rémy,
>>
>> Great progression! Congrats!
>>
>> I have a few (details) notes - guess i'm opening an open door but just to
>> ensure:
>>
>> 1. Is it intended to bind cxf to /rest/* in any case? I tend to see it
>> bound on on /api but generally thanks to an Application
>> (+ @ApplicationPath("api")) so cxf is bound on /*. Wonder if the listener
>> shouldn't host that config and we would link it through a context listener
>> or servletcontextinitializer (both will work and rely on tomcat internals)
>>
>
> I am not comfortable mapping a servlet on /* by default, it would be
> annoying, so I changed the mapping to /api/*. I used a web-fragment for now
> since it's a decent Servlet API feature and has plenty of configuration
> flexibility.
> Adding additional CXF integration would be good but is work, a filter
> could useful. Moving CXF to a container integration is even more work and
> doesn't looks that practical to me.
>
> The CDI context listener configuring CXF if is present sounds possible (it
> can programmatically add the CDI CXF servlet, no problem), it does sound a
> bit weird conceptually but it's a good option.
>
>
>> 2. In beans.xml, rather than annotated mode - which skips a lot of
>> classes which can be used in CDI - we tend to prefer discovery mode
>> "full" + trim:
>> https://github.com/apache/geronimo-health/blob/master/geronimo-health/src/main/resources/META-INF/beans.xml
>>
>
> I don't understand how that works, if I add scanning to tomcat-cxf.jar, it
> loads all classes (which fails). So that's why I'm not doing it.
>

If you can detail that, I can surely help.
If you can change the code, adding @Vetoed on classes you don't want to be
CDI beans can help too.
The annotated mode - default in cxf - was here to "work out of the box",
however the defaults were not that great and it is easy to fall in a case
where "it should work". All mode is more reliable and aligned on the "old"
(1.0) scanning where all beans are here, the  addition was there to
drop the useless types and ensure the deployment stays "light".
So long story short, full+trim is likely the less error prone and
priviledged mode today.


>
>
>> 3. Why not merging SPI files thanks to maven?  (shade part, end of
>> http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html)
>> 4. You have a spring config (cxf.xml), not sure it is intended?
>> 5. jettison is not needed since it is not the one used for json
>> serialization (guess you can drop several cxf deps)
>>
>
> Very good idea, I made changes and fixed these items.
>



BTW, is the assembly available?


>
> Rémy
>
>


Re: CDI support improvements

2019-06-17 Thread Romain Manni-Bucau
PS/FYI: just noticed jetty did the same kind of work with weld 4 years ago:
https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-cdi/cdi-servlet/src/main/config/etc/jetty-cdi.xml,
great Tomcat is catching up :).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 17 juin 2019 à 10:52, Romain Manni-Bucau  a
écrit :

> Hi Rémy,
>
> Great progression! Congrats!
>
> I have a few (details) notes - guess i'm opening an open door but just to
> ensure:
>
> 1. Is it intended to bind cxf to /rest/* in any case? I tend to see it
> bound on on /api but generally thanks to an Application
> (+ @ApplicationPath("api")) so cxf is bound on /*. Wonder if the listener
> shouldn't host that config and we would link it through a context listener
> or servletcontextinitializer (both will work and rely on tomcat internals)
> 2. In beans.xml, rather than annotated mode - which skips a lot of classes
> which can be used in CDI - we tend to prefer discovery mode "full" + trim:
> https://github.com/apache/geronimo-health/blob/master/geronimo-health/src/main/resources/META-INF/beans.xml
> 3. Why not merging SPI files thanks to maven?  (shade part, end of
> http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html)
> 4. You have a spring config (cxf.xml), not sure it is intended?
> 5. jettison is not needed since it is not the one used for json
> serialization (guess you can drop several cxf deps)
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le lun. 17 juin 2019 à 10:29, Rémy Maucherat  a écrit :
>
>> Hi Romain,
>>
>> On Thu, Jun 13, 2019 at 6:52 PM Romain Manni-Bucau 
>> wrote:
>>
>>>
>>> https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1412
>>> is likely the one but looks like johnzon was not scanned nor registered
>>> programmatically
>>>
>>> Maybe code this bean:
>>>
>>> @Produces("application/json") // jaxrs import
>>> @Provider //jaxrs import
>>> @Dependent // cdi import
>>> public class MyJson extends JsonbJaxrsProvider {}
>>>
>>> Should be enough if it is the issue (or use delegation instead of
>>> inheritance)
>>>
>>
>> Thanks for your help, I was able to make cxf work for me, and then
>> package it in a less error prone way (
>> https://github.com/rmaucher/tomcat-cxf ).
>> It does the following:
>> - Use a bean to add the json provider
>> - Package the necessary dependencies for json, jax-rs and cdi
>> - Bundle the web-fragment for the cxf cdi servlet (I wasted quite a lot
>> of time by using the regular cxf servlet, ultimately noticing that the
>> trace wasn't using cdi)
>> tomcat-owb should then be placed in lib, add the Server listener. It will
>> CDI enable all webapps (if they use the support). CXF then uses that
>> support. Due to its intricacies (and also the fact that it's not
>> lightweight), I don't think CXF is a good choice to put in the main Tomcat
>> lib folder (and at the moment, it won't work out of the box in that case).
>>
>> I tested with a health bean from the "tck":
>> @Health
>> @ApplicationScoped
>> public class SuccessfulHealth implements HealthCheck {
>> @Override
>> public HealthCheckResponse call() {
>> return HealthCheckResponse.named("successful-check").up().build();
>> }
>> }
>> With the addition of the geronimo-health (which is a CDI extension),
>> geronimo-health-common, microprofile-health-api-1.0, and the fat jar
>> tomcat-cxf to /WEB-INF/lib, the bean is processed and runs (on
>> /rest/health). I expect the other mp APIs like metrics to work in a similar
>> way.
>>
>> Rémy
>>
>>


Re: CDI support improvements

2019-06-17 Thread Romain Manni-Bucau
Hi Rémy,

Great progression! Congrats!

I have a few (details) notes - guess i'm opening an open door but just to
ensure:

1. Is it intended to bind cxf to /rest/* in any case? I tend to see it
bound on on /api but generally thanks to an Application
(+ @ApplicationPath("api")) so cxf is bound on /*. Wonder if the listener
shouldn't host that config and we would link it through a context listener
or servletcontextinitializer (both will work and rely on tomcat internals)
2. In beans.xml, rather than annotated mode - which skips a lot of classes
which can be used in CDI - we tend to prefer discovery mode "full" + trim:
https://github.com/apache/geronimo-health/blob/master/geronimo-health/src/main/resources/META-INF/beans.xml
3. Why not merging SPI files thanks to maven?  (shade part, end of
http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html)
4. You have a spring config (cxf.xml), not sure it is intended?
5. jettison is not needed since it is not the one used for json
serialization (guess you can drop several cxf deps)

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 17 juin 2019 à 10:29, Rémy Maucherat  a écrit :

> Hi Romain,
>
> On Thu, Jun 13, 2019 at 6:52 PM Romain Manni-Bucau 
> wrote:
>
>>
>> https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1412
>> is likely the one but looks like johnzon was not scanned nor registered
>> programmatically
>>
>> Maybe code this bean:
>>
>> @Produces("application/json") // jaxrs import
>> @Provider //jaxrs import
>> @Dependent // cdi import
>> public class MyJson extends JsonbJaxrsProvider {}
>>
>> Should be enough if it is the issue (or use delegation instead of
>> inheritance)
>>
>
> Thanks for your help, I was able to make cxf work for me, and then package
> it in a less error prone way ( https://github.com/rmaucher/tomcat-cxf ).
> It does the following:
> - Use a bean to add the json provider
> - Package the necessary dependencies for json, jax-rs and cdi
> - Bundle the web-fragment for the cxf cdi servlet (I wasted quite a lot of
> time by using the regular cxf servlet, ultimately noticing that the trace
> wasn't using cdi)
> tomcat-owb should then be placed in lib, add the Server listener. It will
> CDI enable all webapps (if they use the support). CXF then uses that
> support. Due to its intricacies (and also the fact that it's not
> lightweight), I don't think CXF is a good choice to put in the main Tomcat
> lib folder (and at the moment, it won't work out of the box in that case).
>
> I tested with a health bean from the "tck":
> @Health
> @ApplicationScoped
> public class SuccessfulHealth implements HealthCheck {
> @Override
> public HealthCheckResponse call() {
> return HealthCheckResponse.named("successful-check").up().build();
> }
> }
> With the addition of the geronimo-health (which is a CDI extension),
> geronimo-health-common, microprofile-health-api-1.0, and the fat jar
> tomcat-cxf to /WEB-INF/lib, the bean is processed and runs (on
> /rest/health). I expect the other mp APIs like metrics to work in a similar
> way.
>
> Rémy
>
>


Re: CDI support improvements

2019-06-13 Thread Romain Manni-Bucau
https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1412
is likely the one but looks like johnzon was not scanned nor registered
programmatically

Maybe code this bean:

@Produces("application/json") // jaxrs import
@Provider //jaxrs import
@Dependent // cdi import
public class MyJson extends JsonbJaxrsProvider {}

Should be enough if it is the issue (or use delegation instead of
inheritance)

Le jeu. 13 juin 2019 à 18:45, Rémy Maucherat  a écrit :

> On Thu, Jun 13, 2019 at 5:31 PM Romain Manni-Bucau 
> wrote:
>
>> can you drop johnzon-jsonb (+-core + -mapper + jsonp and jsonb specs
>> jars) too?
>>
>
> Ok, thanks. Still not working though, and this part of the code doesn't
> have debug logs of any kind, so I'll now have to trace the whole thing. It
> feels bad I have to do that as serializing json didn't seem *so* complex
> overall in the first place.
>
> Rémy
>
>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le jeu. 13 juin 2019 à 17:26, Rémy Maucherat  a écrit :
>>
>>> On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>>
>>>> Joke apart, and assuming you grabbed the spec yourself (geronimo, javax
>>>> or jakarta jars) you just need:
>>>>
>>>> org.apache.cxf:cxf-core:3.3.2
>>>> org.apache.cxf:cxf-rt-security:3.3.2
>>>> org.apache.cxf:cxf-rt-transports-http:3.3.2
>>>> org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
>>>> org.apache.cxf:cxf-integration-cdi:3.3.2
>>>> org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
>>>> Microprofile you need it)
>>>>
>>>
>>> About CXF, I still have one issue related to json.
>>> org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem No
>>> message body writer has been found for class
>>> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint$AggregatedResponse,
>>> ContentType: application/json
>>> It should be very simple, but for whatever reason I cannot get it to
>>> work (I added cxf-rt-rs-extension-providers which has the json provider).
>>> Anyway it's mostly a cosmetic issue at this point.
>>>
>>> I now know what I want to do with CXF, but it's certainly harder than
>>> for OWN (no surprise).
>>>
>>> Rémy
>>>
>>>


Re: CDI support improvements

2019-06-13 Thread Romain Manni-Bucau
can you drop johnzon-jsonb (+-core + -mapper + jsonp and jsonb specs jars)
too?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 13 juin 2019 à 17:26, Rémy Maucherat  a écrit :

> On Wed, Jun 12, 2019 at 8:32 AM Romain Manni-Bucau 
> wrote:
>
>> Joke apart, and assuming you grabbed the spec yourself (geronimo, javax
>> or jakarta jars) you just need:
>>
>> org.apache.cxf:cxf-core:3.3.2
>> org.apache.cxf:cxf-rt-security:3.3.2
>> org.apache.cxf:cxf-rt-transports-http:3.3.2
>> org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
>> org.apache.cxf:cxf-integration-cdi:3.3.2
>> org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
>> Microprofile you need it)
>>
>
> About CXF, I still have one issue related to json.
> org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem No message
> body writer has been found for class
> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint$AggregatedResponse,
> ContentType: application/json
> It should be very simple, but for whatever reason I cannot get it to work
> (I added cxf-rt-rs-extension-providers which has the json provider). Anyway
> it's mostly a cosmetic issue at this point.
>
> I now know what I want to do with CXF, but it's certainly harder than for
> OWN (no surprise).
>
> Rémy
>
>


Re: CDI support improvements

2019-06-12 Thread Romain Manni-Bucau
Current owb-tomcat module is stable and could be used if some people need
it but it does not prevent us to make trunk 9.last based IMHO.

Maybe give a shout to owb dev list when you have something you want to
integrate and Ill be happy to review and support it.

Le mer. 12 juin 2019 à 18:13, Mark Struberg  a
écrit :

>
>
> > Am 12.06.2019 um 15:35 schrieb Rémy Maucherat :
> >
>
> > That did not seem very practical to me so the said code is quite
> Tomcat-like
> > right now and most importantly it needs the fixes made in 9.0.21, so it
> won't
> > work with any older Tomcat. If you really can take it over
> > (and un-Tomcatize the code, I suppose), no problem.
>
> There are multiple options on the table.
> One would be to have this code checked via reflection.
> The other is to just add a new module which is for tomcat9++
>
> >
> > > B.) We should also try to keep code and responsibilities at a single
> place and shall try to avoid duplications. This has nothing to do with
> > > 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it
> has a lot to do with users knowing exactly where to look at if they
> > > are searching for a bug or even want to contribute a new feature.
> >
> > Ok, so I guess I don't need to do anything further in that area since
> you prefer to continue covering it. I'll move on to other items on my todo
> list then.
> >
>
> We need a JIRA ticket in OWB with a description of the suggested
> improvements.
> After all we'd love to understand and document what improvements you would
> like to implement.
>
> And of course a patch would also be highly welcome!
>
> txs and LieGrue,
> strub
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: CDI support improvements

2019-06-12 Thread Romain Manni-Bucau
Hell Rémy,

I commented inline

Le mar. 11 juin 2019 à 23:29, Rémy Maucherat  a écrit :

> On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau 
> wrote:
>
>> My 2cts would be that we have the luck to be fully ASF here so each
>> project can likely get back its missing piece(s) and we stay overall
>> consistent instead of creating yet another fork in our beloved foundation
>> (we already have some concurrent servers or even jdbc pools which does not
>> help much user land).
>>
>> @Rémy do you track the issues you encounter somewhere?
>> For instance "CXF is not user friendly" but once you have CDI you get CXF
>> set up just adding a servlet. Here, an initializer would have been friendly
>> but then you would encounter the servlet initializer ordering issue.
>>
>
> Ok :)
>
> So:
> - When downloading CXF, I'm facing a myriad of JARs, and I cannot really
> figure out what's mandatory (there's a WHICH_JARS file, so that cannot be
> that good).
>

Depends, if you use maven it is fine  ;).

Joke apart, and assuming you grabbed the spec yourself (geronimo, javax or
jakarta jars) you just need:

org.apache.cxf:cxf-core:3.3.2
org.apache.cxf:cxf-rt-security:3.3.2
org.apache.cxf:cxf-rt-transports-http:3.3.2
org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2
org.apache.cxf:cxf-integration-cdi:3.3.2
org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target
Microprofile you need it)


> - (Ok I figured it out) Looking at the integration(s), I quickly notice
> there are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and
> cxf-rt-transports-http (did I miss any ?). They all need that I define a
> Servlet it seems (no idea why at least some of these don't do it for me).
>

There are two main concepts: the integration (cdi, spring, blueprint, )
and the transport (http, jms, ...). Http transport goes through the servlet
and the integration relies on the transport to forward the messages
(request) to the CXF server which does the link with the beans.


> - After getting somewhere and trying a mp health test with your Geronimo
> Health CDI bundle, I got:
> 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2]
> org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both
> org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks
> and
> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks
> are equal candidates for handling the current request which can lead to
> unpredictable results
> 11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2]
> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse
> javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error
> at
> org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79)
> at
> org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450)
> at
> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89)
> at
> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.getInstance(PerRequestResourceProvider.java:78)
> at
> org.apache.cxf.jaxrs.JAXRSInvoker.getServiceObject(JAXRSInvoker.java:420)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101)
> ...
> Caused by: java.lang.IllegalAccessException: Class
> org.apache.cxf.jaxrs.utils.InjectionUtils can not access a member of class
> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint
> with modifiers "private"
> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
> at
> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296)
> at
> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288)
> at java.lang.reflect.Method.invoke(Method.java:491)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1442)
> ... 47 more
>
> That's where I am right now. The way to use CXF with Tomcat should be more
> obvious.
>

Geronimo Health has a common and a cdi modules (cdi one being not suffixed
in terms of naming). Both are exactly the same except cdi one uses CDI
beans for the wiring and common is reusable in an OSGi container.
Common is not intended to be scanned.
I will add a scan=none in the jar since it is not done today and leads to
that issue if not excluded from the scanned jar - can be done through
openwebbeans.properties.

-> https://issues.apache.org/jira/browse/GERONIMO-6734 if you want to give
another try with a snapshot


>
> OWB did not have most of these issues, the amount of libraries is
> manageable an

Re: CDI support improvements

2019-06-11 Thread Romain Manni-Bucau
My 2cts would be that we have the luck to be fully ASF here so each project
can likely get back its missing piece(s) and we stay overall consistent
instead of creating yet another fork in our beloved foundation (we already
have some concurrent servers or even jdbc pools which does not help much
user land).

@Rémy do you track the issues you encounter somewhere?
For instance "CXF is not user friendly" but once you have CDI you get CXF
set up just adding a servlet. Here, an initializer would have been friendly
but then you would encounter the servlet initializer ordering issue.

In other words I wonder if we can't cumulate our efforts instead of working
isolated and moreover if we can avoid to split the code and deliverables
more than necessary - sounds like overlapping will be very high without
more details.

Do we have a functional showcase app already? Can help building one if
needed.
Do you have an idea of where you want to land (in terms of config +
deliverables)?

Answering both can be a way to move forward and see how we can converge.
To complete David's answer, I kind of see that even without integrating
some EE things in Tomcat itself, it can benefit to TomEE and enable it to
align even more on Tomcat in terms of user facing configuration for
instance.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 11 juin 2019 à 21:22, Rémy Maucherat  a écrit :

> Hi David,
>
> On Tue, Jun 11, 2019 at 8:37 PM David Blevins 
> wrote:
>
>> Hi All,
>>
>> At a high level, is there a desire to start supporting more "EE" like
>> specs such as CDI, JAX-RS, JPA, etc?
>>
>> Completely understood if the answer is "depends."  I suspect it would
>> depend on if the code is clean and light in Tomcat spirit.
>>
>
> Ok, so the plan (my plan, actually) here is that I noticed CDI (and
> JAX-RS) is the building block of many other APIs (like the Microprofile),
> so there's a need to be able to use it in a "clean and light [and] in
> Tomcat spirit" way (as you said). I had a look at OWB and CXF and while the
> support is there, it needs some work (especially for the latter) and is
> certainly not user friendly (again, esp for the latter). Note that the work
> is also in Tomcat itself, since I'm in a good position to make changes and
> improvements as needed.
>
> As for the answer, it would still be "no" at this point, since at most
> these could be considered as a couple extra optional modules like the jdbc
> pool, or maybe "build them yourself" poms.
>
>
>>
>> I write this not from the perspective of "let's move a bunch of TomEE
>> code into Tomcat", but more of "let's write cleaner newer code in Tomcat
>> and retire equivalent TomEE code."
>>
>> That's not a specific proposal, just curious if appetite has developed in
>> recent years to entertain tip-toeing beyond the same set of specs.
>>
>
> Rémy
>
>>
>>
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>>
>> > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau 
>> wrote:
>> >
>> >
>> >
>> > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat  a écrit
>> :
>> > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <
>> rmannibu...@gmail.com> wrote:
>> >
>> > Once done it can be hosted on both side.Owb has the advantage to be
>> know by users, tomcat to be a more natural home for an integration. At the
>> end it is mainly synchronizing both projects for a consistent communication
>> and code "move" IMHO.
>> >
>> > For deep tomcat/cxf integration, you can use
>> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
>> module. Technically it uses an embedded flavor but it would be easy to move
>> to a standalone one through a listener based on a small refactoring in
>> Meecrowave#start. The good part are the lifecycle and scanning integrations
>> + the tooling to make testing and dev simple -
>> http://openwebbeans.apache.org/meecrowave/.
>> >
>> > Ok, I think things look reasonably good using CDI extensions (looking
>> at the Geronimo mp implementation you did) except the default CXF "servlet"
>> integration. I think right now the "servlet" integration from the
>> cxf-rt-transports-http package is "

Re: CDI support improvements

2019-06-11 Thread Romain Manni-Bucau
Le mar. 11 juin 2019 à 16:57, Rémy Maucherat  a écrit :

> On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau 
> wrote:
>
>
>> Once done it can be hosted on both side.Owb has the advantage to be know
>> by users, tomcat to be a more natural home for an integration. At the end
>> it is mainly synchronizing both projects for a consistent communication and
>> code "move" IMHO.
>>
>> For deep tomcat/cxf integration, you can use
>> http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
>> module. Technically it uses an embedded flavor but it would be easy to move
>> to a standalone one through a listener based on a small refactoring in
>> Meecrowave#start. The good part are the lifecycle and scanning integrations
>> + the tooling to make testing and dev simple -
>> http://openwebbeans.apache.org/meecrowave/.
>>
>
> Ok, I think things look reasonably good using CDI extensions (looking at
> the Geronimo mp implementation you did) except the default CXF "servlet"
> integration. I think right now the "servlet" integration from the
> cxf-rt-transports-http package is "bad" and that the one from Meecrowave
> (in org.apache.meecrowave.cxf) is more likely to be the way to go (it
> derives from cxf-integration-cdi).
>
> So this looks a lot closer to Meecrowave than I originally expected, with
> a lot of "buts" though:
> - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal here
> is a "Meecrowave for Tomcat"
>

Guess this one can converge - at least for TomEE it did and we have a tons
of flavors, I dont see a blocker to unify it here to.


> - The JAR has all of Tomcat, log4j, API JARs, etc, while it should here be
> based off Tomcat, the javax APIs and OWB already present in the Tomcat OWB
> implementation JAR (the classic "tomcat7" or the modernized "tomcat-owb")
>

The jar is just one flavor of meecrowave - assuming you reference the
fatjar, you should still be able to use it as plain unitary dependencies.
The missing part here is to extract from Meecrowave master class all the
logic to "glue" the stack in Tomcat (mainly extracting it in a Listener I
guess and ignoring the specific launcher config?)


> - log4j would need to be removed as well
>

It is already supported, in this IT we drop log4j, johnzon, cxf:
https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32


> - plenty of configuration files and options in the JARs, but I guess
> that's the way it is since all the subcomponents are so flexible
>

Yep, but all are also settable from a listener or a centralized file, we
are really free here.


>
>
>>
>>
>>>> More technically: openwebbeans does not need properties files you can
>>>> pass Properties when you create the WebBeansContext, this is what tomee
>>>> does. Same for cxf and its bus ;).
>>>>
>>>
>>> Ok, I'll have a look at that, it's better than properties files (but
>>> similar).
>>>
>>
>>>> Biggest short term challenge is to align scanners but it is very
>>>> doable, long term it is to drop big core jars in all 3 libs for smaller
>>>> bundles ;).
>>>>
>>>
>>> Ok.
>>>
>>>>
>>>> Feel free to shout if you need help or more precise pointers.
>>>>
>>>
> Rémy
>
>


Re: CDI support improvements

2019-05-30 Thread Romain Manni-Bucau
Hello Rémy,

Few precisions inline

Le jeu. 30 mai 2019 à 00:34, Rémy Maucherat  a écrit :

> Hi,
>
> On Wed, May 29, 2019 at 11:35 PM Romain Manni-Bucau 
> wrote:
>
>> Hi Rémy,
>>
>> Openwebbeans has a tomcat integration module - mainly standalone case,
>> and meecrowave subproject - embedded or ready to run fatjar. It looks like
>> it covers what you target. Where I am loosing track is why not improving
>> openwebbeans and forking the code in tomcat? At least i would expect to
>> discuss to move over tomcat the code on dev@owb - and I would support it
>> ;).
>>
>
> There's not a lot of code, so I don't call that a fork. The problem is
> that I need to make changes and adjustments in Tomcat, so in the end it
> can't be in owb. I used the code from webbeans-tomcat7, and didn't see any
> other modules (maybe you're referring to the ones in samples I just found).
>


Once done it can be hosted on both side.
Owb has the advantage to be know by users, tomcat to be a more natural home
for an integration. At the end it is mainly synchronizing both projects for
a consistent communication and code "move" IMHO.

For deep tomcat/cxf integration, you can use
http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core
module. Technically it uses an embedded flavor but it would be easy to move
to a standalone one through a listener based on a small refactoring in
Meecrowave#start. The good part are the lifecycle and scanning integrations
+ the tooling to make testing and dev simple -
http://openwebbeans.apache.org/meecrowave/.


>> More technically: openwebbeans does not need properties files you can
>> pass Properties when you create the WebBeansContext, this is what tomee
>> does. Same for cxf and its bus ;).
>>
>
> Ok, I'll have a look at that, it's better than properties files (but
> similar).
>

>> Biggest short term challenge is to align scanners but it is very doable,
>> long term it is to drop big core jars in all 3 libs for smaller bundles ;).
>>
>
> Ok.
>
>>
>> Feel free to shout if you need help or more precise pointers.
>>
>
> Rémy
>
>>
>>
>> Le mer. 29 mai 2019 à 18:26, Rémy Maucherat  a écrit :
>>
>>> Hi,
>>>
>>> This was on my hackaton todo list, I guess I'm a bit late, but getting
>>> to it now ...
>>>
>>> CDI is the building brick for many other popular libraries and
>>> frameworks, including JAX-RS (Apache CXF), Eclipse Microprofile, etc.
>>> Looking at the CDI implementation from the ASF, I am not fully satisfied
>>> with the integration or packaging of OWB in the context of Tomcat. Since
>>> it's such an important building block, I wanted to do something about it
>>> and be able to have something that played better with Tomcat standalone, in
>>> addition to embedded (that is well covered !). As a result, I took on the
>>> task to take over the Tomcat(7 ;) ) integration that was in OWB.
>>>
>>> I'm working on it here: https://github.com/rmaucher/tomcat-owb
>>>
>>> The packaging is a big jar that is not done yet (the APIs would of
>>> course be separate JARs, but the goal is to have a big-OWB JAR tuned for
>>> Tomcat with the rest). Eventually if it works well enough, I would move it
>>> to https://github.com/apache/tomcat/tree/master/modules
>>>
>>> Note: I'm not a fan of the OWB configuration, it looks rather cryptic to
>>> me (properties files spread across all the JARs, I guess that's pluggable -
>>> even though it's not really needed here). I will look at that area for
>>> Tomcat specific improvements (the main listener could be used for
>>> configuration).
>>>
>>> Note 2: Apache CXF is quite the same first impression, when I download
>>> it I find a "lib/WHICH_JARS" file, which kind of says it all. So after OWB,
>>> it's possible there would be another tomcat-cxf module, which would be
>>> packaging only (I hope/expect the integration, which uses CDI and Servlets,
>>> will not need any real improvements).
>>>
>>> Comments ?
>>>
>>> Rémy
>>>
>>>


Re: CDI support improvements

2019-05-29 Thread Romain Manni-Bucau
Hi Rémy,

Openwebbeans has a tomcat integration module - mainly standalone case, and
meecrowave subproject - embedded or ready to run fatjar. It looks like it
covers what you target. Where I am loosing track is why not improving
openwebbeans and forking the code in tomcat? At least i would expect to
discuss to move over tomcat the code on dev@owb - and I would support it ;).

More technically: openwebbeans does not need properties files you can pass
Properties when you create the WebBeansContext, this is what tomee does.
Same for cxf and its bus ;).

Biggest short term challenge is to align scanners but it is very doable,
long term it is to drop big core jars in all 3 libs for smaller bundles ;).

Feel free to shout if you need help or more precise pointers.


Le mer. 29 mai 2019 à 18:26, Rémy Maucherat  a écrit :

> Hi,
>
> This was on my hackaton todo list, I guess I'm a bit late, but getting to
> it now ...
>
> CDI is the building brick for many other popular libraries and frameworks,
> including JAX-RS (Apache CXF), Eclipse Microprofile, etc. Looking at the
> CDI implementation from the ASF, I am not fully satisfied with the
> integration or packaging of OWB in the context of Tomcat. Since it's such
> an important building block, I wanted to do something about it and be able
> to have something that played better with Tomcat standalone, in addition to
> embedded (that is well covered !). As a result, I took on the task to take
> over the Tomcat(7 ;) ) integration that was in OWB.
>
> I'm working on it here: https://github.com/rmaucher/tomcat-owb
>
> The packaging is a big jar that is not done yet (the APIs would of course
> be separate JARs, but the goal is to have a big-OWB JAR tuned for Tomcat
> with the rest). Eventually if it works well enough, I would move it to
> https://github.com/apache/tomcat/tree/master/modules
>
> Note: I'm not a fan of the OWB configuration, it looks rather cryptic to
> me (properties files spread across all the JARs, I guess that's pluggable -
> even though it's not really needed here). I will look at that area for
> Tomcat specific improvements (the main listener could be used for
> configuration).
>
> Note 2: Apache CXF is quite the same first impression, when I download it
> I find a "lib/WHICH_JARS" file, which kind of says it all. So after OWB,
> it's possible there would be another tomcat-cxf module, which would be
> packaging only (I hope/expect the integration, which uses CDI and Servlets,
> will not need any real improvements).
>
> Comments ?
>
> Rémy
>
>


Re: Registry instance aligned on Tomcat/Server lifecycle?

2019-05-15 Thread Romain Manni-Bucau
Oki, I can hear it is a lot of work for a small gain, however, at least, it
is possible to ensure the disable method is re-callable (actually setting
the registry instance) and that there is an enableRegistry() method. It is
ok and cheap IMO to have a global reference counting and force it to be ==
0 to ensure we don't change the setup if a server is already running.

Use case is to be able to have:

lifecycle()
  configureJMX();
  startServer();
  stopServer();

can call lifecycle twice with the configuration of configureJMX being
different.

High level it looks cheaper and solves my current issue with the disable
method too.

Does it sound better?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 15 mai 2019 à 13:52, Mark Thomas  a écrit :

> On 15/05/2019 10:35, Romain Manni-Bucau wrote:
> > 9.0.20 got a disableRegistry method in Registry class (for JMX server
> > interaction),
> > I wonder if it is possible to enhance it a bit to make it instance bound
> > to the server instead of being global.
> >
> > It would enable to start/stop/restart servers potentially
> > deactivating/activating JMX without issues if multiple tomcat instances
> > are started in the same JVM.
> >
> > wdyt?
>
> Currently all registrations go through a singleton Registry instance.
>
> The process to obtain a Registry instance would need to be changed to
> obtain one per Server. That looks to be doable (there look to be just
> over 40 instances of calling the getRegistry() method). We might even be
> able to use the existing key parameter (once we restore the key related
> plumbing we only just removed).
>
> How much user demand has there been for making this more granular? So
> far, the only requests I have seen have been from users wanting to
> disable JMX registration completely for Tomcat objects.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Registry instance aligned on Tomcat/Server lifecycle?

2019-05-15 Thread Romain Manni-Bucau
Hi guys,

9.0.20 got a disableRegistry method in Registry class (for JMX server
interaction),
I wonder if it is possible to enhance it a bit to make it instance bound to
the server instead of being global.

It would enable to start/stop/restart servers potentially
deactivating/activating JMX without issues if multiple tomcat instances are
started in the same JVM.

wdyt?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Re: Jakarta package change

2019-05-07 Thread Romain Manni-Bucau
I agree with the 2030 statement but it also means not replacing javax by
jakarta is saner because it avoids to duplicate and make ambiguous the API
and also reduce maintenance cost. It also keeps tomcat embedded working -
classloader hacks or javaagent can be tricky to keep performing well with
recent java versions.

Any servlet evolution under the radar? Anything not doable already or are
we fighting ghosts?

Le mar. 7 mai 2019 à 19:33, Mark Struberg  a
écrit :

> Hi folks!
>
> Yes, I'm right now playing with it.
> For a little more background and overview I've written up a blog post:
>
> https://struberg.wordpress.com/2019/05/06/the-way-forward-for-jakartaee-packages/
>
> I've also already started to migrate a few spec packages.
> The current work in progress is available here:
> https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/
>
> I've already test-migrated over Apache OpenWebBeans CDI container.
> Of course with TCK and servlet integration disabled for now as Arquillian
> and Tomcat first needs to be ported.
> https://github.com/struberg/openwebbeans/tree/jakarta
>
> I'm right now tinkering with Tomcat.
> And boy, tomcat has way more dependencies than I'd like.
> And it would help if it would finally be migrated to use Maven, but I
> spare you that ;)
>
> As soon as I've something decently working then I'll share!
>
> LieGrue,
> strub
>
> > Am 07.05.2019 um 14:09 schrieb Rémy Maucherat :
> >
> > On Tue, May 7, 2019 at 12:31 PM Mark Thomas  wrote:
> >
> >> On 07/05/2019 08:05, Rémy Maucherat wrote:
> >>> Hi,
> >>>
> >>> Background information:
> >>> https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/
> >>>
> >>> So this is obviously a large breaking change. While there are plenty of
> >>> options, there is a simple one too:
> >>> - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all
> the
> >>> APIs in Tomcat 9 can remain javax.* and users with "old" applications
> >> will
> >>> still have an up to date fully compatible container for them.
> >>> - Have a Tomcat 10 with all API packages renamed to jakarta.*, which
> >> would
> >>> provide a container for users who want to move to the new
> "incompatible"
> >>> Jakarta specifications.
> >>>
> >>> This way, there's an appropriate container for everyone. Mark Struberg
> >>> proposed more elaborate strategies using classloader tricks on the ASF
> >>> members list, but I'm not sure this is even needed for Tomcat.
> >>>
> >>> Overall, the impact for Tomcat seems rather minimal given the maturity
> of
> >>> Tomcat and its expected support lifecycle for 9.x.
> >>>
> >>> Comments ?
> >>
> >> I think it is good we are thinking about options but too early to settle
> >> on any one solution. The solution we adopt is going to be largely
> >> dependent on what the API projects at Eclipse decide to do.
> >>
> >> Rather than announcing a solution, how about we announce that we will
> >>
> >
> > I agree, it is too early to decide and announce. Still, discussion is
> fine
> > (IMO) and unless the announced Jakarta change ends up not happening.
> We'll
> > indeed see what happens at Jakarta.
> >
> >
> >> continue to support the javax.* APIS (Servlet 4.0, JSP 2.3, EL 3.0,
> >> WebSocket 1.1 and JASPIC 1.1) until at least 31 Dec 2030*. Note: that
> >> means supporting all the older versions of those specs as well. Exactly
> >> how we do that is TBD. Extending Tomcat 9 support to the end of 2030 is
> >> just one possible option.
> >>
> >
> > +1, I was also thinking about "2030 at least" when I wrote "forever"
> > because it makes for a nice impressive announcement !
> >
> >
> >>
> >> Mark
> >>
> >> * Insert date of choice here. I picked first Tomcat 9 release + 10 years
> >> for typical support period + 5 years extension and rounded to the end of
> >> the year.
> >>
> >
> > Rémy
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: Becoming graalvm friendly?

2019-04-26 Thread Romain Manni-Bucau
Depending the reflection usage you can generate a feature registering all
the classes for reflections, is it predicble and "generable" at build time?
Can lead to a "a bit too big" metadata space but nothing crazy.

here what i used in manual mode for a sample (if it helps):
https://github.com/rmannibucau/docosh/blob/broken-graal-threadlocal/src/main/java/com/github/rmannibucau/docker/compose/cli/svm/Feature_Reflections.java#L35

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 26 avr. 2019 à 11:42, Rémy Maucherat  a écrit :

> On Thu, Apr 25, 2019 at 3:07 PM Rémy Maucherat  wrote:
>
> > On Wed, Apr 24, 2019 at 6:29 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> Awesome news Rémy, thanks for sharing!
> >>
> >
> > Next roadblock is https://github.com/oracle/graal/issues/684
> > It's probably not 100% mandatory but I'd rather have a minimum of
> > flexibility (I'm not a big believer of Java only embedding since
> > configuration can get complex fast and it's harder to maintain long
> term).
> >
> > Feel free to help if you'd like.
> >
>
> Ok, so after configuring reflection to some extent in order to examine the
> behavior, I am now rather confident things might work out eventually.
> I thought the best strategy was to add tracing to Tomcat and have the user
> do a regular run with its config to generate the reflection json. In the
> end, I found that there's a tool to do that already in graal, in the form
> of a jvm agent. I then ran into
> https://github.com/oracle/graal/issues/1194
> (exact same crash trace), not sure about any workaround so I'll wait for
> the issue to be resolved in a future RC.
>
> Rémy
>


Re: Becoming graalvm friendly?

2019-04-24 Thread Romain Manni-Bucau
Awesome news Rémy, thanks for sharing!

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 24 avr. 2019 à 18:06, Rémy Maucherat  a écrit :

> On Thu, Mar 28, 2019 at 3:38 PM Rémy Maucherat  wrote:
>
> > On Wed, Mar 20, 2019 at 4:45 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> Most of the time monitoring is done through a custom exporter in
> practise
> >> based on other impl - sigar, library integration like
> >> hibernate/eclipselinks ones, metrics, microprofile etc... -  and JMX is
> >> not
> >> then used - not judging it is good, bad, lack of knowledge or not, just
> >> saying what i see.
> >> Now I'm happy if JMX is made graal compatible. From what I saw, mainly
> the
> >> MBeanServer and Notifier (through the hierarchy it goes until that point
> >> in
> >> the JVM in standard mbeans) are blocking the compilation. I'm pretty
> sure
> >> these parts of Tomcat can be extracted in a particular class and then
> >> substrated which would make it graal compatible probably.
> >>
> >
> > Ok, so I had a (quick) look, and this doesn't seem to be something that
> is
> > adapted to Tomcat at this time.
> >
> > Steps:
> > - I built the embedded packaging here
> > https://github.com/apache/tomcat/tree/master/res/tomcat-maven
> > - It produces a standalone jar in target/tomcat-maven-1.0.jar
> > - Une the graal tool $GRAALVM/bin/native-image -jar
> > target/tomcat-maven-1.0.jar
> >
> > Produces:
> > Error: No instances are allowed in the image heap for a class that is
> > initialized or reinitialized at image runtime:
> > java.util.logging.SimpleFormatter
> > Detailed message:
> > Error: No instances are allowed in the image heap for a class that is
> > initialized or reinitialized at image runtime:
> > java.util.logging.SimpleFormatter
> > Trace: object java.util.logging.ConsoleHandler
> > object java.lang.Object[]
> > object java.util.concurrent.CopyOnWriteArrayList
> > object java.util.logging.LogManager$RootLogger
> > object java.util.logging.Logger
> > object org.apache.juli.logging.DirectJDKLog
> > method
> > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> > Object, boolean)
> > Call path from entry point to
> > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> > Object, boolean):
> > at
> >
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:390)
> > at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:193)
> > at org.apache.catalina.startup.Tomcat.start(Tomcat.java:455)
> > at org.apache.catalina.startup.Tomcat.main(Tomcat.java:1444)
> > at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:152)
> > at
> >
> com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)
> >
> > If you want to work on this, you can (git makes it easy) but it looks a
> > bit daunting at this point (java.util.logging is not supported either ?
> > this is not documented at
> > https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
> ).
> >
>
> https://www.graalvm.org/docs/release-notes/#10-rc16 finally adds
> java.util.logging support, so I can resume investigations.
>
> ../graalvm-ce-1.0.0-rc16/bin/native-image -jar tomcat-maven-1.0.jar
> Build on Server(pid: 1452, port: 38003)*
> [tomcat-maven-1.0:1452]classlist:   2,157.50 ms
> [tomcat-maven-1.0:1452](cap): 801.03 ms
> [tomcat-maven-1.0:1452]setup:   1,746.56 ms
> [tomcat-maven-1.0:1452]   (typeflow):   4,968.17 ms
> [tomcat-maven-1.0:1452](objects):   3,425.07 ms
> [tomcat-maven-1.0:1452]   (features): 176.88 ms
> [tomcat-maven-1.0:1452] analysis:   8,816.22 ms
> [tomcat-maven-1.0:1452] universe: 289.24 ms
> Warning: Reflection method java.lang.Class.forName invoked at
> org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:686)
> Warning: Reflection method java.lang.Class.forName invoked at
>
> org.apache.catalina.core.NamingContextListener.constructEnvEntry(NamingContextListener.java:797)
> Warning: Reflection method java.lang.Class.forName invoked at
>
> org.a

Re: Becoming graalvm friendly?

2019-03-28 Thread Romain Manni-Bucau
You can make it supporting JUL switching the log manager to a simpler
version, AFAIK this is what quarkus does using jboss logging log manager,
guess it shouldn't be that complicated to switch to a lighter version of
JUL one without reload capabilities - still thinking out loud.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 28 mars 2019 à 16:19, Rémy Maucherat  a écrit :

> On Thu, Mar 28, 2019 at 3:43 PM Romain Manni-Bucau 
> wrote:
>
> > In my case - I tried on meecrowave - i just switched using Log SPI the
> impl
> > to something else - custom log4j2 IIRC - and it passed that state until
> it
> > fails on JMX. Then i @Subtitute some code in the Registry and base
> classes
> > but it is literally "monkey patching" Tomcat which is something I really
> > disliked - versus adding a module using a SPI which deactivates some
> > potential code path.
> >
> > My goal is to avoid to fork most of the stack as quarkus did and ensure
> > built-in tomcat can be compiled natively. Using more SPI can be a good
> > option probably and even open more doors to integrators which is never
> bad
> > IMHO.
> >
>
> Well, support for java.util.logging shouldn't be optional (this isn't even
> documented, while JMX is at least documented as not supported). I don't
> think Tomcat support is ever going to happen unless Graal capabilities
> manages to improve, if at all possible, right now it's simply too alien.
>
> Rémy
>


Re: Becoming graalvm friendly?

2019-03-28 Thread Romain Manni-Bucau
In my case - I tried on meecrowave - i just switched using Log SPI the impl
to something else - custom log4j2 IIRC - and it passed that state until it
fails on JMX. Then i @Subtitute some code in the Registry and base classes
but it is literally "monkey patching" Tomcat which is something I really
disliked - versus adding a module using a SPI which deactivates some
potential code path.

My goal is to avoid to fork most of the stack as quarkus did and ensure
built-in tomcat can be compiled natively. Using more SPI can be a good
option probably and even open more doors to integrators which is never bad
IMHO.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 28 mars 2019 à 15:38, Rémy Maucherat  a écrit :

> On Wed, Mar 20, 2019 at 4:45 PM Romain Manni-Bucau 
> wrote:
>
> > Most of the time monitoring is done through a custom exporter in practise
> > based on other impl - sigar, library integration like
> > hibernate/eclipselinks ones, metrics, microprofile etc... -  and JMX is
> not
> > then used - not judging it is good, bad, lack of knowledge or not, just
> > saying what i see.
> > Now I'm happy if JMX is made graal compatible. From what I saw, mainly
> the
> > MBeanServer and Notifier (through the hierarchy it goes until that point
> in
> > the JVM in standard mbeans) are blocking the compilation. I'm pretty sure
> > these parts of Tomcat can be extracted in a particular class and then
> > substrated which would make it graal compatible probably.
> >
>
> Ok, so I had a (quick) look, and this doesn't seem to be something that is
> adapted to Tomcat at this time.
>
> Steps:
> - I built the embedded packaging here
> https://github.com/apache/tomcat/tree/master/res/tomcat-maven
> - It produces a standalone jar in target/tomcat-maven-1.0.jar
> - Une the graal tool $GRAALVM/bin/native-image -jar
> target/tomcat-maven-1.0.jar
>
> Produces:
> Error: No instances are allowed in the image heap for a class that is
> initialized or reinitialized at image runtime:
> java.util.logging.SimpleFormatter
> Detailed message:
> Error: No instances are allowed in the image heap for a class that is
> initialized or reinitialized at image runtime:
> java.util.logging.SimpleFormatter
> Trace: object java.util.logging.ConsoleHandler
> object java.lang.Object[]
> object java.util.concurrent.CopyOnWriteArrayList
> object java.util.logging.LogManager$RootLogger
> object java.util.logging.Logger
> object org.apache.juli.logging.DirectJDKLog
> method
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> Object, boolean)
> Call path from entry point to
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> Object, boolean):
> at
>
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:390)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:193)
> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:455)
> at org.apache.catalina.startup.Tomcat.main(Tomcat.java:1444)
> at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:152)
> at
>
> com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)
>
> If you want to work on this, you can (git makes it easy) but it looks a bit
> daunting at this point (java.util.logging is not supported either ? this is
> not documented at
> https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md ).
>
> Rémy
>


Re: Becoming graalvm friendly?

2019-03-20 Thread Romain Manni-Bucau
Le mer. 20 mars 2019 à 15:06, Rémy Maucherat  a écrit :

> On Tue, Mar 19, 2019 at 4:52 PM Romain Manni-Bucau 
> wrote:
>
> > Hi Rémy, well there are two topics here:
> >
> > 1. how to run tomcat without all that JMX stuff - in Meecrowave for
> > instance we deactivate it by default since in 80% of the usages it is not
> > used - so I think it is a valid option to make it easily deactivable and
> if
> > done well enough it would be easy to "subtrate" the code through svm
> (from
> > graal project) which enable to kind of monkey patch an app (so it should
> be
> > very localized otherwise the maintenance is just hell)
> >
>
> JMX does all the Tomcat monitoring (JVM + container), including also the
> monitoring in cloud environments (with Jolokia and Prometheus). So it is
> difficult for me to understand why it's a such good idea for users to
> remove it. It's quite a bit of work too.
>

Most of the time monitoring is done through a custom exporter in practise
based on other impl - sigar, library integration like
hibernate/eclipselinks ones, metrics, microprofile etc... -  and JMX is not
then used - not judging it is good, bad, lack of knowledge or not, just
saying what i see.
Now I'm happy if JMX is made graal compatible. From what I saw, mainly the
MBeanServer and Notifier (through the hierarchy it goes until that point in
the JVM in standard mbeans) are blocking the compilation. I'm pretty sure
these parts of Tomcat can be extracted in a particular class and then
substrated which would make it graal compatible probably.



>
>
> > 2. graalvm will get more and more support for these parts but I guess
> > tomcat could be less coupled to JMX - in terms of code path - which would
> > also solve the issue.
> >
> > Finally on the url handler part, it is plain useless in native mode so
> > being able to move that URL.setXXX in a static class we would substrate
> by
> > a noop can be worth it too.
> >
> > Hope it makes some sense.
> >
>
> Rémy
>
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 19 mars 2019 à 16:38, Rémy Maucherat  a écrit :
> >
> > > On Sun, Mar 10, 2019 at 6:24 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Hi guys,
> > > >
> > > > Anyone got a look to graalvm native-image tool?
> > > > Tomcat does not work OOTB due to its JMX wide usage - all is not
> > > > implemented in graalvm native scope. That said most of this code is
> not
> > > > really used by Tomcat and can be dropped while keeping Tomcat - at
> > least
> > > > embedded - running. The other hit issue is the URL handler usage.
> > > >
> > > > So concretely - and without entering into the details at that early
> > > stage,
> > > > ensuring TomcatURLStreamHandlerFactory does not use URL custom
> factory
> > > > registration (constructor) and Registry/MBeanUtils don't rely on
> > > > MBeanServer loading directly would be a first step to be able native
> > > > images. To test it I @Substitute them with substrate API but it
> > requires
> > > to
> > > > fork some part of Tomcat which is not desired at all on my side.
> > > >
> > > > This is just the first step since, if you want to keep all features,
> > you
> > > > will need to create a json with the reflection metadata for some
> > features
> > > > but at least these two "changes" would enable to run native-image
> > > > successfully.
> > > >
> > > > Overall this mail does not intend to speak of "fix" yet but only
> mainly
> > > > intend to ask two questions:
> > > >
> > > > 1. any existing status on graalvm native image support I would have
> > > missed?
> > > > 2. any will to work in that direction in the community? (graalvm is
> > still
> > > > very young and lack several features to really embrace java ecosystem
> > so
> > > > can be fair to say "later")
> > > >
> > >
> > > Well, the said features are quite useful/nice/etc, and I haven't been
> > > looking at native images. Any real concrete plan to improve things
> > without
> > > removing useful items ?
> > >
> > > Rémy
> > >
> >
>


Re: Becoming graalvm friendly?

2019-03-19 Thread Romain Manni-Bucau
Hi Rémy, well there are two topics here:

1. how to run tomcat without all that JMX stuff - in Meecrowave for
instance we deactivate it by default since in 80% of the usages it is not
used - so I think it is a valid option to make it easily deactivable and if
done well enough it would be easy to "subtrate" the code through svm (from
graal project) which enable to kind of monkey patch an app (so it should be
very localized otherwise the maintenance is just hell)
2. graalvm will get more and more support for these parts but I guess
tomcat could be less coupled to JMX - in terms of code path - which would
also solve the issue.

Finally on the url handler part, it is plain useless in native mode so
being able to move that URL.setXXX in a static class we would substrate by
a noop can be worth it too.

Hope it makes some sense.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 19 mars 2019 à 16:38, Rémy Maucherat  a écrit :

> On Sun, Mar 10, 2019 at 6:24 PM Romain Manni-Bucau 
> wrote:
>
> > Hi guys,
> >
> > Anyone got a look to graalvm native-image tool?
> > Tomcat does not work OOTB due to its JMX wide usage - all is not
> > implemented in graalvm native scope. That said most of this code is not
> > really used by Tomcat and can be dropped while keeping Tomcat - at least
> > embedded - running. The other hit issue is the URL handler usage.
> >
> > So concretely - and without entering into the details at that early
> stage,
> > ensuring TomcatURLStreamHandlerFactory does not use URL custom factory
> > registration (constructor) and Registry/MBeanUtils don't rely on
> > MBeanServer loading directly would be a first step to be able native
> > images. To test it I @Substitute them with substrate API but it requires
> to
> > fork some part of Tomcat which is not desired at all on my side.
> >
> > This is just the first step since, if you want to keep all features, you
> > will need to create a json with the reflection metadata for some features
> > but at least these two "changes" would enable to run native-image
> > successfully.
> >
> > Overall this mail does not intend to speak of "fix" yet but only mainly
> > intend to ask two questions:
> >
> > 1. any existing status on graalvm native image support I would have
> missed?
> > 2. any will to work in that direction in the community? (graalvm is still
> > very young and lack several features to really embrace java ecosystem so
> > can be fair to say "later")
> >
>
> Well, the said features are quite useful/nice/etc, and I haven't been
> looking at native images. Any real concrete plan to improve things without
> removing useful items ?
>
> Rémy
>


Re: [VOTE] Release Apache Tomcat 9.0.17

2019-03-18 Thread Romain Manni-Bucau
+1 (non binding), tested in custom apps and meecrowave

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 15 mars 2019 à 09:38, Keiichi Fujino  a écrit :

> 2019年3月14日(木) 3:23 Mark Thomas :
>
> > The proposed Apache Tomcat 9.0.17 release is now available for voting.
> >
> > The major changes compared to the 9.0.16 release are:
> >
> > - The APR/Native connector now supports both OpenSSL and JSSE TLS
> >   configuration syntax (NIO and NIO2 already support this)
> >
> > - Various improvements to NIO2
> >
> > - Various fixes for HTTP/2 push requests
> >
> >
> > Along with lots of other bug fixes and improvements.
> >
> > For full details, see the changelog:
> > https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
> >
> > It can be obtained from:
> > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.17/
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1205/
> > The tag is:
> > https://github.com/apache/tomcat/tree/9.0.17
> > 25d7c99e8c44a41a08ba85ccaba3cfec6af9c801
> >
> > The proposed 9.0.17 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 9.0.17
> >
> >
> +1
> Tested on some test application (enable session replication).
>
>
>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>
> --
> Keiichi.Fujino
>


Re: War Maven artifacts deployment

2019-03-17 Thread Romain Manni-Bucau
Le dim. 17 mars 2019 à 19:35, Gaël Lalire  a
écrit :

>
> Le 17 mars 2019 à 16:22, Romain Manni-Bucau  a
> écrit :
>
> > Le dim. 17 mars 2019 à 14:51, Gaël Lalire  a
> > écrit :
> >
> >>
> >> Le 17 mars 2019 à 13:21, Romain Manni-Bucau  a
> >> écrit :
> >>
> >>> Le dim. 17 mars 2019 à 12:56, Gaël Lalire 
> a
> >>> écrit :
> >>>
> >>>> Hello Romain,
> >>>>
> >>>> I already explained why I do not want to give file or jar:file URL,
> even
> >>>> if I have it.
> >>>> Maven resolver is giving me File, I create a VestigeJar from it
> >>>>
> >>
> https://gaellalire.fr/gitlab/vestige/vestige.spi.resolver/blob/master/src/main/java/fr/gaellalire/vestige/spi/resolver/VestigeJar.java
> >>>> I also create a mvn: URL accessible through getCodeBase however it is
> >>>> only for policy permission you should not use openStream on it
> >> (although I
> >>>> had to make it possible to get BouncyCastle working).
> >>>>
> >>>
> >>> I get that but it also can conflict with other resolver using mvn:,
> open
> >>> new security issues and break some libs - speaking having dropped a lib
> >>> doing exactly that at work for all these reasons.
> >>
> >> mvn: was implemented two weeks before, it is only for ProtectionDomain.
> >> And ProtectionDomain is used by almost no library.
> >> VestigeClassloader send vrt: URL. These ones start with / and does not
> >> break libraries relying on context URL.
> >> It will break those expecting jar:file URL though but Java9 with its
> jrt:
> >> URL will also break them, so I don't care.
> >>
> >
> > Paxurl uses it for a long tile. Also jrt is different cause excluded from
> > most scanner - it is only the jvm - whereas your jars are not excluded
> and
> > scanning will fail. Check out spring, weld, openwebbeans etc...
> >
>
> I mean implemented in Vestige. I use a sub format of Paxurl (no
> repository, no version range).
> Also I could use vmvn: instead, as I said it's only for code base URL.
>
> Scanning in openwebbeans will not work because it is expecting an
> URLClassLoader or using java.class.path property.
> Java9 is not providing URLClassLoader ... these scanners must evolve.
>


No, it uses getResources to find root urls then unpack the url to find the
folders and jars to scan.

Look jboss vfs, it has extensions in all frameworks for that and this is
why this kind of impl will not match much app until it becomes mainstream
(or $$) IMHO.


> I see 2 types of scanning :
> - hinted one -> for example with beans.xml. These ones can be written to
> be working only using clean Java (context URL will do the job).
>

You still need to scan the jar even with a beans.xml

- blind one -> searching for annotations in all jars. These ones have to
> hack the system to find all jars (there is no listAllJar in classloader),
> they should provide an API so its container can give it the jar list, and
> by jar list I think of  something like (InputStream, JarName, JarSize)
> rather than a JarFile or URL.
>


This is what cdi is and what sole spring config does.


> >
> >
> >>>
> >>>
> >>>> I think that SecureClassLoader is not secure enough because it only
> >> checks
> >>>> classes not resources.
> >>>> In a world using XML to create, configure and link instances (Spring),
> >> it
> >>>> is terrible to let resources unchecked.
> >>>>
> >>>> That's also why VestigeClassLoader#getResource is returning vrt: URL
> and
> >>>> not jar:file: URL.
> >>>>
> >>>
> >>> Classloaders generally check in their own calls, not in the resource
> >>> itself. Can' t you validate the resource before actually reasing it?
> >> Sounds
> >>> saner and closer to security manager common configs.
> >>
> >> Yes but it is not secure even with read lock.
> >> The read lock is on the file not the path. You can remove and even
> replace
> >> the file while the read lock is still here.
> >> So my check succeeds, I give a jar:file URL then the file is replaced,
> the
> >> jar:file is open and get the new file (hacked one).
> >>
> >
> > Sounds like you want to implement a jvm filesystem and not a new url
> > handler explained this way otherwise you still have this issue with other
> > concurrent accesses.
&g

Re: War Maven artifacts deployment

2019-03-17 Thread Romain Manni-Bucau
Le dim. 17 mars 2019 à 14:51, Gaël Lalire  a
écrit :

>
> Le 17 mars 2019 à 13:21, Romain Manni-Bucau  a
> écrit :
>
> > Le dim. 17 mars 2019 à 12:56, Gaël Lalire  a
> > écrit :
> >
> >> Hello Romain,
> >>
> >> I already explained why I do not want to give file or jar:file URL, even
> >> if I have it.
> >> Maven resolver is giving me File, I create a VestigeJar from it
> >>
> https://gaellalire.fr/gitlab/vestige/vestige.spi.resolver/blob/master/src/main/java/fr/gaellalire/vestige/spi/resolver/VestigeJar.java
> >> I also create a mvn: URL accessible through getCodeBase however it is
> >> only for policy permission you should not use openStream on it
> (although I
> >> had to make it possible to get BouncyCastle working).
> >>
> >
> > I get that but it also can conflict with other resolver using mvn:, open
> > new security issues and break some libs - speaking having dropped a lib
> > doing exactly that at work for all these reasons.
>
> mvn: was implemented two weeks before, it is only for ProtectionDomain.
> And ProtectionDomain is used by almost no library.
> VestigeClassloader send vrt: URL. These ones start with / and does not
> break libraries relying on context URL.
> It will break those expecting jar:file URL though but Java9 with its jrt:
> URL will also break them, so I don't care.
>

Paxurl uses it for a long tile. Also jrt is different cause excluded from
most scanner - it is only the jvm - whereas your jars are not excluded and
scanning will fail. Check out spring, weld, openwebbeans etc...



> >
> >
> >> I think that SecureClassLoader is not secure enough because it only
> checks
> >> classes not resources.
> >> In a world using XML to create, configure and link instances (Spring),
> it
> >> is terrible to let resources unchecked.
> >>
> >> That's also why VestigeClassLoader#getResource is returning vrt: URL and
> >> not jar:file: URL.
> >>
> >
> > Classloaders generally check in their own calls, not in the resource
> > itself. Can' t you validate the resource before actually reasing it?
> Sounds
> > saner and closer to security manager common configs.
>
> Yes but it is not secure even with read lock.
> The read lock is on the file not the path. You can remove and even replace
> the file while the read lock is still here.
> So my check succeeds, I give a jar:file URL then the file is replaced, the
> jar:file is open and get the new file (hacked one).
>

Sounds like you want to implement a jvm filesystem and not a new url
handler explained this way otherwise you still have this issue with other
concurrent accesses.


> >
> >
> >> The easiest way to implements War Maven artifacts deployment is to use
> >> directly Maven resolver API and give file or jar:file URL to Tomcat.
> >>
> >
> > Or war: since tomcat supports it.
>
> Of course
>
> >
> >
> >
> >> I could have done that, but guess what, I'm willing to give TomEE EAR
> >> Maven artifacts deployment after Tomcat.
> >> In the TomEE my company uses there is a horrible CLASSPATH because they
> >> wanted to avoid RMI call between EAR.
> >> That is where Vestige is useful, it allows to choose which jar(s) should
> >> be shared without any global impact.
> >>
> >
> > Hmm, you use a tomee? Did you check jars.txt? Can be worth pinging tomee
> > about it cause all is there to do it afaik.
>
> Thanks for the pointer, I will check it because I really don't like global
> CLASSPATH.
> For my business case it will almost certainly work, however I'm pretty
> sure it has not the power of Vestige.
> I don't know if you chose to create one classloader grouping all jars in
> jar.txt in which case you will have issues when a library is deployed in 2
> different versions.
> Or if you chose to create one classloader per entry in jar.txt in which
> case the jar will be missing its dependencies unless you expect them to be
> in MANIFEST.MF.
>
> In Maven repositories Class-Path is generally not set in MANIFEST.MF.
>


Jars.txt is just a way to add jars in the classloader it is present in -
webapp or ear lib one - without putting the files physically there. It is
close to old configurable tolcat classloader and new webresource
abstraction which can do it as well.


> >
> >
> >> You have 3 scopes and 2 modes in Vestige.
> >> Mode CLASSPATH is creating one classloader with all jars inside, not
> easy
> >> to share.
> >> Mode FIXED_DEPENDENCIES is creating one classloader per jar, but implies
> >> some go

Re: War Maven artifacts deployment

2019-03-17 Thread Romain Manni-Bucau
Le dim. 17 mars 2019 à 12:56, Gaël Lalire  a
écrit :

> Hello Romain,
>
> I already explained why I do not want to give file or jar:file URL, even
> if I have it.
> Maven resolver is giving me File, I create a VestigeJar from it
> https://gaellalire.fr/gitlab/vestige/vestige.spi.resolver/blob/master/src/main/java/fr/gaellalire/vestige/spi/resolver/VestigeJar.java
> I also create a mvn: URL accessible through getCodeBase however it is
> only for policy permission you should not use openStream on it (although I
> had to make it possible to get BouncyCastle working).
>

I get that but it also can conflict with other resolver using mvn:, open
new security issues and break some libs - speaking having dropped a lib
doing exactly that at work for all these reasons.


> I think that SecureClassLoader is not secure enough because it only checks
> classes not resources.
> In a world using XML to create, configure and link instances (Spring), it
> is terrible to let resources unchecked.
>
> That's also why VestigeClassLoader#getResource is returning vrt: URL and
> not jar:file: URL.
>

Classloaders generally check in their own calls, not in the resource
itself. Can' t you validate the resource before actually reasing it? Sounds
saner and closer to security manager common configs.


> The easiest way to implements War Maven artifacts deployment is to use
> directly Maven resolver API and give file or jar:file URL to Tomcat.
>

Or war: since tomcat supports it.



> I could have done that, but guess what, I'm willing to give TomEE EAR
> Maven artifacts deployment after Tomcat.
> In the TomEE my company uses there is a horrible CLASSPATH because they
> wanted to avoid RMI call between EAR.
> That is where Vestige is useful, it allows to choose which jar(s) should
> be shared without any global impact.
>

Hmm, you use a tomee? Did you check jars.txt? Can be worth pinging tomee
about it cause all is there to do it afaik.


> You have 3 scopes and 2 modes in Vestige.
> Mode CLASSPATH is creating one classloader with all jars inside, not easy
> to share.
> Mode FIXED_DEPENDENCIES is creating one classloader per jar, but implies
> some good practice (use of context classloader for example).
>
> After setting FIXED_DEPENDENCIES you have to use the PLATFORM scope to get
> it shared, this scope implies some other good practice (static field
> immutable for example).
>
> About memory issue, I don't get your point.
> I will not keep all jars content in memory I will use shared locks (fcntl)
> to keep the content of RandomAccessFile the way it was when I checked it.
> VestigeJar#open will create an InputStream reading from this locked
> RandomAccessFile.
>

Oki but then you are in jar:file mode ;)


> Regards,
> Gaël Lalire
>
> Le 17 mars 2019 à 10:17, Romain Manni-Bucau  a
> écrit :
>
> Hi Gaël,
>
> In Tomee we plugged before to enrich the classloader and then tomcat -and
> other libs - works normally using jar urls.
>
> Cant you use a listener to do that and convert m2 urls to plain jar files -
> at the end it is local files i guess otherwise you generally consume too
> much memory to be prod friendly?
>
>
> Le dim. 17 mars 2019 à 09:46, Gaël Lalire  a
> écrit :
>
> Hello Tomcat developers,
>
> I made a software to enable update of Java applications named Vestige.
> To achieve that, Vestige use Maven, downloading Maven artifacts and
> creating classloaders linked with jar inside m2 repository.
>
> I made it to update my IBM notes connector (POP access provider).
>
> The fact it is downloading Maven artifacts makes the assembly
> (jar-with-dependencies of maven-assembly-plugin) of the connector not
> mandatory.
>
> In a business project I saw that war artifacts were filling the
> repository, so they had to regularly remove older version from it.
> I thought it would be great if we could remove the WEB-INF/lib from the
> published war and still be able to deploy it with Tomcat.
>
> I did that, the WebResource API helps me a lot.
> However I had to disable JarScanner API (tld & fragments) because it's
> using JarURLConnection and my API is not providing jar:file: nor file: URL.
> My API won't provide them because I want to be able to check a pgp
> signature before any use of an artifact in m2 repository.
> If I check the signature and send a jar:file: or file: URL it won't be
> secure because there is no way to prevent the modification of the file
> after the check.
> To be secure I will probably lock the file for reading, then check the
> signature, and give locked InputStream.
>
> I would like you to change the JarScanner API/Impl so it won't rely on
> JarURLConnection anymore (maybe WebResource ?).
> Also I have to replace some Tomcat classes (
&

Re: War Maven artifacts deployment

2019-03-17 Thread Romain Manni-Bucau
Hi Gaël,

In Tomee we plugged before to enrich the classloader and then tomcat -and
other libs - works normally using jar urls.

Cant you use a listener to do that and convert m2 urls to plain jar files -
at the end it is local files i guess otherwise you generally consume too
much memory to be prod friendly?


Le dim. 17 mars 2019 à 09:46, Gaël Lalire  a
écrit :

> Hello Tomcat developers,
>
> I made a software to enable update of Java applications named Vestige.
> To achieve that, Vestige use Maven, downloading Maven artifacts and
> creating classloaders linked with jar inside m2 repository.
>
> I made it to update my IBM notes connector (POP access provider).
>
> The fact it is downloading Maven artifacts makes the assembly
> (jar-with-dependencies of maven-assembly-plugin) of the connector not
> mandatory.
>
> In a business project I saw that war artifacts were filling the
> repository, so they had to regularly remove older version from it.
> I thought it would be great if we could remove the WEB-INF/lib from the
> published war and still be able to deploy it with Tomcat.
>
> I did that, the WebResource API helps me a lot.
> However I had to disable JarScanner API (tld & fragments) because it's
> using JarURLConnection and my API is not providing jar:file: nor file: URL.
> My API won't provide them because I want to be able to check a pgp
> signature before any use of an artifact in m2 repository.
> If I check the signature and send a jar:file: or file: URL it won't be
> secure because there is no way to prevent the modification of the file
> after the check.
> To be secure I will probably lock the file for reading, then check the
> signature, and give locked InputStream.
>
> I would like you to change the JarScanner API/Impl so it won't rely on
> JarURLConnection anymore (maybe WebResource ?).
> Also I have to replace some Tomcat classes (
> https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige/commit/67dea6054c9da30047ebba3e9a376fa44b544f13)
> that is not future proof.
> Could you provide some extension(s) so I could do the same thing without
> replacing any Tomcat class ?
>
> Hoping that you get interested enough to help me improve the Maven
> artifact deployment support, I send you my best regards.
>
> PS:
> You can test the vwar, an xml which describes the war to deploy
> (essentially repository URL, groupId, artifactId, version), deployment by :
> - download (https://gaellalire.fr/vestige/) & install & run Vestige
> - go to http://localhost:8480/
> - click on install
> - write "tomcat" in repository application name
> - write "8.0.32" in repository application version
> - write "tc" in local application name
> - click install button
> - click play button
> - go to http://localhost:8080/mywar/hello (servlet test) and
> http://localhost:8080/mywar/hi.jsp?max=5 (jsp test)
>
> The vwar will be at $VESTIGE_BASE/app/tc/webapps/mywar.vwar
> Where $VESTIGE_BASE is :
> - $HOME/Vestige on Mac OS X
> - $HOME/vestige on Linux
> - %userprofile%\Vestige on Windows
> - the place you unzip the file if you chose to install the standalone
> version (a ZIP file)
>
> You can also see it at
> https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige/blob/master/installer/src/main/resources/mywar.vwar
>
> tomcat_vestige sources at
> https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige
> tomcat_vestige descriptor at
> https://gaellalire.fr/vestige/repository/tomcat/tomcat-8.0.32.xml
> mywar sources at https://gaellalire.fr/gitlab/vestige_app/mywar (its pom
> https://gaellalire.fr/gitlab/vestige_app/mywar/blob/master/pom.xml
> excludes lib folder)
>
>


Becoming graalvm friendly?

2019-03-10 Thread Romain Manni-Bucau
Hi guys,

Anyone got a look to graalvm native-image tool?
Tomcat does not work OOTB due to its JMX wide usage - all is not
implemented in graalvm native scope. That said most of this code is not
really used by Tomcat and can be dropped while keeping Tomcat - at least
embedded - running. The other hit issue is the URL handler usage.

So concretely - and without entering into the details at that early stage,
ensuring TomcatURLStreamHandlerFactory does not use URL custom factory
registration (constructor) and Registry/MBeanUtils don't rely on
MBeanServer loading directly would be a first step to be able native
images. To test it I @Substitute them with substrate API but it requires to
fork some part of Tomcat which is not desired at all on my side.

This is just the first step since, if you want to keep all features, you
will need to create a json with the reflection metadata for some features
but at least these two "changes" would enable to run native-image
successfully.

Overall this mail does not intend to speak of "fix" yet but only mainly
intend to ask two questions:

1. any existing status on graalvm native image support I would have missed?
2. any will to work in that direction in the community? (graalvm is still
very young and lack several features to really embrace java ecosystem so
can be fair to say "later")


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Re: Proposed change to STREAMS_DROP_EMPTY_MESSAGES system property

2019-02-05 Thread Romain Manni-Bucau
As an user c sounds ok. Worse case maybe keep it for 1 release with some
comm to have time to migrate if relevant.

Le mar. 5 févr. 2019 à 20:10, Rémy Maucherat  a écrit :

> On Tue, Feb 5, 2019 at 7:58 PM Mark Thomas  wrote:
>
> > Hi,
> >
> > org.apache.tomcat.websocket.STREAMS_DROP_EMPTY_MESSAGES
> >
> > The above system property was added to address an issue with Tomcat's
> > WebSocket implementation not passing the TCK. Tomcat was sending empty
> > messages when the TCK wasn't expecting a message to be sent.
> >
> > Now that we have access to the TCK I have been able to track down the
> > root cause of these failures.
> >
> > The root cause is this code in WsRemoteEndpointImplBase:
> > ...
> > } else if (encoder instanceof Encoder.TextStream) {
> > try (Writer w = getSendWriter()) {
> > ((Encoder.TextStream) encoder).encode(obj, w);
> > }
> > }
> >
> > The call to getSendWriter() triggers the state change that a write has
> > started. Then the exception is thrown and because of the
> > try-with-resources close() is called. That triggers the end of message
> > state change hence a zero length message is written.
> >
> > The STREAMS_DROP_EMPTY_MESSAGES causes all empty messages (not just in
> > this error case) to be dropped.
> >
> > I'm currently thinking that handling of this error case and
> > STREAMS_DROP_EMPTY_MESSAGES should be decoupled. The idea is that, in
> > the above case, obtaining the Writer is delayed until the encoder tries
> > to write bytes.
> >
> > If the above change is implemented then what should be happen to
> > STREAMS_DROP_EMPTY_MESSAGES?
> > a) keep it as is
> > b) deprecate it and remove it in 10.x
> > c) remove it now
> >
> > I'm leaning towards b)
> >
>
> You could probably do c) as the only purpose was to stick to the TCK
> behavior. When there is no spec, the TCK is supposed to be the referee (and
> I don't really see why empty messages are useful).
>
> Rémy
>
>
> >
> > Thoughts?
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>


Re: System properties: JVM launch versus catalina.properties

2018-12-30 Thread Romain Manni-Bucau
except the name, if run in the same JVM thantomcat it is too late anyway

so 2 options are either to not do it or preprocess it IMHO

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le sam. 29 déc. 2018 à 13:25, Martin Grigorov  a
écrit :

> Hi Igal,
>
> I am not sure this is a good idea.
> Usually .properties.default files are used as sample files. And one has to
> rename them to .properties to make use of them.
> IMO your suggestion will be confusing for people used to this approach.
>
> Regards,
> Martin
>
> On Sat, Dec 29, 2018 at 2:11 AM Igal Sapir  wrote:
>
> > Chris,
> >
> > On 12/28/2018 7:07 AM, Christopher Schultz wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > All,
> > >
> > > Someone asked this question on SO recently:
> > >
> https://stackoverflow.com/questions/53921375/tomcat-overriding-catalina-
> > > properties-from-commandline/53952396#53952396
> > >
> > > TLDR: this person wants to set system properties in
> > > catalina.properties but be able to "override" those from the
> command-lin
> > > e.
> > >
> > > The fix would be trivial: just don't clobber the value of any existing
> > > system property in CatalinaProperties when copying the properties from
> > > the file to the live system properties.
> > >
> > > I'm wondering if anyone can think of any security issues with doing
> > > that. Presumably, if a user can launch Tomcat, they can set system
> > > properties. However, it's possible that a user might have the right to
> > > *launch* Tomcat, but not reconfigure it (e.g. read-only
> > > catalina.properties).
> > >
> > > That could easily be solved by using a catalina.properties-only
> > > setting like "catalina.properties.noclobber.system.properties=true" or
> > > something like that.
> >
> > How about adding an optional file named "catalina.properties.default",
> > which will be read before "catalina.properties", and whose values will
> > be set only if no corresponding keys are set in System properties?  e.g.
> >
> > # file catalina.properties.default
> > tomcat.port=8080
> >
> > Can be overridden with `-Dtomcat.properties=`, but
> >
> > # file catalina.properties
> > tomcat.host=localhost
> >
> > Can not be overridden, as it is now.
> >
> > Users will know that if they place a value in the default file, it could
> > be overridden with a System property.
> >
> > This should be fairly simple and I can implement it if it sounds like a
> > good idea.
> >
> > Igal
> >
> >
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>


Re: System properties: JVM launch versus catalina.properties

2018-12-28 Thread Romain Manni-Bucau
Except if you call java -jar catalina_home/lib/prdtartup.jar which creates
a temp file used instead of setenv (just a generator) so you can read it in
plain java and launch tomcat only later to ensure it respects all props.
This small main would do anything except suceed or fail.


Le ven. 28 déc. 2018 19:41, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Romain,
>
> On 12/28/18 10:10, Romain Manni-Bucau wrote:
> > Hi
> >
> > As a user it is nicer to be able to set all system properties in
> > the same place and catalina code is too late for some of them like
> > log manager. Why not having a conf/system.properties handled by
> > scripts and in fallback by Tomcat (embedded case)? Would just be a
> > more natural way to write it than setenv.
>
> Shell-script processing of .properties files will likely be hairy.
>
> I have seen systems like install4j which use "vmoptions" files which
> essentially allow you to set system properties without actually typing
> a huge line of text with "-Dkey=value" but instead have "key=value" on
> separate lines. I suspect they do not adhere to the full "properties"
> specification (e.g. ignorable whitespace, line-continuation, \u
> character processing, etc.).
>
> It we defined something that "wasn't a properties file, but looks like
> a properties file", then maybe it would be okay. It could be processed
> easily like this on systems with proper scripting capabilities:
>
> sysprops=$( echo $( sed -e 's/^/"-D/' -e 's/$/"/'
> conf/system.not-properties $) $)
>
> ...
>
> java [script properties] $sysprops
>
> You still have the awful problem of quoting, though.
>
> - -chris
>
> > Le 28 déc. 2018 16:07, "Christopher Schultz"
> >  a écrit :
> >
> > All,
> >
> > Someone asked this question on SO recently:
> > https://stackoverflow.com/questions/53921375/tomcat-overriding-catalin
> a-
> >
> >
> properties-from-commandline/53952396#53952396
> > <https://stackoverflow.com/questions/53921375/tomcat-overriding-catali
> na-properties-from-commandline/53952396#53952396
> <https://stackoverflow.com/questions/53921375/tomcat-overriding-catalina-properties-from-commandline/53952396#53952396>
> >
> >
> >  TLDR: this person wants to set system properties in
> > catalina.properties but be able to "override" those from the
> > command-lin e.
> >
> > The fix would be trivial: just don't clobber the value of any
> > existing system property in CatalinaProperties when copying the
> > properties from the file to the live system properties.
> >
> > I'm wondering if anyone can think of any security issues with
> > doing that. Presumably, if a user can launch Tomcat, they can set
> > system properties. However, it's possible that a user might have
> > the right to *launch* Tomcat, but not reconfigure it (e.g.
> > read-only catalina.properties).
> >
> > That could easily be solved by using a catalina.properties-only
> > setting like "catalina.properties.noclobber.system.properties=true"
> > or something like that.
> >
> > What does everyone think?
> >
> > Thanks, -chris
> >
> > -
> >
> >
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwmblsACgkQHPApP6U8
> pFj/0RAAt+e4UDhtWZ7bHLGfNkXEAiO0hAor8MOHINn8f99Aeu9LbD0odH9ruDzy
> B0s3Yhyg49PgUIxZbqqCPFMME83L/Fx//YT2VRfgvxjM3BvWCtGIRAqx8NZpbbqX
> fbQYxdc7DWkIr3/5CQ3BsVPZu9HdhmoOTeFMMPvRWbW4LqRfkQXyNdAd308i2a6M
> 0N0RQED7gyEAPfMKaXOLX+AoSApAnGG7F4c+jr8l6P8U0VVRnX+TFWrjBmEt2iWx
> z0dtH0AZJlf2QwEq48g1qSaB7vUo9w9WPx57YYB3Zv1kcGPGF1h6Acy7S3vqEVgo
> ZafsK5PzyVycXd37P5EcQ1Yh1yELVS0Zdl3qfGxllX6jDSpb6cMcMUbC6buMpPwG
> Af6WmUCfDThI7Q9Om5MttT73acj/Wcvh1rtYbu6hhjPXZ+uplGJcwBcY1sujC81S
> s389xDL+GVxde31sW6pSVY+OYsdrg1HsqQJeFnmpEDZSjrSgTEsS6hj0dVRkIPCS
> 0k1JPydMD28OGwdoxLIQHYNq9q3uneBDrw+VTcu1Q9RIJcQ5NW8ksoY/GHbYfG18
> lf01sFu28RyAM1kVZYMc2IZlq61opW4w/DPTGChgNpxqx7yD5nfm31lqvAsYKyht
> EXKqCRayn+89KEV3px0UbAeSVQWVD96a12KbYZHF1IEm/eO+a2M=
> =Qoxt
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: System properties: JVM launch versus catalina.properties

2018-12-28 Thread Romain Manni-Bucau
Hi

As a user it is nicer to be able to set all system properties in the same
place and catalina code is too late for some of them like log manager. Why
not having a conf/system.properties handled by scripts and in fallback by
Tomcat (embedded case)? Would just be a more natural way to write it than
setenv.

Le 28 déc. 2018 16:07, "Christopher Schultz" 
a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Someone asked this question on SO recently:
https://stackoverflow.com/questions/53921375/tomcat-overriding-catalina-
properties-from-commandline/53952396#53952396


TLDR: this person wants to set system properties in
catalina.properties but be able to "override" those from the command-lin
e.

The fix would be trivial: just don't clobber the value of any existing
system property in CatalinaProperties when copying the properties from
the file to the live system properties.

I'm wondering if anyone can think of any security issues with doing
that. Presumably, if a user can launch Tomcat, they can set system
properties. However, it's possible that a user might have the right to
*launch* Tomcat, but not reconfigure it (e.g. read-only
catalina.properties).

That could easily be solved by using a catalina.properties-only
setting like "catalina.properties.noclobber.system.properties=true" or
something like that.

What does everyone think?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwmPCQACgkQHPApP6U8
pFgmzRAAnIzALW5ugkGrQl9uHYBz/WrNXISiSc4aqCXzqzlmDAGENO4coRzTe88n
0uFWLVbjembgz78Cbs1+AdjuGxwpMhPb+mWysAB/Rq7iosr00eXOrV64prHjRhCU
pV00Om943PuxegLFQ/O4WW5grWyUUUm7mWBbyadAbs6ZOspnozS9DJnCwxIwTQgz
JY3kRhZq7+lEirtKBdjtbyaDdVn9BXy59wgXa4e6AQ7ESN41S3NM+9AMhFfTP9Ly
12s/Vb9WQa5hpQsJqVUVoHmDYSI3bQs++7LWTr3fIR7+829A8rTvYS4rxvWhUE3O
dXZFHWU4ATU49kCHG0zHpsDBgU4bL611nsh2yJiVj0uGL/+DxjM0B8Z4Cf+XbltL
wXaraK2oh1SQwo6NqzhW/b5MxzVr7aiX1fuM5hOEZfgbTROnTRnP/uEVVnh5q16v
LPY0SSdJJhLcuxQR8m3ZaFaWik3kZ7SCAq3Mt/jFMjVvmhHQ13WWmrHtiDaYhd1l
Eoi9iGS6AHTr66opoqSfYbviRT2fiRRnwmzXXuFX3U9X7gXhUp44CPqiNODtma22
xPNgDKyuWYByILGRigG/B+Wb3Y2cUTCcuSvI3H/l5PoPi35mR24bmJvC8EWkD1HF
5knfa/ZBoGx48YuXnzVUWe95JAnmNrnj/qcdZ4/1ljxd76jCEGQ=
=qES3
-END PGP SIGNATURE-

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


Re: open visibility of JavaClassCacheEntry

2018-12-06 Thread Romain Manni-Bucau
Fair enough, done in https://bz.apache.org/bugzilla/show_bug.cgi?id=62986

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 6 déc. 2018 à 14:32, Mark Thomas  a écrit :

> On 06/12/2018 13:19, Romain Manni-Bucau wrote:
> > Hello Rémy,
> >
> >
> > Le jeu. 6 déc. 2018 à 14:13, Rémy Maucherat  a écrit :
> >
> >> On Thu, Dec 6, 2018 at 11:51 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> Hi guys,
> >>>
> >>> can you make ContextConfig.JavaClassCacheEntry public please? Idea is
> to
> >> be
> >>> able to override ContextConfig and potentially customize
> >> processAnnotations
> >>> methods. Currently it is a pain and it is preventing to upgrade
> >> meecrowave
> >>> and likely tomee to java11+jlink support
> >>>
> >>
> >> Ok, so I had a look at the meecrowave main class after doing my embedded
> >> refactoring and I was a bit horrified by the amount of hacks :) Not that
> >> there were too many options to do the things that were done (some I
> didn't
> >> think were possible), and luckily my changes would have been a very good
> >> help there.
> >>
> >> So here, it looks like a bit scary as well, since JavaClassCacheEntry is
> >> package private (not ok usually), but only instantiated from a private
> >> method (what would you do about that ?). So I'd rather not do that, or
> not
> >> just that, since it would be good to reduce the amount of hacks.
> >>
> >> For starters, I don't like "private" in that kind of class (same with
> >> "final"), I prefer "protected" usually. Shouldn't JavaClassCacheEntry
> be a
> >> non static protected class ?
>
> No objections to making it protected if that helps but I don't see why
> you'd want to make it non-static.
>
> >> About webConfig, I'm not sure. A good way to do it would be to add
> calls to
> >> a few intermediate empty methods in appropriate locations, rather than a
> >> real refactoring.
> >
> > not empty cause here the idea is to reuse an existing scanning and not
> let
> > tomcat scan classes but yes a doScanMagic() would work
> > the part which would be great to reuse is the mapping between bytecode
> (the
> > annotation entry) and the tomcat model (FilterDef etc)
>
> Why don't you suggest a patch? As a rough guideline, please aim for the
> minimally invasive patch the gives you what you need.
>
> Generally adding to the existing API is OK but changing it is not. The
> aim is to minimise the chance of breakage for anyone currently using or
> extending that class directly.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: open visibility of JavaClassCacheEntry

2018-12-06 Thread Romain Manni-Bucau
Hello Rémy,


Le jeu. 6 déc. 2018 à 14:13, Rémy Maucherat  a écrit :

> On Thu, Dec 6, 2018 at 11:51 AM Romain Manni-Bucau 
> wrote:
>
> > Hi guys,
> >
> > can you make ContextConfig.JavaClassCacheEntry public please? Idea is to
> be
> > able to override ContextConfig and potentially customize
> processAnnotations
> > methods. Currently it is a pain and it is preventing to upgrade
> meecrowave
> > and likely tomee to java11+jlink support
> >
>
> Ok, so I had a look at the meecrowave main class after doing my embedded
> refactoring and I was a bit horrified by the amount of hacks :) Not that
> there were too many options to do the things that were done (some I didn't
> think were possible), and luckily my changes would have been a very good
> help there.
>
> So here, it looks like a bit scary as well, since JavaClassCacheEntry is
> package private (not ok usually), but only instantiated from a private
> method (what would you do about that ?). So I'd rather not do that, or not
> just that, since it would be good to reduce the amount of hacks.
>
> For starters, I don't like "private" in that kind of class (same with
> "final"), I prefer "protected" usually. Shouldn't JavaClassCacheEntry be a
> non static protected class ?
>
> About webConfig, I'm not sure. A good way to do it would be to add calls to
> a few intermediate empty methods in appropriate locations, rather than a
> real refactoring.
>

not empty cause here the idea is to reuse an existing scanning and not let
tomcat scan classes but yes a doScanMagic() would work
the part which would be great to reuse is the mapping between bytecode (the
annotation entry) and the tomcat model (FilterDef etc)


>
> Rémy
>


Re: open visibility of JavaClassCacheEntry

2018-12-06 Thread Romain Manni-Bucau
PS: alternative which can be saner would be to split webConfig() in a set
of small protected methods instead of a monolitic block, typically here a
processAnnotations(webXmls) not depending on internals can work

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 6 déc. 2018 à 11:51, Romain Manni-Bucau  a
écrit :

> Hi guys,
>
> can you make ContextConfig.JavaClassCacheEntry public please? Idea is to
> be able to override ContextConfig and potentially customize
> processAnnotations methods. Currently it is a pain and it is preventing to
> upgrade meecrowave and likely tomee to java11+jlink support
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>


open visibility of JavaClassCacheEntry

2018-12-06 Thread Romain Manni-Bucau
Hi guys,

can you make ContextConfig.JavaClassCacheEntry public please? Idea is to be
able to override ContextConfig and potentially customize processAnnotations
methods. Currently it is a pain and it is preventing to upgrade meecrowave
and likely tomee to java11+jlink support

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Re: Problems running TC 7 with Log4J 1.2 and Java 11

2018-11-22 Thread Romain Manni-Bucau
You mean the config in server and libs in common? Only tested with all in
the same loader.

Le jeu. 22 nov. 2018 19:52, Rainer Jung  a écrit :

> Hi Romain, hi all,
>
> are you sure you tried i as I described? Namely loading the config via a
> server.loader path property newly defined in conf/catalina.properties?
> And of course I was using the juli and juli-adapters jar from the 7.0.92
> extras download.
>
> I have another detail to report: it starts working even with Java 11 and
> using the server loader, when i place the log4j.jar and the
> juli-adapters.jar into the server loader instead of the common loader.
> That's interesting, because it was not needed until and including Java
> 10. It worked there by just putting the config into the server loader
> and keeping the log4j and juli-adapters jar in the common loader.
>
> It seems that either for some reason the server loader is no longer
> parent of the common loader or the getResource() call changed behavior
> w.r.t. class loader hierarchies and delegation.
>
> Will debug further.
>
> Regards,
>
> Rainer
>
> Am 22.11.2018 um 18:31 schrieb Romain Manni-Bucau:
> > Hi Rainer,
> >
> > You are right, missed it was set OOTB.
> >
> > BTW, just tested on tomcat 7.0.92 with the log4j (v1.2.17) and its
> > adapter (of the 8.0.53) and java 11.0.1+13-LTS and it works for me
> > (base=home in my test).
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le jeu. 22 nov. 2018 à 17:40, Rainer Jung  > <mailto:rainer.j...@kippdata.de>> a écrit :
> >
> > Hi Romain,
> >
> > Am 22.11.2018 um 16:53 schrieb Romain Manni-Bucau:
> >  > Hi Rainer,
> >  >
> >  > did you open some java.base modules? like
> >
> > No, just the add-opens that we ship in our catalina.sh.
> >
> >  > --add-opens java.base/java.lang=log4j
> >  >
> >  > (not sure this is the one to open but I guess you can debug and
> > identified
> >  > missing open this way - debugging
> > java.lang.Module#isOpen(java.lang.String)
> >  > for instance)
> >
> > I hoped to find a more definitive answer here, not needing to debug
> > into
> > code.
> >
> > Note this is Log4j 1.2, not 2. So not sure why there should be a
> module
> > "log4j". And if log4j would instead be part of the unnamed module,
> then
> > the already existing --add-opens=java.base/java.lang=ALL-UNNAMED
> would
> > be the corrected line for what you suggest. But as said: that one is
> > already one of the three add-opens TC contains in catalina.sh by
> > default.
> >
> > Regards,
> >
> > Rainer
> >
> >  > Romain Manni-Bucau
> >  > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >  > <https://rmannibucau.metawerx.net/> | Old Blog
> >  > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> |
> >  > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >  >
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >  >
> >  >
> >  > Le jeu. 22 nov. 2018 à 16:45, Rainer Jung
> > mailto:rainer.j...@kippdata.de>> a
> >  > écrit :
> >  >
> >  >> Hi all,
> >  >>
> >  >> I have a problem running TC 7.0.92 with Log4J 1.2.17 and Java 11
> > when
> >  >> trying to load the config from
> > ${catalina.base}/somedir/log4j.properties
> >  >> via server.loader=${catalina.base}/somedir in
> > conf/catalina.properties.
> >  >>
> >  >> It works with Java 9 and 10 and it also works when using the
> >  >> common.loader instead of server.loader. Setting -Dlog4j.debug
> shows,
> >  >> that log4j tries to load the files via the class loader but
> > isn't able to:
> >  >>
> >  >> Trying to find [log4j.xml] using java.net.URLClassLoader@c267ef4
> > class
> > 

Re: Problems running TC 7 with Log4J 1.2 and Java 11

2018-11-22 Thread Romain Manni-Bucau
Hi Rainer,

You are right, missed it was set OOTB.

BTW, just tested on tomcat 7.0.92 with the log4j (v1.2.17) and its adapter
(of the 8.0.53) and java 11.0.1+13-LTS and it works for me (base=home in my
test).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 22 nov. 2018 à 17:40, Rainer Jung  a
écrit :

> Hi Romain,
>
> Am 22.11.2018 um 16:53 schrieb Romain Manni-Bucau:
> > Hi Rainer,
> >
> > did you open some java.base modules? like
>
> No, just the add-opens that we ship in our catalina.sh.
>
> > --add-opens java.base/java.lang=log4j
> >
> > (not sure this is the one to open but I guess you can debug and
> identified
> > missing open this way - debugging
> java.lang.Module#isOpen(java.lang.String)
> > for instance)
>
> I hoped to find a more definitive answer here, not needing to debug into
> code.
>
> Note this is Log4j 1.2, not 2. So not sure why there should be a module
> "log4j". And if log4j would instead be part of the unnamed module, then
> the already existing --add-opens=java.base/java.lang=ALL-UNNAMED would
> be the corrected line for what you suggest. But as said: that one is
> already one of the three add-opens TC contains in catalina.sh by default.
>
> Regards,
>
> Rainer
>
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le jeu. 22 nov. 2018 à 16:45, Rainer Jung  a
> > écrit :
> >
> >> Hi all,
> >>
> >> I have a problem running TC 7.0.92 with Log4J 1.2.17 and Java 11 when
> >> trying to load the config from ${catalina.base}/somedir/log4j.properties
> >> via server.loader=${catalina.base}/somedir in conf/catalina.properties.
> >>
> >> It works with Java 9 and 10 and it also works when using the
> >> common.loader instead of server.loader. Setting -Dlog4j.debug shows,
> >> that log4j tries to load the files via the class loader but isn't able
> to:
> >>
> >> Trying to find [log4j.xml] using java.net.URLClassLoader@c267ef4 class
> >> loader.
> >> Trying to find [log4j.xml] using ClassLoader.getSystemResource().
> >> Trying to find [log4j.properties] using java.net.URLClassLoader@c267ef4
> >> class loader.
> >> Trying to find [log4j.properties] using ClassLoader.getSystemResource().
> >> Could not find resource: [null].
> >> log4j:WARN No appenders could be found for logger
> >> (org.apache.catalina.startup.Catalina).
> >> log4j:WARN Please initialize the log4j system properly.
> >> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
> for
> >> more info.
> >>
> >> I suspect it might have to do with some module system change in JAVA 11,
> >> but I found nothing obvious. Adding "--illegal-access=debug" doesn't
> >> produce any output.
> >>
> >> I'm using the log4j juli plus adapters. No problems using log4j 1.2
> >> inside webapps directly.
> >>
> >> Any ideas?
> >>
> >> Regards,
> >>
> >> Rainer
>


Re: Problems running TC 7 with Log4J 1.2 and Java 11

2018-11-22 Thread Romain Manni-Bucau
Hi Rainer,

did you open some java.base modules? like

--add-opens java.base/java.lang=log4j

(not sure this is the one to open but I guess you can debug and identified
missing open this way - debugging java.lang.Module#isOpen(java.lang.String)
for instance)

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 22 nov. 2018 à 16:45, Rainer Jung  a
écrit :

> Hi all,
>
> I have a problem running TC 7.0.92 with Log4J 1.2.17 and Java 11 when
> trying to load the config from ${catalina.base}/somedir/log4j.properties
> via server.loader=${catalina.base}/somedir in conf/catalina.properties.
>
> It works with Java 9 and 10 and it also works when using the
> common.loader instead of server.loader. Setting -Dlog4j.debug shows,
> that log4j tries to load the files via the class loader but isn't able to:
>
> Trying to find [log4j.xml] using java.net.URLClassLoader@c267ef4 class
> loader.
> Trying to find [log4j.xml] using ClassLoader.getSystemResource().
> Trying to find [log4j.properties] using java.net.URLClassLoader@c267ef4
> class loader.
> Trying to find [log4j.properties] using ClassLoader.getSystemResource().
> Could not find resource: [null].
> log4j:WARN No appenders could be found for logger
> (org.apache.catalina.startup.Catalina).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
> more info.
>
> I suspect it might have to do with some module system change in JAVA 11,
> but I found nothing obvious. Adding "--illegal-access=debug" doesn't
> produce any output.
>
> I'm using the log4j juli plus adapters. No problems using log4j 1.2
> inside webapps directly.
>
> Any ideas?
>
> Regards,
>
> Rainer
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: AccessLogValve using STDOUT

2018-11-12 Thread Romain Manni-Bucau
@Rainer: if it helps you can test with this file handler:
https://github.com/apache/tomee/blob/master/tomee/tomee-juli/src/main/java/org/apache/tomee/jul/handler/rotating/LocalFileHandler.java

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 12 nov. 2018 à 10:51, Rainer Jung  a
écrit :

> Hi Mark,
>
> Am 12.11.2018 um 10:40 schrieb Mark Thomas:
> > On 11/11/2018 10:48, Rainer Jung wrote:
> >> Hi Romain,
> >>
> >> Am 11.11.2018 um 11:16 schrieb Romain Manni-Bucau:
> >>> Hi Rainer,
> >>>
> >>> There is an abstract access valve do providing a log impl (like [1])
> can
> >>> enable that - plus other standard stuff like pushing on kafka accesses
> -
> >>> without hardcoding an stdout stream which can not work in docker in
> some
> >>> setup (where tomcat is launched by another process and redirects only
> >>> configured logs).
> >>
> >> I know, that there's the AbstractAccessLogValve, that's why I wrote "Of
> >> course it also extends our base AbstractAccessLogValve", so I am using
> >> it in the STDOUT variant just like the LoggingAccessLogPattern you
> >> mentioned does.
> >>
> >> Yes, another way would be to have a variant that writes via JULI and let
> >> people configure that (combining with what log framework they like).
> >
> > This is why I created the Verbatim Formatter.
> >
> > This past discussion looks to be relevant here:
> > https://tomcat.markmail.org/thread/7ve6awm6inud54l3
> >
> >> That would be more flexible, but also less performant. The reason, that
> >> the AccessLogValve doesn't simply use a log framework for the request
> >> protocol is (I think) only performance. If that is correct and still
> >> relevant, then using a less performing approach for a seemingly simpler
> >> STDOUT output would be surprising.
> >
> > There are performance numbers in the thread above. My reading of that
> > thread is that the initial figures weren't encouraging but that further
> > refinement of the code and/or logging configuration may be able to
> > address that.
>
> Thanks for the discussion pointer actually going back to 2012!
>
> I will do some experiments along the lines of JULI to get current
> numbers on overhead (mostly CPU and latency but probably also memory)
> using our current default solution versus using JULI with
> java.util.logging versus using JULI with something like Log4J2. And also
> probably checking the log framework cases with simple file based logging
> and with STDOUT logging.
>
> I'll come back here, when I have some numbers.
>
> Regards,
>
> Rainer
>
> >>> [1]
> >>>
> https://github.com/apache/meecrowave/blob/trunk/meecrowave-core/src/main/java/org/apache/meecrowave/tomcat/LoggingAccessLogPattern.java
> >>>
> >>>
> >>> Le dim. 11 nov. 2018 11:06, Rainer Jung  a
> >>> écrit :
> >>>
> >>>> Hi all,
> >>>>
> >>>> I don't like it but in managed container environments application
> >>>> instances tend to get configured to write any log output to STDOUT
> (than
> >>>> everything is caught and redirected to a log concentrator).
> >>>>
> >>>> I could be wrong, but I think there is no appropriate way of doing it
> >>>> with our standard AccessLogValve. I first thought to add a flag but
> then
> >>>> noticed that the biggest part of the code of AccessLogValve is about
> >>>> file management. Furthermore adding the STDOUT feature to it means we
> >>>> would either produce lots of warnings for attributes that get ignored
> >>>> once the feature is used, or risking that people might not understand
> >>>> what they actually configure when enabling STDOUT but still setting
> file
> >>>> and directory attributes.
> >>>>
> >>>> I did a little experiment by stripping the existing AccessLogValve
> down
> >>>> to just use STDOUT but still allow buffer and encoding configuration.
> I
> >>>> ended up with 220 lines, less than 100 lines with actual code.
> >>>>
> >>>> I would like to add it, but don't know whether there is enough demand
> >>>> for that use case and whether people agree on using a separate class
> as
> >>>> the right solution. Of course it also extends our base
> >>>> AbstractAccessLogValve.
> >>>>
> >>>> Opinion?
> >>>>
> >>>> Thanks and regards,
> >>>>
> >>>> Rainer
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: AccessLogValve using STDOUT

2018-11-11 Thread Romain Manni-Bucau
Le dim. 11 nov. 2018 à 15:41, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Romain,
>
> On 11/11/18 05:57, Romain Manni-Bucau wrote:
> > I think the perf point is likely wrong. Default JUL handlers are
> > "slow" (the hypothesis being you log a lot but this is more
> > comparatively to others frameworks) but if you switch the handler
> > impl you can even bit log4j2 disruptor setup so JUL is not slow by
> > itself but only its configuration can be so I think it is ok to use
> > JUL. Also Tomcat allows to switch the Log impl so you can use any
> > impl, including a stdout/stderr implementation which can be
> > something worth making configurable more than limiting it to the
> > access log IMO (like -Dtomcat.log.usestdstreams=true in LogFactory
> > or just a jar to add implementing Log SPI).
>
> Writing directly to stdout instead of through String (or
> StringBuilder) buffers (to a logging framework) is always going to be
> faster.
>

Point is not if it is faster or slower by itself - we don't need to dig
until the point javac replaces stringbuilders by direct constant in the
constant pool or the logrecord creation which can be hardcoded in the impl
to bypass the stacktrace capture.
My point is more the perf comparatively to the cost of the other parts.
Compared to a request it is negligible - assuming the handler(s) is(are)
well written - and not impacting the overall perf so it is ok as a solution.


>
> Honestly, maintainability here is more important to me than
> performance. I'd be surprised if the performance difference is
> significant. Writing to stdout versus a logging framework? Probably
> similar in the amount of code necessary.
>

Agree it is exactly the same (overriding 1 method with 1 call - or 2 if you
want to handle error cases on stderr/log.severe).
However, stdout creates a particular case of a particular container
deployment instead of reusing logging framework which are here to be
portable, even in docker they fulfill this part (interacting directly with
a driver or avoiding stdout which can be slower than alternatives in some
environments).

That said the cost of having both is still very light (once again it is max
1 class with 2 line of owned logic) so maybe Tomcat can get both?


>
> - -chris
>
> > Le dim. 11 nov. 2018 à 11:48, Rainer Jung 
> > a écrit :
> >
> >> Hi Romain,
> >>
> >> Am 11.11.2018 um 11:16 schrieb Romain Manni-Bucau:
> >>> Hi Rainer,
> >>>
> >>> There is an abstract access valve do providing a log impl (like
> >>> [1]) can enable that - plus other standard stuff like pushing
> >>> on kafka accesses - without hardcoding an stdout stream which
> >>> can not work in docker in some setup (where tomcat is launched
> >>> by another process and redirects only configured logs).
> >>
> >> I know, that there's the AbstractAccessLogValve, that's why I
> >> wrote "Of course it also extends our base
> >> AbstractAccessLogValve", so I am using it in the STDOUT variant
> >> just like the LoggingAccessLogPattern you mentioned does.
> >>
> >> Yes, another way would be to have a variant that writes via JULI
> >> and let people configure that (combining with what log framework
> >> they like). That would be more flexible, but also less
> >> performant. The reason, that the AccessLogValve doesn't simply
> >> use a log framework for the request protocol is (I think) only
> >> performance. If that is correct and still relevant, then using a
> >> less performing approach for a seemingly simpler STDOUT output
> >> would be surprising.
> >>
> >> Regards,
> >>
> >> Rainer
> >>
> >>> [1]
> >>>
> >> https://github.com/apache/meecrowave/blob/trunk/meecrowave-core/src/m
> ain/java/org/apache/meecrowave/tomcat/LoggingAccessLogPattern.java
> <https://github.com/apache/meecrowave/blob/trunk/meecrowave-core/src/main/java/org/apache/meecrowave/tomcat/LoggingAccessLogPattern.java>
> >>>
> >>>
> >>
> Le dim. 11 nov. 2018 11:06, Rainer Jung  a
> >> écrit :
> >>>
> >>>> Hi all,
> >>>>
> >>>> I don't like it but in managed container environments
> >>>> application instances tend to get configured to write any log
> >>>> output to STDOUT (than everything is caught and redirected to
> >>>> a log concentrator).
> >>>>
> >>>> I could be wrong, but I think there is no a

Re: AccessLogValve using STDOUT

2018-11-11 Thread Romain Manni-Bucau
I think the perf point is likely wrong. Default JUL handlers are "slow"
(the hypothesis being you log a lot but this is more comparatively to
others frameworks)
but if you switch the handler impl you can even bit log4j2 disruptor setup
so JUL is not slow by itself but only its configuration can be so I think
it is ok
to use JUL. Also Tomcat allows to switch the Log impl so you can use any
impl, including a stdout/stderr implementation which can be something worth
making configurable more than limiting it to the
access log IMO (like -Dtomcat.log.usestdstreams=true in LogFactory or just
a jar to add implementing Log SPI).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le dim. 11 nov. 2018 à 11:48, Rainer Jung  a
écrit :

> Hi Romain,
>
> Am 11.11.2018 um 11:16 schrieb Romain Manni-Bucau:
> > Hi Rainer,
> >
> > There is an abstract access valve do providing a log impl (like [1]) can
> > enable that - plus other standard stuff like pushing on kafka accesses -
> > without hardcoding an stdout stream which can not work in docker in some
> > setup (where tomcat is launched by another process and redirects only
> > configured logs).
>
> I know, that there's the AbstractAccessLogValve, that's why I wrote "Of
> course it also extends our base AbstractAccessLogValve", so I am using
> it in the STDOUT variant just like the LoggingAccessLogPattern you
> mentioned does.
>
> Yes, another way would be to have a variant that writes via JULI and let
> people configure that (combining with what log framework they like).
> That would be more flexible, but also less performant. The reason, that
> the AccessLogValve doesn't simply use a log framework for the request
> protocol is (I think) only performance. If that is correct and still
> relevant, then using a less performing approach for a seemingly simpler
> STDOUT output would be surprising.
>
> Regards,
>
> Rainer
>
> > [1]
> >
> https://github.com/apache/meecrowave/blob/trunk/meecrowave-core/src/main/java/org/apache/meecrowave/tomcat/LoggingAccessLogPattern.java
> >
> > Le dim. 11 nov. 2018 11:06, Rainer Jung  a
> écrit :
> >
> >> Hi all,
> >>
> >> I don't like it but in managed container environments application
> >> instances tend to get configured to write any log output to STDOUT (than
> >> everything is caught and redirected to a log concentrator).
> >>
> >> I could be wrong, but I think there is no appropriate way of doing it
> >> with our standard AccessLogValve. I first thought to add a flag but then
> >> noticed that the biggest part of the code of AccessLogValve is about
> >> file management. Furthermore adding the STDOUT feature to it means we
> >> would either produce lots of warnings for attributes that get ignored
> >> once the feature is used, or risking that people might not understand
> >> what they actually configure when enabling STDOUT but still setting file
> >> and directory attributes.
> >>
> >> I did a little experiment by stripping the existing AccessLogValve down
> >> to just use STDOUT but still allow buffer and encoding configuration. I
> >> ended up with 220 lines, less than 100 lines with actual code.
> >>
> >> I would like to add it, but don't know whether there is enough demand
> >> for that use case and whether people agree on using a separate class as
> >> the right solution. Of course it also extends our base
> >> AbstractAccessLogValve.
> >>
> >> Opinion?
> >>
> >> Thanks and regards,
> >>
> >> Rainer
>


Re: AccessLogValve using STDOUT

2018-11-11 Thread Romain Manni-Bucau
Hi Rainer,

There is an abstract access valve do providing a log impl (like [1]) can
enable that - plus other standard stuff like pushing on kafka accesses -
without hardcoding an stdout stream which can not work in docker in some
setup (where tomcat is launched by another process and redirects only
configured logs).

[1]
https://github.com/apache/meecrowave/blob/trunk/meecrowave-core/src/main/java/org/apache/meecrowave/tomcat/LoggingAccessLogPattern.java

Le dim. 11 nov. 2018 11:06, Rainer Jung  a écrit :

> Hi all,
>
> I don't like it but in managed container environments application
> instances tend to get configured to write any log output to STDOUT (than
> everything is caught and redirected to a log concentrator).
>
> I could be wrong, but I think there is no appropriate way of doing it
> with our standard AccessLogValve. I first thought to add a flag but then
> noticed that the biggest part of the code of AccessLogValve is about
> file management. Furthermore adding the STDOUT feature to it means we
> would either produce lots of warnings for attributes that get ignored
> once the feature is used, or risking that people might not understand
> what they actually configure when enabling STDOUT but still setting file
> and directory attributes.
>
> I did a little experiment by stripping the existing AccessLogValve down
> to just use STDOUT but still allow buffer and encoding configuration. I
> ended up with 220 lines, less than 100 lines with actual code.
>
> I would like to add it, but don't know whether there is enough demand
> for that use case and whether people agree on using a separate class as
> the right solution. Of course it also extends our base
> AbstractAccessLogValve.
>
> Opinion?
>
> Thanks and regards,
>
> Rainer
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: [VOTE] Release Apache Tomcat 9.0.13

2018-11-04 Thread Romain Manni-Bucau
+1 (non-binding), tested on meecrowave and some work projects

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 5 nov. 2018 à 08:26, Violeta Georgieva  a
écrit :

> Hi,
>
> На пт, 2.11.2018 г. в 18:11 ч. Mark Thomas  написа:
> >
> > The proposed Apache Tomcat 9.0.13 release is now available for voting.
> >
> > The major changes compared to the 9.0.13 release are:
> >
> > - support for TLSv1.3 when used with a JRE or OPenSSl version that
> >   supports it
> >
> > - added support for encrypting cluster traffic
> >
> > - added automatic reloading of tomcat-users.xml after a change
> >
> >
> > Along with lots of other bug fixes and improvements.
> >
> > For full details, see the changelog:
> > http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
> >
> > It can be obtained from:
> > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.13/
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1196/
> > The svn tag is:
> > http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_13/
> >
> > The proposed 9.0.13 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 9.0.13
>
> +1
>
> Regards,
> Violeta
>


Re: Don't require a base directory?

2018-07-19 Thread Romain Manni-Bucau
up? :)

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le dim. 15 juil. 2018 à 12:12, Romain Manni-Bucau  a
écrit :

> Hi guys,
>
> Just tested with Tomcat 9.0.10 embed and it seems the requirement is a
> base directory is now arbitrary.
>
> To be concrete I overrided org.apache.catalina.startup.Tomcat#initBaseDir
> to not mkdir the folder if it doesn't exist and I ran several apps
> (including meecrowave/cdi based ones) without any issue.
>
> Is it possible to relax this constraint? I envision it as a toggle
> settable on Tomcat instance (tomcat.setRequiresDirectories(false)). If set
> it to false it would disable the mkdir and probably disable the webapp
> extractions.
>
> Guess spring boot can benefit from it as well.
>
> Wdyt?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>


Don't require a base directory?

2018-07-15 Thread Romain Manni-Bucau
Hi guys,

Just tested with Tomcat 9.0.10 embed and it seems the requirement is a base
directory is now arbitrary.

To be concrete I overrided org.apache.catalina.startup.Tomcat#initBaseDir
to not mkdir the folder if it doesn't exist and I ran several apps
(including meecrowave/cdi based ones) without any issue.

Is it possible to relax this constraint? I envision it as a toggle settable
on Tomcat instance (tomcat.setRequiresDirectories(false)). If set it to
false it would disable the mkdir and probably disable the webapp
extractions.

Guess spring boot can benefit from it as well.

Wdyt?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Re: Dynamic reloading of SSL certificates

2018-06-27 Thread Romain Manni-Bucau
+1 for connectors IMHO

Le mer. 27 juin 2018 18:21, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Romain,
>
> On 6/27/18 11:50 AM, Romain Manni-Bucau wrote:
> > up? any hope we have live reloading of certs in tomcat?
>
> Yup. Recent versions allow you to reload the SSLHostConfigs.
>
> I was getting ready to update my presentation on Let's Encrypt,
> actually, so this was a good nudge to actually do that.
>
> I thought the operation would be exposed via JMX, but it does not
> appear to be so. It's in the Manager application.
>
> Have a look at what ManagerServlet.sslReload() does.
>
> markt, any objection to taking this code and putting it into the
> Connector under the public method reloadSSLHostConfig to make it (a)
> accessible via JMX and (b) easy to access?
>
> We have several options when it comes to JMX operations:
>
> 1. Connector
> 2. ProcotolHandler
> 3. SSLHostConfig
>
> #3 doesn't make much sense, since SSLHostConfigs are the ones that
> were loaded, and presumably will be replaced when a "reload" happens.
>
> #2 would work fine, except that:
>
> a. Everyone will look on the Connector first
> and
> b. The ProtocolHandler doesn't know if SSLEnabled=true on the connector
>
> So I think this is best-done on the Connector.
>
> Any comments or suggestions?
>
> - -chris
>
> >
> > Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> |
> > Blog <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-ee-8-high-perfo
> rmance>
> >
> >
> >
> > Le mar. 2 janv. 2018 à 17:00, Romain Manni-Bucau
> >  a écrit :
> >
> >> Yes, if tomcat can supports hot reloading of certs it is very
> >> feasible:
> >> https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/ma
> in/java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.ja
> <https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.ja>
> va
> >>
> >>
> >>
> >>
> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github
> >> <https://github.com/rmannibucau> | LinkedIn
> >> <https://www.linkedin.com/in/rmannibucau>
> >>
> >> 2018-01-02 16:56 GMT+01:00 Emmanuel Bourg :
> >>
> >>> Le 02/01/2018 à 09:40, Romain Manni-Bucau a écrit :
> >>>> up?
> >>>
> >>> I haven't got much time to look into this yet. However since
> >>> Let's Encrypt client implementations in Java are starting to
> >>> appear [1] I wonder if the certificate renewal process could be
> >>> directly integrated into Tomcat instead of relying on an
> >>> external client such as certbot.
> >>>
> >>> Emmanuel Bourg
> >>>
> >>> [1] https://github.com/shred/acme4j
> >>>
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlszuY4ACgkQHPApP6U8
> pFgxRA//Zsf+/zHUtTx1bVLFtJM7pYSHbdxepQRTCnEN4IS5dAeBSx7zI7w/OSV/
> Dt3Fd8dglDrimoYNEt4EWCAo0HNJjJkEsW9UbJPx0riyHQjqW4/wrSFFoWyDLmUg
> IEalbxZ++9MYlIcRAVwJRQ4lfze9g+e1CmkEyN3j3CZuq7mQp+5U9EEX8QkuI3Ig
> cRZfjztWST6Nsec88Y08w7VE+HYvTDQGG/0rzaeeJrQJ7zANxy2YtyBujzCTV3LK
> 2wzOMrc63X4VMGISwbimhFWRwfzwkwYmUZXOhCa0OW5/Ob56x/LVYtlRykfQAYbT
> xTIyaY+hc3cdbbDNEWymef6FbILbA7lOUOy0qhH2Aiv47gPCTIYyvDkYPr+tjoYo
> 5F+gqfTmy3qfBOBbRpcWcC9ySu5CdGvwP9YIMY8Q6ko8y/ySw26CK2XQH8Nm4yca
> os0zhOu2GzI0P202yGVavoSjLYsdJxDHCIcIRLowbCVBnp6bY1kL/dgGtyQoC7oi
> K9Yoz9LmjDJC+DkLSidZEugyGRCihI5fEAH9f1ftSDoCjMeYUMJ5dcOeiU2Vu5Ix
> CyYmiIgIDeWOitJJOOV38ogdGo8pGWJvFWymOt41BROtiS7OOTnURcc3Nx65C5mE
> odkio+xWznTt09a4Fb4cE9s1CoUIZ79ZkjFf2L4PY+xc27T5xvs=
> =8dT7
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: Dynamic reloading of SSL certificates

2018-06-27 Thread Romain Manni-Bucau
up? any hope we have live reloading of certs in tomcat?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 2 janv. 2018 à 17:00, Romain Manni-Bucau  a
écrit :

> Yes, if tomcat can supports hot reloading of certs it is very feasible:
> https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau>
>
> 2018-01-02 16:56 GMT+01:00 Emmanuel Bourg :
>
>> Le 02/01/2018 à 09:40, Romain Manni-Bucau a écrit :
>> > up?
>>
>> I haven't got much time to look into this yet. However since Let's
>> Encrypt client implementations in Java are starting to appear [1] I
>> wonder if the certificate renewal process could be directly integrated
>> into Tomcat instead of relying on an external client such as certbot.
>>
>> Emmanuel Bourg
>>
>> [1] https://github.com/shred/acme4j
>>
>
>


Re: [VOTE] Release Apache Tomcat 9.0.10

2018-06-21 Thread Romain Manni-Bucau
+1 (non-binding), tested on Meecrowave and a few work apps and all was green

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 20 juin 2018 à 22:58, Rémy Maucherat  a écrit :

> On Wed, Jun 20, 2018 at 9:45 PM Mark Thomas  wrote:
>
> > The proposed Apache Tomcat 9.0.10 release is now available for voting.
> >
> > Note:
> > 9.0.9 was tagged and uploaded when BZ 62476 was created and the decision
> > was taken to re-tag to pick up that fix.
> >
> > The major changes compared to the 9.0.8 release are:
> >
> > - Add the RemoteCIDRFilter and RemoteCIDRValve that can be used to
> >   allow/deny requests based on IPv4 and/or IPv6 client address where the
> >   IP ranges are defined using CIDR notation.
> >   Based on a patch by Francis Galiegue.
> >
> > - Use NIO2 API for websockets writes.
> >
> > - Update the packaged version of the Tomcat Native Library to 1.2.17 to
> >   pick up the latest Windows binaries built with APR 1.6.3 and OpenSSL
> >   1.0.2o.
> >
> > - Correct a regression in the Host validation by removing the
> >   requirement that the final component of a FQDN must be alphabetic.
> >
> > Along with lots of other bug fixes and improvements.
> >
> > For full details, see the changelog:
> > http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
> >
> > It can be obtained from:
> > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.10/
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1186/
> > The svn tag is:
> > http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_10/
> >
> > The proposed 9.0.10 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 9.0.10
> >
>
> No issues testing the usual stuff.
>
> Ran into unusual problems testing SSL with JSSE (OpenSSL worked well) on
> Java 10 and 11, nothing conclusive yet. Will investigate for the next
> build.
>
> Rémy
>


Re: Tomcat 9 Support Java Version clarification

2018-04-26 Thread Romain Manni-Bucau
@Chris: -release 1.8 (kind of target=source=1.8 but java 9 has the
signatures of java 8 to ensure it will run on java 8 and avoid the issues
like "i built with java 8 with source=target=1.7 but it doesnt run on java
7")


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-26 17:28 GMT+02:00 Christopher Schultz <ch...@christopherschultz.net
>:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Coty,
>
> On 4/25/18 2:51 PM, Coty Sutherland wrote:
> > On Wed, Apr 25, 2018 at 2:14 PM, Mark Thomas <ma...@apache.org>
> > wrote:
> >> On 25/04/18 18:07, Coty Sutherland wrote:
> >>> Hi all,
> >>>
> >>> There was a problem discovered on Ubuntu where they're building
> >>> Tomcat 9 with Java 9, but users are using it with Java 8. That
> >>> is causing issues because of changes made in Java 9. One of the
> >>> Ubuntu folks is poking around with a patch and has some details
> >>> about the issue here https://pastebin.com/EnVh7K8v. We will
> >>> probably open a bugzilla to see if anyone is open to addressing
> >>> them in tomcat,
> >>
> >> I'm not in favour of that patch.
> >
> > Given the amount of changes I'm not either, I mentioned it because
> > I told the person working on it I would just in case someone was
> > interested. I think the responsibility of maintaining those sorts
> > of problems should fall on that on the distro's maintainer. Fedora
> > is fine for me (I build with Java 8), but apparently Ubuntu is
> > building with Java 10 and will switch to 11 at some point, which is
> > causing the problem.
> >
> >>
> >>> but while thinking about the problem I noted that our supported
> >>> java versions table on
> >>> http://tomcat.apache.org/whichversion.html doesn't explicitly
> >>> say that by 'supported' we mean the tomcat binary we provide
> >>> will run on that java version. I don't think that we claim that
> >>> you can build with any version and run on any version anywhere,
> >>> right?
> >>
> >> Correct.
> >
> > Thanks for confirming.
> >
> >> BUILDING.txt states that Tomcat 9 should be built with Java 8.
> >>
> >>> Is anyone opposed to adding a statement to that effect on the
> >>> page?
> >>
> >> I think something along those lines would be fine. Something to
> >> the effect of if you build from source with a higher version of
> >> Java than the minimum then it might not work on Java versions
> >> below the version you build with. But worded more clearly.
> >
> > OK, I'll look at adding some verbiage around that.
>
> Dumb question, I haven't tried Java 9 yet: can't you just set "-target
> 1.8" on the compiler and still build with Java 9?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlrh8AwACgkQHPApP6U8
> pFjMaQ/8Dc/3cQmckkgYeCmrlliNQV59GvHI4tmueMTM+Rd/OKYQZpiD48GTD09U
> zMMbTsc9oqmzS+FcDeYMyeZcx7W97oH+uiaTAiyM6LKbbEiz0KHITLsnMw1ujAMw
> 9q0V1pz4uaS3vBKRZtJRg5AEGYCzAT+lLzmZWhY26WlTppeISTmd/jCqK37v8OAq
> 98nCd6vVno8lJIRoSPbNLorPIi+iS8OoVQl5uQrdylb0ueXZiv0eI7BL5DgZoKQC
> 9xhYCcGPGj/CdHAym6koBpCMLn4l3hc8m/rvdY238FDcDLrzSdHyNSkslXqzG8iD
> L+iJt+Go2wn7Pe+n3/+LpN4i5yIv5JMSqW3W0iUKGqz6yJblRNxpSiD0iS0h3zOc
> zBnzYtYvOV+dMW339OZHxwZZd+TlFN9XeXq81a4orfEbH4AwZEJqKzRGiRCMW3jP
> X4O8iGF68TgQHDbOkMTkzBjLsgof7bmk5r2uYcndGlhoOLDdL0KszXxNVTQPKFwc
> ImMs3UVBmqdb4JI+7tzK/j0LyQmjmjPmWq0z/xzpJTTxzDfRfsr1mhcWygL7bv+d
> 7jGwye77ZZQBjAOjU53z9By+JEfDZtizAz5/7FjlSdNWAygXNZIZiGs+XbVyUmTL
> N4l/6vTHOHCBLV8xHnRWPtwyEw0VmBFzExpn+GnwLfkKmmRHEMY=
> =lUtG
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: [Git migration] trunk or master

2018-01-09 Thread Romain Manni-Bucau
+1 for master and same as on svn for branches

Le 10 janv. 2018 00:03, "Emmanuel Bourg"  a écrit :

> Le 08/01/2018 à 15:33, Mark Thomas a écrit :
>
> > Thoughts?
>
> +1 for master
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: Dynamic reloading of SSL certificates

2018-01-02 Thread Romain Manni-Bucau
Yes, if tomcat can supports hot reloading of certs it is very feasible:
https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>

2018-01-02 16:56 GMT+01:00 Emmanuel Bourg <ebo...@apache.org>:

> Le 02/01/2018 à 09:40, Romain Manni-Bucau a écrit :
> > up?
>
> I haven't got much time to look into this yet. However since Let's
> Encrypt client implementations in Java are starting to appear [1] I
> wonder if the certificate renewal process could be directly integrated
> into Tomcat instead of relying on an external client such as certbot.
>
> Emmanuel Bourg
>
> [1] https://github.com/shred/acme4j
>


Re: Dynamic reloading of SSL certificates

2018-01-02 Thread Romain Manni-Bucau
up?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>

2017-09-05 16:41 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> Hello guys,
>
> wonder if this thread went anywhere? Would be very neat to have a let's
> encrypt integration (don't know if it would be a listener to declare to
> have automatic reloading or just a flag on the SSL config but it would ease
> deploying self hosted instances).
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-01-23 23:18 GMT+01:00 Christopher Schultz <
> ch...@christopherschultz.net>:
>
>> Mark and Emmanuel,
>>
>> On 1/23/17 5:01 AM, Mark Thomas wrote:
>> > On 23/01/2017 09:36, Emmanuel Bourg wrote:
>> >> Hi all,
>> >>
>> >> With the fast adoption of Let's Encrypt many people are interested in
>> >> integrating it with Tomcat. A first step was to ensure that Tomcat can
>> >> directly use the PEM certificates generated by the letsencrypt/certbot
>> >> client. An important aspect of Let's Encrypt is automation, the
>> >> certificates are relatively short lived (90 days) and must be updated
>> >> automatically. AFAIK there is no easy way yet to reload a connector in
>> >> Tomcat to pick a new certificate. The administrator either has to
>> >> restart Tomcat (bad in a production environment) or do some JMX tricks
>> >> [1] (but JMX must be enabled and secured properly).
>> >>
>> >> I'm wondering if it would be possible for Tomcat to monitor the
>> >> certificates/keystore files and reload the associated connectors
>> >> automatically? If there is a consensus on this feature I'd be
>> interested
>> >> in implementing it.
>> >
>> > For background reading:
>> >
>> > http://tomcat.markmail.org/thread/fthbtwuozidno6lw
>> >
>> > http://tomcat.markmail.org/thread/753blzkslmifcvh4
>>
>> Yep. I'm also planning on giving a presentation about this exact topic
>> at ApacheCon in Miami.
>>
>> -chris
>>
>>
>


Re: removeMessageHandler in WS doesnt handle wrapped listeners?

2017-12-21 Thread Romain Manni-Bucau
PS: forgot the workaround:

session.removeMessageHandler(session.getMessageHandlers().iterator().next());



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>

2017-12-21 10:54 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> Hi guys,
>
> shouldnt org.apache.tomcat.websocket.WsSession#removeMessageHandler
> handle the wrapped instance the other way around?
>
> My isssue is this kind of code:
>
> session.addMessageHandler(MyPayload.class, this);
> session.removeMessageHandler(MyPayload.class, this);
>
> this doesnt work cause the instance is wrapped but not tested this way, i
> would need to remove the handler passing the wrapped instance but i cant
> access it transparently through the javax code.
>
> Did I miss something?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau>
>


removeMessageHandler in WS doesnt handle wrapped listeners?

2017-12-21 Thread Romain Manni-Bucau
Hi guys,

shouldnt org.apache.tomcat.websocket.WsSession#removeMessageHandler handle
the wrapped instance the other way around?

My isssue is this kind of code:

session.addMessageHandler(MyPayload.class, this);
session.removeMessageHandler(MyPayload.class, this);

this doesnt work cause the instance is wrapped but not tested this way, i
would need to remove the handler passing the wrapped instance but i cant
access it transparently through the javax code.

Did I miss something?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>


Re: [VOTE] Release Apache Tomcat 9.0.2

2017-11-27 Thread Romain Manni-Bucau
2017-11-27 9:15 GMT+01:00 Konstantin Kolinko <knst.koli...@gmail.com>:
> 2017-11-27 10:55 GMT+03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>> Hi guys,
>>
>> I have 2 questions:
>>
>> 1. (simple ;)) is the repo released? central is not yet synch-ed
>
> It is a VOTE thread, not a RELEASE one.
>
> Nothing should be on Central.

oops, not sure why I read announce yesterday, forget it

>
>> 2. "java 9 fully supported": I didn't see the classloader update to
>> support multi-jar release
>
> Yes. Issue 61601.
>
>> or module-info respect (visibility+SPI),
>
> I do not understand what you mean here.
>
> There are no such feature requests in Bugzilla, nor in changelog,
> meaning nobody needs this feature.

Well this is a bit fast as answer ;) since java 9 brings new features
then fully supported would naturally mean Tomcat embraces these
features as well otherwise you can code a "standard" java 9 app and
have it not working in Tomcat. There is no issue
not supporting it yet - even Spring doesn't - but the "fully" made me
wondering if I missed a key commit.

Thanks for the clarification.

>
>> is it intended or is it "support" as "can run" only?
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

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



Fwd: [VOTE] Release Apache Tomcat 9.0.2

2017-11-26 Thread Romain Manni-Bucau
Hi guys,

I have 2 questions:

1. (simple ;)) is the repo released? central is not yet synch-ed
2. "java 9 fully supported": I didn't see the classloader update to
support multi-jar release or module-info respect (visibility+SPI), is
it intended or is it "support" as "can run" only?

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



-- Forwarded message --
From: Mark Thomas <ma...@apache.org>
Date: 2017-11-25 22:36 GMT+01:00
Subject: [VOTE] Release Apache Tomcat 9.0.2
To: Tomcat Developers List <dev@tomcat.apache.org>


The proposed Apache Tomcat 9.0.2 release is now available for voting.

The major changes compared to the 9.0.1 release are:

- Java 9 is fully supported

- Fixed numerous JASPIC issues with patches from Lazar

- Update the packaged version of the Tomcat Native Library to
  1.2.16 to pick up the latest Windows binaries built with
  APR 1.6.3 and OpenSSL 1.0.2m

Along with lots of other bug fixes and improvements.


For full details, see the changelog:
http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.2/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1160/
The svn tag is:
http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_2/

The proposed 9.0.2 release is:
[ ] Broken - do not release
[ ] Alpha  - go ahead and release as 9.0.2
[ ] Beta   - go ahead and release as 9.0.2
[ ] Stable - go ahead and release as 9.0.2

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

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



tomcat-api missing from websocket?

2017-11-02 Thread Romain Manni-Bucau
Hi guys,

is it known the tomcat-websocket pom doesn't contain all dependencies
websocket code requires? typically i didnt see tomcat-api here but
WsSession uses it.

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

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



Re: Java 9, modularisation and build systems

2017-10-06 Thread Romain Manni-Bucau
Hi Mark,

few comments inline

2017-10-06 10:18 GMT+02:00 Mark Thomas :

> Hi all,
>
> As you have probably seen, I've been working on improving Java 9
> support. The current TODO list is:
>
> - module path scanning
> - handling multi-release JARs in the JarScanner
>
> I've been looking at the module path scanning and while there are
> various approaches, they all make fairly heavy use of Java 9 APIs.
> Implementing them via the existing JreCompat approach is going to
> require a lot of reflection. That got me thinking about the obvious
> alternative: multi-release JARs.
>
> Handling multi-release JARs is going to require some changes / additions
> to the build process and source layout. That reminded me of a comment
> that Rémy made at TomcatCon in London regarding modularisation and build
> tools and whether we wanted to do things differently. If we want to make
> changes in that area it probably makes sense to make them now - hence
> this e-mail.
>
> Modularisation and build tools are inter-related so I think it makes
> sense to discuss them together. Hence this thread.
>
> I'm going to start with what I think is the easy one: Modularisation.
>
> Tomcat is already modular. You can remove some features (JSP, WebSocket,
> clustering?, store-config?) simply by removing the JARs. Do we want to
> take this further? Nothing immediately springs to mind hence the fairly
> open question: what changes could we implement to make Tomcat more
> modular and how would those changes benefit our users?
>
> The build tools aspect has, historically, been the area where fairly
> strong opinions have been expressed.
>
> The argument against Ant is that it isn't as well known amongst
> prospective new contributors as other tools and hence creates a barrier
> to contributing that harms the community. The argument for Ant is that
> it works, it isn't causing any pain points and it has the flexibility to
> handle all aspects of our build.
>
> The usual candidate for an alternative build system is Maven. The
> argument for Maven is that it is more widely known and hence easier to
> get started with. The argument against is broadly that Maven is very
> opinionated and they way Tomcat currently does things is not consistent
> with what Maven expects and some things (e.g. the Windows installer) are
> well outside the typical Maven build. Therefore switching to Maven would
> require a fair amount of effort.
>
> I'd like to suggest a third alternative: Gradle. The argument for Gradle
> is that it can boot-strap itself so, unlike Ant, a new user doesn't need
> to download the build tool. Gradle can also import Ant build files so we
> could start with a simple Gradle script that simply imported the current
> Ant script and then migrate slowly over time. The argument against is
> that it isn't as widely known as Maven.
>

Maven also has this wrapper stuff (
https://github.com/takari/takari-maven-plugin) and an ant plugin so this
doesn't help much to decide between gradle and maven IMHO.


>
>
> My own views are neutral at this point on modularisation. I don't have
> any immediate suggestions for changes but I'd like to hear what ideas
> others have. On build systems, I'm not convinced that the benefits of
> switching to Maven justify the costs. Gradle looks promising and I do
> like the boot-strapping feature. If there was consensus to move to
> Gradle, I'd be willing to help that process.
>
>

I'm concerned of all consumers of tomcat embedded - none of them are java 9
friendly today AFAIK - including spring boot - so this could create a
moment where tomcat can't be used on java 9 even if it supports it by
itself ("alone"). Maybe it is the kind of work which can be done in a
branch in quick and dirty mode to evaluate the current state before
speaking of a build tool which is mainly an implementation detail not
impacting much users _immediately_? Rephrased: I would like tomcat to avoid
to go live and prevent people to upgrade to get security fixes (or bug
fixes) due to java 9 work - it has been the case for surefire where a few
release broke more than they helped to support java 9.


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


Re: Dynamic reloading of SSL certificates

2017-09-05 Thread Romain Manni-Bucau
Hello guys,

wonder if this thread went anywhere? Would be very neat to have a let's
encrypt integration (don't know if it would be a listener to declare to
have automatic reloading or just a flag on the SSL config but it would ease
deploying self hosted instances).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-01-23 23:18 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net
>:

> Mark and Emmanuel,
>
> On 1/23/17 5:01 AM, Mark Thomas wrote:
> > On 23/01/2017 09:36, Emmanuel Bourg wrote:
> >> Hi all,
> >>
> >> With the fast adoption of Let's Encrypt many people are interested in
> >> integrating it with Tomcat. A first step was to ensure that Tomcat can
> >> directly use the PEM certificates generated by the letsencrypt/certbot
> >> client. An important aspect of Let's Encrypt is automation, the
> >> certificates are relatively short lived (90 days) and must be updated
> >> automatically. AFAIK there is no easy way yet to reload a connector in
> >> Tomcat to pick a new certificate. The administrator either has to
> >> restart Tomcat (bad in a production environment) or do some JMX tricks
> >> [1] (but JMX must be enabled and secured properly).
> >>
> >> I'm wondering if it would be possible for Tomcat to monitor the
> >> certificates/keystore files and reload the associated connectors
> >> automatically? If there is a consensus on this feature I'd be interested
> >> in implementing it.
> >
> > For background reading:
> >
> > http://tomcat.markmail.org/thread/fthbtwuozidno6lw
> >
> > http://tomcat.markmail.org/thread/753blzkslmifcvh4
>
> Yep. I'm also planning on giving a presentation about this exact topic
> at ApacheCon in Miami.
>
> -chris
>
>


symmetry of get/set property in endpoint?

2017-07-06 Thread Romain Manni-Bucau
Hi guys,

is it intended org.apache.tomcat.util.net.AbstractEndpoint#setProperty and
its getter are not symmetric? getter uses only attributes whereas setter
uses a socket or this through reflection.

Asking cause setProperty(x, y) implies most likely getProperty(x) != y
which sounds weird

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>


Re: RFE idea: Add port offset system property to Tomcat

2017-06-09 Thread Romain Manni-Bucau
@Mark: guess you are thinking to server.xml? then it would have placeholder
support so still a system property somehow no?

+1 anyway, sounds very useful!


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-09 18:32 GMT+02:00 Mark Thomas <ma...@apache.org>:

> On 09/06/2017 16:31, Coty Sutherland wrote:
> > Hi all,
> >
> > I was just doing some testing and got had an idea for spinning up new
> > instances of tomcat. JBoss has this system property
> > "-Djboss.socket.binding.port-offset" that I think would be useful for
> > tomcat. As en example, setting the property to 100 on startup would
> > add "100" to all port bindings on the server (e.g. with a vanilla
> > install it would cause tomcat to run on 8105, 8180, and 8109). This
> > prevents uses from having to use a fancy sed (or whatever Windows has)
> > to update the port bindings for every new install. Does anyone else
> > see any value to adding this feature?
>
> I like the idea a lot - apart from the system property part. Would this
> still be as useful if it wasn't a system property?
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: Things that we can do to increase contributor involvement?

2017-06-01 Thread Romain Manni-Bucau
Hi guys,

a quick feedback on that topic:

- github seems to be the preferred way to submit code these days (what we
saw in tomee, batchee etc), it implies almost the same amount of work for
dev (just need to comment if applied or not on github itself for tracking)
so it is a good way probably
- tomcat build not being "standard" can be a stopper for newcomers, I know
migrating to a real maven structure was rejected multiple times but I think
it can help. It would enable to import the project smoothly in any IDE, run
it almost directly from the command line (it is not rare now to not have
ant), and make it easier to browse the structure/package/module




Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-01 15:29 GMT+02:00 Mark Thomas <ma...@apache.org>:

> On 1 June 2017 13:05:18 BST, Coty Sutherland <csuth...@redhat.com> wrote:
>
> >Hm, using Git was mentioned at the TomcatCon but I can't recall if the
> >git repository on github is bi-directional or just a clone of svn. Can
> >anyone answer that?
>
> The ASF hosts a read-only git clone of svn. GitHub has a read-only mirror
> of the ASF repo.
>
> I.e. only ASF svn is read/write.
>
> > Have we made a decision about the best way to
> >submit patches? BZ attachment, github PR, email, other?
>
> BZ or PR are generally best since they are less likely to be forgotten.
>
> > How often do
> >we check the github projects for contributions?
>
> Notifications of PRs get sent to the dev list.
>
> >  We also talked about
> >going over the tomcat 6 and older version BZs to clean them up, maybe
> >we should do the same for github PRs?
>
> 5.5.x and earlier was cleaned up as they went EOL. There are currently 15
> or so 6.0.x BZ entries left to clean up.
>
> >> Anyway, there are PRs there from a few months ago, all the way to a
> >couple
> >> of years ago.  The really old ones should be closed IMO, and suggest
> >to the
> >> contributors to submit again if the issue(s) are still valid.
>
> There is generally a large difference in responsiveness between bugs and
> enhancement requests. Most of the open PRs have been reviewed and are
> waiting for feedback. The others are enhancement requests which typically
> remain open until there is sufficient interest in implementing them.
>
> Yes it would be great to move faster on these. That needs more people
> looking at them. Things are slowly improving - the total open issues is
> trending downwards over time.
>
> Mark
>
>
>  > The
> >newer
> >> ones should be evaluated and feedback should be given to the
> >contributors
> >> You already "found" new contributors -- better spend some time
> >"cultivating"
> >> them than look for new ones who might end up stuck in that same
> >situation.
> >>
> >> The most recent PR ATM -- https://github.com/apache/tomcat/pull/56 --
> >is
> >> from me, and it's only been a few days, so normally I wouldn't have
> >said
> >> anything at this point because it hasn't been "long enough" since I
> >> submitted it.  But then I saw this email and it made perfect sense
> >for me to
> >> chime in.
> >>
> >> It was very important for me to keep my PR as small and simple as
> >possible,
> >> so that it's easy to review and accept or reject.  But there is no
> >feedback
> >
> >Just for future reference, when you submit a PR it's easiest to review
> >if you squash all of the commits into one rather than multiple
> >commits.
> >
> >> whatsoever.  I usually have more time to contribute on the weekends,
> >so if
> >> I'll get some feedback soon, I will hopefully be able to implement
> >whatever
> >> changes necessary on the weekend.  If not, then another week goes by.
> >>
> >> Anyway, I really am not complaining here.  Just providing a
> >perspective from
> >> "the other side".
> >>
> >> All the best, and keep up the good work!
> >
> >I appreciate the perspective and hope to hear more from new
> >contributors :) Thanks again!
> >
> >> Igal
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


  1   2   3   4   >