opment builds.
>
> Or as suggested moved into another context.
>
> I think b) would add too much surprise possibilities for admins/users to
> be worth it.
>
> Felix
>
> >
> >Maybe move the old shiny "root" page to the examples web application.
> >
> >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
>
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion
com/apache/tomcat/tree/8.5.79
> > 1af5f227ae591e601a9426d3788bf6a60a1b75a3
> >
> > The proposed 8.5.79 release is:
> > [ ] Broken - do not release
> >
> [X] Stable - go ahead and release as 8.5.79 (stable)
>
> Filip
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion
8561ba6f3d0bc8890ae15de1
> >
> > The proposed 9.0.63 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 9.0.63 (stable)
>
> Unit tests pass on Linux, Windows and MacOS.
>
> Mark
>
> ---
lease as 10.0.21 (stable)
>
> ---------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion
proposed 10.1.0-M15 release is:
> [ ] Broken - do not release
> [ ] Alpha - go ahead and release as 10.1.0-M15 (alpha)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail:
stable)
>
> Tests pass with Linux, Windows and MacOS
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
; 85113741042dcce9e9792bdbc3d498172bc31291
> >
> > The proposed 9.0.62 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 9.0.62 (stable)
>
> Rémy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion
t; > until they are published or we will be completely open about them up
> front
> > (e.g. if there is a zero day).
> >
> > HTH,
> >
> > Mark
> >
> > ---------
> > To unsubscribe, e
gt; [ ] Broken - do not release
> > [X] Stable - go ahead and release as 10.0.20 (stable)
>
> Rémy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion
; [ ] Broken - do not release
> [ ] Stable - go ahead and release as 9.0.61 (stable)
>
> Rémy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion
and release as 10.0.19 (stable)
>
> -----
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion
roposed 10.1.0-M13 release is:
> [ ] Broken - do not release
> [ ] Alpha - go ahead and release as 10.1.0-M13 (alpha)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-
Hey all,
Regarding tomcat 10.x+
I'm wondering if org.apache.tomcat.jakartaee usage in tomcat-catalina is
intended to be optional?
By the looks of it, I'm thinking not, so it begs the question whether it
should be a proper module; both JPMS and OSGi? Otherwise tomcat-catalina
can never be used in
👍 I'll prepare a pr.
On Sun., Mar. 13, 2022, 1:11 p.m. Mark Thomas, wrote:
> On 13/03/2022 03:07, Raymond Augé wrote:
> > tomcat-catalina imports org.apache.tomcat.util.http.fileupload.impl [1]
> > tomcat-coyote however does not export
> > org.apache.tomcat
tomcat-catalina imports org.apache.tomcat.util.http.fileupload.impl [1]
tomcat-coyote however does not export
org.apache.tomcat.util.http.fileupload.impl
How would you like to address this?
Should tomcat-coyote simply export the package? or should the classes (two
Exceptions) be made part of the
ed (or not!).
>
> Thanks,
> -chris
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion
Lastly, I do agree that if fixed in Java that would be the best case
scenario. However, I am not hopeful.
On Thu, Feb 17, 2022 at 9:08 AM Raymond Augé
wrote:
> Another small point is that the issue is with cleanup more than with
> registration. The Java 17 API has no way to remove fac
. Each product has it's own design an quirks.
On Thu, Feb 17, 2022 at 9:02 AM Raymond Augé
wrote:
> I would like to clarify one small point which may have been missed in my
> description.
>
> The issue is that there is not only tomcat. There are other frameworks in
> the Jav
d 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. 1
Hello all,
There has been a long standing limitation in the JDK w.r.t. the handling of
URLStreamHandlerFactory. Beyond Java 17 this API becomes even more locked
down making dynamic use cases or coordination among frameworks next to
impossible. It appears unlikely to ever be resolved in the JDK.
T
orm but I anticipate that this work will be on the
> back-burner for a while as I have a couple of other things I want to
> look at first.
>
> Mark
>
> -----
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
&
+1
I think it's a great plan.
Ray
On Tue., May 18, 2021, 8:16 a.m. Romain Manni-Bucau,
wrote:
> +1 to move forward even if jakarta is not yet adopted (there is a single
> time direction - at least at our scale ;))
> -0 to break all clones and related toolings/automotion for hypothetical
> reas
he lines of blocking applications from setting specific
> headers and/or header/value combinations.
>
> Thoughts?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional
ook
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow
used with an API that doesn't have the Tomcat implementation as the
> hard-coded default.
>
> What is the concern with using the @ServiceProvider annotation to enable
> Bnd to generate the correct meta data?
>
> Mark
>
>
> >
> >
> > Le jeu. 22
On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé,
wrote:
> @ServiceProvider is just a hint no?
>
> It does not change the implementation behavior... Unless you've found
> otherwise, which would be surprising.
>
To be clear, there is no runtime behavior associated with @Serv
Are you maybe in JPMS mode?
On Thu., Apr. 22, 2021, 9:51 a.m. Raymond Augé,
wrote:
>
>
> On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé,
> wrote:
>
>> @ServiceProvider is just a hint no?
>>
>> It does not change the implementation behavior... Unless you'
@ServiceProvider is just a hint no?
It does not change the implementation behavior... Unless you've found
otherwise, which would be surprising.
Ray
On Thu., Apr. 22, 2021, 9:29 a.m. Romain Manni-Bucau,
wrote:
> Hi all,
>
> Websocket server configurator uses the SPI to load the impl and if not
However, I
wasn't sure that this would cover all cases particularly w.r.t. the service
loader handling. However, it appears it does.
Sincerely,
Ray
On Tue, Apr 6, 2021 at 10:39 AM Mark Thomas wrote:
> On 02/04/2021 13:58, Raymond Augé wrote:
> > I just wanted to make a note that remo
a failure that we
> > >> consider can be safely ignored.
> > >>
> > >> Tomcat does not, and has not for many, many years, formally certified
> > >> against the Jakarta EE / Java EE TCKs. I am not aware of any user
> > >> request at any point in that time to complete formal certification.
> > >> Therefore, I expect that Tomcat will continue following its current
> > >> pragmatic approach to the TCKs.
> > >>
> > >> Mark
> > >>
> > >> -
> > >> 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
> >
> >
>
> --
> Jean-Louis
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow
30 matches
Mail list logo
