next release
Hi, i'm participating to Apache OpenEJB project and we would like to release this mounth. However we are interested by (at least) one fix in tomcat 7.0.24. Any planned date for this release? Thanks - Romain
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Hi, i agree on the fact maven is technically more complicated than an ant script but let say you know both maven and ant, your ant script is very complicated to do almost nothing useful. (ok i prefer maven ;)). For newcomers i think it is important. Maven stuff can be almost hidden by a good IDE, complicated ant script can't be hidden by an IDE. Well as said earlier it can be a troll so i'll not speak about it more. What i wanted to add is tomcat starts to be widely used by othes projects (i particularly think of OpenEJB) and maven is almost everywhere used (OpenEJB, Geronimo, Siwpas...). So another question is do you want to be more open to other communities. - Romain 2011/12/19 Mark Thomas > On 19/12/2011 08:36, Antonio Petrelli wrote: > > 2011/12/17 Mark Thomas > > > >> On 17/12/2011 20:24, Antonio Petrelli wrote: > >>> Ok, let's do it again :-D > >>> 1. Standardization. Maven strongly encourages to use a standardized > >>> structure. The source should go into src/main/java, the resources in > >>> src/main/resources etc. You can change it, but this is discouraged. > With > >>> Ant you always do things differently for different projects. > >> > >> What benefit is this to the Tomcat community? I see a change, but no > >> benefit. > >> > > > > So standardization is no benefit? Do you mean that an external developer, > > that sees a common project structure that can start working on it easily, > > is not a benefit? > > I agree that being able to start working on something easily is a > benefit. Where we disagree is how important standardisation and Maven > helps. > > Maven may add standardisation but it also adds complexity. Too much > happens under the hood for my liking. You need a much better > understanding of the tool to figure out what is going on. I think that > makes it harder to get started than the current Ant script. I suspect we > just aren't going to agree on this since one's view will change > depending on how well one understands Mavem. You understand it very > well. I understand it hardly at all. > > >>> 2. Modularization. Separation between modules is strong, i.e. one > jar-one > >>> source directory. In the case of Tomcat, there is a big big trouble: > one > >>> single big source directory. Separating them will be one of the most > >>> important step to do. > >> > >> Why is that an issue? Switching to a single source tree was one of the > >> best changes we ever made. It has been much easier to manage than the > >> multiple source trees we had in the past. > > > > > > Sincerely, this is the worst thing that you have made. Do you think that > > having a single source tree and letting Ant script reconstruct in some > > non-obvious way the jars, is a benefit? > > A single source tree has been a huge benefit. The code is much easier to > work with. I'm happy to pay the price of the way the JARs are created to > be able to work with a single source tree. > > >> The dependencies are known and > >> we have checks in place (via Checkstyle) to ensure that unwanted > >> dependencies are not added. > > > > Checkstyle checks unwanted *imports* not dependencies. > > Agreed, but they are equivalent as makes no difference when talking > about dependencies between the JARs (as I was). > > >> Again, what is the benefit here to the > >> Tomcat community? There has been some interest but very little activity > >> towards greater modularity. If there was more interest in increasing > >> modularity then there might be a case for this but given Tomcat's remit > >> of implementing the Servlet and JSP specs there is very little that > >> could be made modular / optional. Jasper and EL are already optional > >> (well, they can be removed) and pretty much everything else is required > >> by the Servlet spec. > >> > > > > Real modularity means: one source directory -> one jar. In other cases, > it > > is not obvious. > > Again, what is the benefit? > > >>> 3. Metadata-driven process. The build process is driven by metadata > >> (where > >>> the source is? where should I deploy it?) and not by commands (compile > >> the > >>> source that is in that point, deploy it in that repository) > >> > >> Again, how does this benefit the Tomcat community? > >> > > > > The benefit is that the pom.xml is similar to other projects. After you > see > > a kind of project, you see almost them all. > > As above, similar but in my view more complex. I suspect how comfortable > you are with Maven determines which you think is best and not everyone > has your level of skill with Maven. > > >>> 4. POMs are (almost) universal. Projects of the same kind have almost > the > >>> same content.. > >> > >> How does this benefit the Tomcat community? > >> > > > > See above. > > Ditto. > > >>> 5. Plug-ins do generically what pieces of Ant's script do specifically. > >> For > >>> example take the Maven assembly plugin: via a descriptor you obtain a > zip > >>> file to distribute. > >> > >> That sounds like just a different way of doing th
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
There is a big part of tomcat which doesn't need maven because it doesn't need to be standard (the installers are a great example). I spoke about the common part which is today not obvious because of the false modularity of the project. - Romain 2011/12/19 Mladen Turk > On 12/19/2011 07:47 PM, David Jencks wrote: > >> Are you reading the thread? I mentioned dec 17 that geronimo has been >> maintaining a script for 2+ years that pulls tomcat source out of tomcat >> svn and puts it in an appropriately structured maven mutli-project build >> and we've been re-releasing quite a few tomcat versions using this >> technique. Not sure how this is "talk". I've experienced enough hostility >> over the years from the tomcat community (not necessarily any currently >> active members) that I'm reluctant to spend more time on this. >> > > And that relates to this thread in exactly which way? > You guys did that for Geronimo, fine, great, super. > > Here we speak that we should replace entire Tomcat > build system with maven, meaning, multiple arches, creating > windows installer, etc. I don't see any of those in Geronimo. > > All I'm saying, if you can do it, you're welcome. > I'd like to see 'ant release' using 'mvn release' before > someone breaks trunk. > > > Regards > -- > ^TM > > > --**--**- > To unsubscribe, e-mail: > dev-unsubscribe@tomcat.apache.**org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
because developers can't know both? we use both on OpenEJB (ok the ant part is small but it is used through the maven plugin). I don't know if it is because i used more maven than ant but when i checked out tomcat the first time i wondered where was modules (corresponding to jars). I was doing the same with ant. So i don't say use mvn or ant even if IMHO mvn could be a benefit for the community. I just say be consistent with your artifacts. - Romain 2011/12/19 Mladen Turk > On 12/19/2011 08:58 PM, Romain Manni-Bucau wrote: > >> There is a big part of tomcat which doesn't need maven because it doesn't >> need to be standard (the installers are a great example). >> >> > Installer is just ant exec task with some filtering > for getting the versions correctly. > We have multiple release artifacts using different compressors > having different line endings, so I suppose that would > stay with ant as well. > > > I spoke about the common part which is today not obvious because of the >> false modularity of the project. >> >> > So it would be ant + maven I suppose. > Fine, who's gonna do it and maintain? > > > > Regards > -- > ^TM > > --**--**- > To unsubscribe, e-mail: > dev-unsubscribe@tomcat.apache.**org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
i needed to dig into tomcat for some bugs regarding TCKs. That's why i needed more. - Romain 2011/12/19 jean-frederic clere > On 12/19/2011 07:47 PM, David Jencks wrote: > >> Are you reading the thread? I mentioned dec 17 that geronimo has >> been maintaining a script for 2+ years that pulls tomcat source out >> of tomcat svn and puts it in an appropriately structured maven >> mutli-project build and we've been re-releasing quite a few tomcat >> versions using this technique. Not sure how this is "talk". I've >> experienced enough hostility over the years from the tomcat community >> (not necessarily any currently active members) that I'm reluctant to >> spend more time on this. >> > > So starting with what is in the geronimo repo, how much work would it to > have a "mavenized" Tomcat? > > >> As I have said before in previous iterations of this topic, IMO many >> of the advantages of maven are not for direct development of the >> project itself (although they certainly exist) but in encouraging >> interactions with other projects and communities. You won't be able >> to detect these without actually using maven. >> > > We already publish artifacs, do you need more of them? > > Cheers > > Jean-Frederic > > > --**--**- > To unsubscribe, e-mail: > dev-unsubscribe@tomcat.apache.**org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
+1 - Romain 2011/12/20 David Jencks > > On Dec 19, 2011, at 1:06 PM, jean-frederic clere wrote: > > > On 12/19/2011 07:47 PM, David Jencks wrote: > >> Are you reading the thread? I mentioned dec 17 that geronimo has > >> been maintaining a script for 2+ years that pulls tomcat source out > >> of tomcat svn and puts it in an appropriately structured maven > >> mutli-project build and we've been re-releasing quite a few tomcat > >> versions using this technique. Not sure how this is "talk". I've > >> experienced enough hostility over the years from the tomcat community > >> (not necessarily any currently active members) that I'm reluctant to > >> spend more time on this. > > > > So starting with what is in the geronimo repo, how much work would it to > have a "mavenized" Tomcat? > > I did this work and suggested tomcat look at it several years ago, and > don't remember all the details, some other people have been maintaining it > recently. IIRC the maven projects generate pretty much the same jars as > the ant build, possibly plus one more to get around the circular > dependencies among the jars. So to generate a maven multimodule project to > build the jars, 20 min to configure the script that builds the project, > then you have a mavenized tomcat project checked in that builds pretty much > the same jars as the ant build. I don't really know what else the ant > build generates. > > > > >> > >> As I have said before in previous iterations of this topic, IMO many > >> of the advantages of maven are not for direct development of the > >> project itself (although they certainly exist) but in encouraging > >> interactions with other projects and communities. You won't be able > >> to detect these without actually using maven. > > > > We already publish artifacs, do you need more of them? > > I think the benefit might be more on the order of encouraging people who > ask "where did this jar come from-- I wanna fix something". For people > familiar with maven, there is IMO a much higher barrier to contributing to > tomcat than a well-structured maven project. (BTW I must add that I'm > delighted that the tomcat community seems much more receptive to outside > input than it did several years ago -- community unfriendliness seems to be > totally missing now :-) ). > > thanks > david jencks > > > > > Cheers > > > > Jean-Frederic > > > > - > > 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 > >
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Another good thing in gradle is its incremental build support. - Romain 2011/12/20 Pid > On 20/12/2011 08:38, Antonio Petrelli wrote: > > 2011/12/19 Pid > > > >> On 18/12/2011 08:37, Mladen Turk wrote: > >>> On 12/17/2011 09:24 PM, Antonio Petrelli wrote: > As requested here is a proposal to move to Maven. > > >>> > >>> I simply cannot understand why some folks have > >>> almost religious fascination with Maven. > >>> > >>> I know many projects that have move from Ant to > >>> Maven and are now either switched back or gone to > >>> some other solution like Gradle or are in the > >>> active process of seeking the alternative. > >> > >> I was wondering if someone would mention Gradle. If there's a build > >> tool shootout to be had, Gradle should get fair consideration. > >> > > > > I tried Gradle some time ago and, IMHO, it is pretty slow compared to > Maven > > 3. > > Gradle are releasing frequently, it would be worth trying again. > > > > Moreover, m2eclipse and Maven have some developers in common and are > doing > > a great work to integrate the various plugins. The Eclipse-Gradle plugin > > seems not much mature IMHO. > > Have you tried that recently? It has been working OK for me - but then > I prefer to do the build stuff from the CLI anyway. > > > > However, point in the right direction if I missed something :-) > > Plenty of new things to read in the changelog. > > A notable feature of Gradle is that it does not require the build tool > to be pre-installed, it provides a wrapper mechanism that downloads the > specified version of the tool when it runs. > > I think that the syntax of the Gradle DSL is easier to understand than > Maven (certainly for new users) and it happily integrates with various > of the popular repos and other build tool plugins. > > Seems like the best of both worlds to me. > > > p > > > -- > > [key:62590808] > >
Re: Who wants my Cassandra session manager for Tomcat?
Hi, Maybe it should be posted to cassandra list? - Romain Le 3 avr. 2012 18:52, "Pid" a écrit : > On 03/04/2012 09:56, Morten Jorgensen wrote: > > All, > > > > I recently implemented a Tomcat session manager that uses Cassandra for > > session storage. Cassandra is a commonly used session store for > > PHP-based applications, but I could not find one that would plug > > seamlessly into Tomcat. My Cassandra session manager is fully working > > and has gone through basic testing. > > > > Now I want to donate my code to the Tomcat project - if you'll have it. > > I am unsure on how to proceed with this, so any direction will be very > > much appreciated. I did manage the donation of XSLTC from Sun > > Microsystems to the Xalan-J project at xml.apache.org way back when, > > but this was more than 10 years ago and my memory isn't great... > > I can't speak for the committers/project, but one option would be to > file an enhancement request and attach a patch in diff format. > > Whether it gets added or not would depend on the committers' opinion > about the value of the feature & the impact of adding dependencies etc. > > Is there a community of users already, or is it too new? > > > > Apologies if this is the wrong forum for this request. > > It's the right forum. > > > p > > > Best regards, > > Morten Jorgensen > > > > > -- > > [key:62590808] > >
tomcat & deploywar & context.xml
Hi, how does tomcat manage context.xml at startup? from what i saw it uses org.apache.catalina.startup.HostConfig.DeployWar but in org.apache.catalina.startup.HostConfig#deployWAR it reads the context.xml file before overriding it with contextname info which ignores the context.xml file: context.setName(cn.getName()); context.setPath(cn.getPath()); context.setWebappVersion(cn.getVersion()); context.setDocBase(cn.getBaseName() + ".war"); did i miss sthg or is it a bug? - Romain
Re: tomcat & deploywar & context.xml
ok thank you for the quick answer sorry to have missed it on the website - Romain 2012/5/21 Konstantin Kolinko > 2012/5/21 Romain Manni-Bucau : > > Hi, > > > > how does tomcat manage context.xml at startup? > > > > from what i saw it uses org.apache.catalina.startup.HostConfig.DeployWar > > but in org.apache.catalina.startup.HostConfig#deployWAR it reads the > > context.xml file before overriding it with contextname info which ignores > > the context.xml file: > > > >context.setName(cn.getName()); > >context.setPath(cn.getPath()); > >context.setWebappVersion(cn.getVersion()); > >context.setDocBase(cn.getBaseName() + ".war"); > > > > > > did i miss sthg or is it a bug? > > > > 1. There are several context.xml files (App's context.xml, Host's > "context.xml.default" file, common conf/context.xml). See Context in > config. reference for details. > > 2. App's context.xml is read twice, with different configuration of > Digester. > > When it is read by the second time, the name etc. are ignored. > > That relates with the following documented feature: You cannot specify > path attribute on Context in app's own context.xml, because it is > already known a-priori from the name and location of the context file > itself. > > The name and version are calculated from path. > > The same with docBase. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
RE: tomat-jdbc & hashCode
Thanks :) Le 7 août 2012 02:17, "Filip Hanik (mailing lists)" a écrit : > Fixed in > r1370074 and r1370075 > > http://svn.apache.org/viewvc?rev=1370075&view=rev > http://svn.apache.org/viewvc?rev=1370074&view=rev > > > > -Original Message- > > From: Filip Hanik Mailing Lists [mailto:devli...@hanik.com] > > Sent: Monday, July 30, 2012 5:58 AM > > To: Tomcat Developers List > > Subject: Re: tomat-jdbc & hashCode > > > > nope, I will fix that > > > > Filip > > > > - Original Message - > > > From: "Romain Manni-Bucau" > > > To: "Tomcat Developers List" > > > Sent: Tuesday, July 24, 2012 5:18:32 PM > > > Subject: tomat-jdbc & hashCode > > > > > > Hi, > > > > > > just noticed tomcat jdbc doesn't manage hashCode if the connection is > > > already close (it is in org.apache.tomcat.jdbc.pool.JdbcInterceptor). > > > Any > > > reason to do so? > > > > > > > > > - Romain > > > > > > > - > > 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 > >
Re: pooledconnection & tccl?
if the resource is an app resource it should be closed with the stop() and recreated with the start *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/8/22 Pid * > On 19 Aug 2012, at 19:11, Romain Manni-Bucau > wrote: > > > Hi, > > > > org.apache.tomcat.jdbc.pool.PooledConnection#connectUsingDriver uses > tomcat > > classloader to create the driver, couldn't it be the TCCL? > > > > this way it could allow to provide the driver in the webapp. > > What would happen if the app is reloaded? > > > p > > > > > > > > *Romain Manni-Bucau* > > *Twitter: @rmannibucau* > > *Blog: http://rmannibucau.wordpress.com* > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Performance degrade
Think thats linked to the always scan of servlet 3 (first versions were scanning only for web.xml in version 3, now version is igmored for the scanning) Le 28 oct. 2012 09:21, "Mark Thomas" a écrit : > David Blevins wrote: > > >Seems there was a measurable decrease in large app deploy time between > >Tomcat 7.0.28 and 7.0.29. I haven't yet had time to dig in with a > >profiler. Hoping someone might go "oh, that's when we changed X" and > >have a tip or two. > > No need for a profiler. The changelog for 7.0.29 should be all you need. > Also, these are questions for the users list, not the dev list. A look in > the users archives is likely to be informative. > > Mark > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
websocket tomcat listener API?
Hi guys, Would it be possible to add to tomcat codebase a way to register custom websocket lifecycle listeners for technical integration. For instance in TomEE we would need a clean way to listen for close() or timeout() without modifying the user code side if possible. wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com>
Re: websocket tomcat listener API?
Here is the use case: we make these endpoints go through the javee instance manager. Being a ee server we support @Inject and in some cases - sadly the most common one - we need a cleanup hook once the endpoint is no more used. Strictly at tomcat level think to postconstruct/predestroy support for instance. Side note: when i spoke about timeout i thought to WsTimeout. Main point is to know when to release the instance. Note also it would be awesome to have it for tomcat 8 :). Le 4 nov. 2015 00:57, "Rémy Maucherat" a écrit : > > 2015-11-04 9:47 GMT+01:00 Mark Thomas : > > > On 04/11/2015 06:28, Romain Manni-Bucau wrote: > > > Hi guys, > > > > So you only want the views of the male committers? > > > > > Would it be possible to add to tomcat codebase a way to register custom > > > websocket lifecycle listeners for technical integration. For instance in > > > TomEE we would need a clean way to listen for close() or timeout() > > without > > > modifying the user code side if possible. > > > > Why? What is the use case? > > > > Also, there is no timeout() method but there is an error() method. There > > is no clear way to differentiate between timeout and any other errors. > > > > > wdyt? > > > > Looking at trunk, it appears to be doable with some refactoring but > > there would be a (probably small) performance impact. It depends on the > > justification. > > > > Maybe it could be the usual integration thing, for example at the moment > the endpoint instances are not going through the InstanceManager. Not sure > if that would be enough for him. Obviously a listener system would be much > more annoying (configuration needed, etc ...). > > Rémy
Re: websocket tomcat listener API?
Yes, and would avoid a custom configurator :). Le 4 nov. 2015 06:09, "Rémy Maucherat" a écrit : > 2015-11-04 14:55 GMT+01:00 Romain Manni-Bucau : > > > Here is the use case: we make these endpoints go through the javee > instance > > manager. Being a ee server we support @Inject and in some cases - sadly > the > > most common one - we need a cleanup hook once the endpoint is no more > used. > > > > Strictly at tomcat level think to postconstruct/predestroy support for > > instance. > > > > Side note: when i spoke about timeout i thought to WsTimeout. Main point > is > > to know when to release the instance. > > > > Note also it would be awesome to have it for tomcat 8 :). > > > > So if websockets was using the instance manager to get/destroy endpoint > instances (it does for Servlets / JSP tags / etc, but not that at the > moment) it would likely work for you, right ? > > Rémy >
Re: websocket tomcat listener API?
That is what I thought but extending WsSession in t8 is hard. Le 4 nov. 2015 06:45, "Rémy Maucherat" a écrit : > 2015-11-04 15:16 GMT+01:00 Romain Manni-Bucau : > > > Yes, and would avoid a custom configurator :). > > > > In way the difficulty is that the configurator takes over the instance > creation, but doesn't care about its destruction. If the default Tomcat > configurator took care of newInstance, the tracking would fail if the > configurator is replaced. Not very good. So the > InstanceManager.newInstance(Object o) should always be used instead IMO > after delegating instance creation to whatever configurator is present. > Maybe from WsSession (since it's in a good position to call destroyInstance > as well). > > Rémy >
Re: websocket tomcat listener API?
2015-11-04 8:43 GMT-08:00 Rémy Maucherat : > 2015-11-04 15:59 GMT+01:00 Romain Manni-Bucau : > > > That is what I thought but extending WsSession in t8 is hard. > > > > Probably. > > So I'll see about porting it to Tomcat 8 if feedback is ok. > > However, I have two new problems: > - I noticed during testing that the upgrade handler instance is created > through the instance manager, but never destroyed > there is not only fireClose case I think, if the client disconnect brutally you skip this part I think, isn't it? > - the websockets client endpoint instances won't go through the instance > manager > this is fine IMO as a first big step, client endpoints are easier to integrate in client code since you - the user - handle the connection. > For both of these situations, it would likely have to work through a static > CL map, like naming does. > > Rémy >
Re: websocket tomcat listener API?
I see, will it be "fixed" or should it be worked-around with a BackgroundProcess - that is what we use ATM in TomEE SNAPSHOT code? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-11-04 8:57 GMT-08:00 Rémy Maucherat : > 2015-11-04 17:46 GMT+01:00 Romain Manni-Bucau : > > > there is not only fireClose case I think, if the client disconnect > brutally > > you skip this part I think, isn't it? > > > > It is always called, but the websockets code isn't very rich on finally, so > if something really unexpected occurs during the close process, it won't > get called in some cases. It would need a finally on every line, so ... > > Rémy >
access log valve not using logger?
Hi guys, any reason the AccessLogValve doesnt rely on JULI - https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/valves/AccessLogValve.java#L515 ? Makes it quite complicated to extend the logging logic or use another logging framework with more rotation policy for instance. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: access log valve not using logger?
+1, that is more or less what I just hacked for tomcat 7/8.
Romain Manni-Bucau
@rmannibucau | Blog | Github | LinkedIn | Tomitriber
2015-11-20 12:01 GMT-08:00 Christopher Schultz :
> Romain,
>
> On 11/20/15 2:44 PM, Romain Manni-Bucau wrote:
>> any reason the AccessLogValve doesnt rely on JULI -
>> https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/valves/AccessLogValve.java#L515
>> ?
>
> Because JULI is slow, and we want logging to be fast.
>
> Logging frameworks are super-flexible, let you add/remove information at
> runtime and do things like conditionally-log messages or even
> conditionally filter them as they are going to log sinks (like a
> specific file for instance). For an access log, you pretty much always
> want to log everything. There's no reason for all those options.
>
>> Makes it quite complicated to extend the logging logic or use another
>> logging framework with more rotation policy for instance.
>
> The rotation policy for the access logger is certainly crude.
>
> I don't believe AccessLogValve was really intended to be extensible...
> that's what AbstractAccessLogValve is for: just write your own subclass
> like this:
>
> public class FrameworkAccessLogValve extends AbstractAccessLogValve {
> private Log log;
> private Level level;
> public void setLog(Log log) { this.log = log; }
> public Log getLog() { return this.log; }
> public void Level setLevel(Level level) { this.level = level; }
> public Level getLevel() { return this.level; }
>
> @Override
> protected abstract void log(CharArrayWriter message) {
> getLog().log(getLevel(), message);
> }
> }
>
> If you think that kind of thing would be useful in Tomcat, I suppose we
> could commit it.
>
> -chris
>
> -
> 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
Re: [VOTE] Release Apache Tomcat 9.0.10
+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: Dynamic reloading of SSL certificates
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: Dynamic reloading of SSL certificates
+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 > >
Don't require a base directory?
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: Don't require a base directory?
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> >
bug in 8.5.0?
Hi guys, if I'm not mistaken org.apache.catalina.loader.WebappClassLoaderBase#getResourceAsStream can throw a NPE: 1090. URL url = super.findResource(name); 1091. stream = url.openStream(); // url can be null Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: bug in 8.5.0?
Thanks Violeta. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-24 20:29 GMT+01:00 Violeta Georgieva : > Hi, > > 2016-03-24 21:01 GMT+02:00 Romain Manni-Bucau : >> >> Hi guys, >> >> if I'm not mistaken >> org.apache.catalina.loader.WebappClassLoaderBase#getResourceAsStream >> can throw a NPE: >> >> 1090. URL url = super.findResource(name); >> 1091. stream = url.openStream(); // url can be null >> > > Thanks for the report. > The fix will be in 8.5.1 > > Regards, > Violeta > >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >> - >> 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
8.5.1?
Hi guys, any plan to do a 8.5.1? I'd like to upgrade tomee and remove the workaround we have for the NPE in the webapp classloader with custom repositories. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>
Re: 8.5.1?
Ok thanks! Le 14 avr. 2016 21:50, "Mark Thomas" a écrit : > On 14/04/2016 15:39, Romain Manni-Bucau wrote: > > Hi guys, > > > > any plan to do a 8.5.1? I'd like to upgrade tomee and remove the > workaround > > we have for the NPE in the webapp classloader with custom repositories. > > 8.5.0 was so close to the end of March it didn't make sense to do an > April release so the next release is pencilled in for the beginning of May. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
tomcat 7 broken on java 7 for linux distro
Hi guys, tomcat uses ConcurrentHashMap in few places and doesn't rely on ConcurrentMap API (ApplicationContext IIRC for instance was the case I encounter). This means if you build tomcat with java 8 and run on java 7 it is broken cause of this new KeyViewSet API used on java 8 (returned type is used for method lookup at runtime). Why would you do it? Not sure but several linux distribution do it. I know we could easily ask all linux distro to build using java 7 but at least fedora/redhat/ubuntu are impacted and tomcat can easily without loosing any feature make it passing for that case using the interface instead of the implementation as field type. Do you think it is possible or would you just move it over linux distro? If this last one: how to ensure we don't get more regression in the future due to another build process for user binaries? Thanks, Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>
Re: tomcat 7 broken on java 7 for linux distro
Only met it on previous LTS (16.04 is still fresh so was 14 one). So sounds it was a no luck case. Maybe a page on tomcat website dealing with main integrations and things to check (/etc/defaults/tomcatX JAVA_HOME etc...) can be enough for this issue. What do you think? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-04-25 18:18 GMT+02:00 Emmanuel Bourg : > Le 25/04/2016 17:42, Romain Manni-Bucau a écrit : > > > I know we could easily ask all linux distro to build using java 7 but at > > least fedora/redhat/ubuntu are impacted and tomcat can easily without > > loosing any feature make it passing for that case using the interface > > instead of the implementation as field type. > > Debian and Ubuntu usually build and run Tomcat with the same version of > Java. For example Ubuntu 16.04 LTS and the upcoming Debian 9 default to > Java 8 (Java 7 has been removed). Tomcat 7 is no longer supported for > these versions (Ubuntu switched to Tomcat 8 and Debian will remove it in > a few months, the general rule is to keep only one version of Java and > Tomcat per major release). In the previous release Tomcat 7 was built > with Java 7. > > This issue may arise if the user installs its own Java 7 and use it to > run Tomcat instead of the JRE provided by the distribution. I can > address that in Debian by ensuring the package dependencies are more > strict (please file a bug against the tomcat8 package if it's affected > too). > > Emmanuel Bourg > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: tomcat 7 broken on java 7 for linux distro
Just to make it clearer: 14.04 had java 7 as expected but tomcat7 package was compiled with java 8. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-04-25 18:45 GMT+02:00 Emmanuel Bourg : > Le 25/04/2016 18:32, Romain Manni-Bucau a écrit : > > Only met it on previous LTS (16.04 is still fresh so was 14 one). So > sounds > > it was a no luck case. > > That's odd because Ubuntu 14.04 LTS doesn't have Java 8 [1]. It first > appeared in Ubuntu 15.10. Tomcat 7 in Ubuntu 14.04 LTS is built with Java > 7. > > Emmanuel Bourg > > http://packages.ubuntu.com/search?keywords=openjdk-8-jre-headless > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: tomcat 7 broken on java 7 for linux distro
Not sure what happent, got the same it in one of my box (but was 15.10 so can't explain the feedback i got with 14.04). Maybe a package update. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-04-25 21:41 GMT+02:00 Emmanuel Bourg : > Le 25/04/2016 18:50, Romain Manni-Bucau a écrit : > > Just to make it clearer: 14.04 had java 7 as expected but tomcat7 package > > was compiled with java 8. > > This shouldn't be possible. Ubuntu packages are built in a clean > environment with no packages or applications not in the distribution. > Ubuntu 14.04 doesn't have Java 8 and therefore official packages can't > be compiled with Java 8. If you look at the build log [1] for the > version of Tomcat 7 currently distributed for Ubuntu 14.04 you'll see > that Java 7 was used. > > Emmanuel Bourg > > [1] > > https://launchpadlibrarian.net/209543797/buildlog_ubuntu-trusty-i386.tomcat7_7.0.52-1ubuntu0.3_BUILDING.txt.gz > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: tomcat 7 broken on java 7 for linux distro
Le 26 avr. 2016 22:27, "Christopher Schultz" a écrit : > > Romain, > > On 4/25/16 11:42 AM, Romain Manni-Bucau wrote: > > Hi guys, > > > > tomcat uses ConcurrentHashMap in few places and doesn't rely on > > ConcurrentMap API (ApplicationContext IIRC for instance was the case I > > encounter). This means if you build tomcat with java 8 and run on java 7 it > > is broken cause of this new KeyViewSet API used on java 8 (returned type is > > used for method lookup at runtime). > > Which method, here? The return type of a method isn't officially part of > the method's signature. Are you saying that the Java 8 compiler will > choose a method (from a specific interface) at compile-time that doesn't > exist in earlier versions of Java? > > Can this be fixed with a cast? > This is not java 8 specific. The method lookup is done using return type too - check bytecode with javap for instance. I didnt check if a cast fixes it but using a temp var should or moving the impl typing to the interface at field level fixes it in tomcat and no api is missing AFAIK. > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org >
Re: tomcat 7 broken on java 7 for linux distro
from what I saw in commit mails it seems so. Does it still worth a page explaining linux distro rebuild tomcat and how to check the java version (reading MANIFEST.MF from catalina.jar for instance) in case it happens again or someone hits it short term? Thanks to have taken it into consideration anyway. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-04-27 13:41 GMT+02:00 Mark Thomas : > On 27/04/2016 00:03, Mark Thomas wrote: > > On 25/04/2016 16:42, Romain Manni-Bucau wrote: > >> Hi guys, > >> > >> tomcat uses ConcurrentHashMap in few places and doesn't rely on > >> ConcurrentMap API (ApplicationContext IIRC for instance was the case I > >> encounter). This means if you build tomcat with java 8 and run on java > 7 it > >> is broken cause of this new KeyViewSet API used on java 8 (returned > type is > >> used for method lookup at runtime). > >> > >> Why would you do it? Not sure but several linux distribution do it. > >> > >> I know we could easily ask all linux distro to build using java 7 but at > >> least fedora/redhat/ubuntu are impacted and tomcat can easily without > >> loosing any feature make it passing for that case using the interface > >> instead of the implementation as field type. > >> > >> Do you think it is possible or would you just move it over linux distro? > > > > I've been through the source code and I have a patch locally ready to > > commit that fixes this in 9.0.x. However... > > > > In some places, this would mean changing the API (usually a protected > > field) of an internal component we might reasonably expect some users to > > have extended. That is generally something we try and avoid in a point > > release unless the change is absolutely necessary (e.g. security) or we > > view the chances of it being used as very, very low. > > > > Therefore, I want to review my local changes and split them into two > > commits. The safe one and the API breaking one. I'm not sure the API > > breaking one is going to be back-ported beyond 8.5.x. > > > > Fundamentally, this is an issue for the distro. The Tomcat docs are > > quite specific (see BUILDING.txt) about which version of Java should be > > used to build Tomcat. If a distro wants to mess with that, they get to > > deal with the consequences. > > > >> If > >> this last one: how to ensure we don't get more regression in the future > due > >> to another build process for user binaries? > > > > This is generally something we check during the release. It is mostly a > > manual process although it is automated where building with the wrong > > Java version causes issues for DBCP. > > After rather more commits than I expected (it was easier top review > package by package than all in one go) I think this is fixed. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Small typo in title on security-9 page
Hi guys, If like me you use chrome the tabs are likely too small to see it but check the window title of https://tomcat.apache.org/security-9.html, it is " Apache Tomcat® - Apache Tomcat 8 vulnerabilities" which looks like a copy/paste. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>
Re: Small typo in title on security-9 page
After having cleaned the cache yes. Thanks! Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-05-10 16:55 GMT+02:00 Violeta Georgieva : > Hi, > > 2016-05-10 17:45 GMT+03:00 Romain Manni-Bucau : > > > > Hi guys, > > > > If like me you use chrome the tabs are likely too small to see it but > check > > the window title of https://tomcat.apache.org/security-9.html, it is " > > Apache Tomcat® - Apache Tomcat 8 vulnerabilities" > which > > looks like a copy/paste. > > > > Thanks for the report. > It should be OK now. > > Regards, > Violeta > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > > <http://www.tomitribe.com> | JavaEE Factory > > <https://javaeefactory-rmannibucau.rhcloud.com> >
NPE in StandardJarScanner
Hi guys, org.apache.tomcat.util.scan.StandardJarScanner#processManifest does: Manifest manifest = jar.getManifest(); Attributes attributes = manifest.getMainAttributes(); Please note that manifest can be null so another NPE should be added Thanks, Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>
Re: NPE in StandardJarScanner
Thanks Violeta for the fix! Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-05-16 22:53 GMT+02:00 Romain Manni-Bucau : > Hi guys, > > org.apache.tomcat.util.scan.StandardJarScanner#processManifest does: > > Manifest manifest = jar.getManifest(); > Attributes attributes = manifest.getMainAttributes(); > > Please note that manifest can be null so another NPE should be added > > Thanks, > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> >
8.5.2 async state?
Hi guys,
on 8.5.2 this code doesn't work anymore (in a valve):
if (!request.isAsync()) {
getNext().invoke(request, response);
} else {
request.getAsyncContext().addListener(...);
getNext().invoke(request, response);
}
Issue is isAsync() = true but getAsyncContext() throws an exception since
isAsyncStarted() = false.
Was it intended?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
Re: 8.5.2 async state?
Only found https://bz.apache.org/bugzilla/show_bug.cgi?id=59261 which
doesn't mean this code would be invalid
Also if you add a listener eagerly you will have the start event and loose
all "end" (completed, timeout etc...) ones. This doesn't sound very
reliable.
Can you point me out the related issue please?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-05-17 12:26 GMT+02:00 Mark Thomas :
> On 17/05/2016 11:24, Romain Manni-Bucau wrote:
> > Hi guys,
> >
> > on 8.5.2 this code doesn't work anymore (in a valve):
> >
> > if (!request.isAsync()) {
> >
> > getNext().invoke(request, response);
> >
> > } else {
> > request.getAsyncContext().addListener(...);
> > getNext().invoke(request, response);
> > }
> >
> > Issue is isAsync() = true but getAsyncContext() throws an exception since
> > isAsyncStarted() = false.
> >
> > Was it intended?
>
> Yes. It is in the change log.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: 8.5.2 async state?
the real issue is adding a listener there trigger onStartAsync()*ONLY* (no onCompleted(), onTimeout(), onError() etc... cause org.apache.catalina.core.AsyncContextImpl#setStarted does listeners.clear(); ) Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-05-17 12:43 GMT+02:00 Rémy Maucherat : > 2016-05-17 12:37 GMT+02:00 Romain Manni-Bucau : > > > Only found https://bz.apache.org/bugzilla/show_bug.cgi?id=59261 which > > doesn't mean this code would be invalid > > > > Also if you add a listener eagerly you will have the start event and > loose > > all "end" (completed, timeout etc...) ones. This doesn't sound very > > reliable. > > > > Can you point me out the related issue please? > > > > The bugzilla title says: "Request getAsyncContext should throw > IllegalStateException if async is not started". So that's what happens now. > > Rémy >
Re: 8.5.2 async state?
I see, that's however a regression for tomcat users. could the async
listener wrapper impl this if a tomcat flag is switched on?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-05-17 13:03 GMT+02:00 Violeta Georgieva :
> Hi,
>
> 2016-05-17 13:46 GMT+03:00 Romain Manni-Bucau :
> >
> > the real issue is adding a listener there trigger onStartAsync()*ONLY*
> (no
> > onCompleted(), onTimeout(), onError() etc... cause
> > org.apache.catalina.core.AsyncContextImpl#setStarted does
> listeners.clear();
> > )
> >
>
> That's behaviour is by spec:
>
> "public void addListener(AsyncListener) - Registers the given listener for
> notifications of onTimeout, onError, onComplete or onStartAsync. The first
> three are associated with the most recent asynchronous cycle started by
> calling
> one of the ServletRequest.startAsync methods. The onStartAsync is
> associated to a new asynchronous cycle via one of the
> ServletRequest.startAsync
> methods."
>
> so you can do the following:
>
> public void onStartAsync(AsyncEvent event) throws IOException {
> // Re-add this listener to the new AsyncContext
> event.getAsyncContext().addListener(this);
> }
>
> Regards,
> Violeta
>
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-05-17 12:43 GMT+02:00 Rémy Maucherat :
> >
> > > 2016-05-17 12:37 GMT+02:00 Romain Manni-Bucau :
> > >
> > > > Only found https://bz.apache.org/bugzilla/show_bug.cgi?id=59261
> which
> > > > doesn't mean this code would be invalid
> > > >
> > > > Also if you add a listener eagerly you will have the start event and
> > > loose
> > > > all "end" (completed, timeout etc...) ones. This doesn't sound very
> > > > reliable.
> > > >
> > > > Can you point me out the related issue please?
> > > >
> > > > The bugzilla title says: "Request getAsyncContext should throw
> > > IllegalStateException if async is not started". So that's what happens
> now.
> > >
> > > Rémy
> > >
>
Re: [VOTE] Release Apache Tomcat 8.5.3
+1 (non-binding) upgraded TomEE 7 master to tomcat 8.5.3 and build is green Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-06-10 3:58 GMT+02:00 Keiichi Fujino : > 2016-06-09 21:13 GMT+09:00 Mark Thomas : > > > The proposed Apache Tomcat 8.5.3 release is now available for voting. > > > > The major changes compared to the 8.5.2 release are: > > > > - Ensure error will not be thrown during deployment when scanning jar > > files with no or invalid MANIFEST.MF files. > > > > - Improvements to memory leak detection and prevention > > > > - The HTTP Server header is no longer set by default > > > > It can be obtained from: > > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.3/ > > The Maven staging repo is: > > https://repository.apache.org/content/repositories/orgapachetomcat-1086/ > > The svn tag is: > > http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_3/ > > > > The proposed 8.5.3 release is: > > [ ] Broken - do not release > > [ ] Alpha - go ahead and release as 8.5.3 > > [ ] Beta - go ahead and release as 8.5.3 > > [X] Stable - go ahead and release as 8.5.3 > > > > > +1 > Tested on my test apps (enable BackupManager) > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > -- > > Keiichi.Fujino > > > > >
Re: Avoid use of SecureRandom during server startup
@Andy: you can use FastNonSecureRandom to disable it, should be enough for applications not using the session Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-06-16 11:21 GMT+02:00 Rémy Maucherat : > 2016-06-16 11:15 GMT+02:00 Andy Wilkinson : > > > I work on Spring Boot which uses Tomcat (or Jetty or Undertow) as an > > embedded servlet container. We've seen a number of complaints from users > > that their application hangs during startup, most often on a newly booted > > VPS. The root cause is a lack of entropy which causes Tomcat's use of > > SecureRandom for session ID generation to block. > > > > Users that choose to use Undertow rather than Tomcat aren't affected by > > this problem during startup. Like Tomcat, Undertow uses SecureRandom to > > generate session IDs. However, unlike Tomcat, Undertow does so lazily. > This > > defers the problem till the first request that uses a session and > > permanently if the application does not make use of HTTP sessions. > > > > Can we please explore the possibility of making Tomcat behave in a > similar > > way to Undertow? > > > > -1, I am against fake improvements. > > Rémy >
leak if jspServlet.destroy() fails
Hello guys, if a jspDestroy() throws an Exception then the instance manager is not called which can lead to some leaks depending the implementation (see org.apache.jasper.servlet.JspServletWrapper#destroy) Would it be possible to have a way to release/cleanup the jsp context through the instance manager or to call destroyInstance properly? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>
Re: leak if jspServlet.destroy() fails
+1 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-07-01 18:06 GMT+02:00 Mark Thomas : > On 01/07/2016 16:41, Romain Manni-Bucau wrote: > > Hello guys, > > > > if a jspDestroy() throws an Exception then the instance manager is not > > called which can lead to some leaks depending the implementation (see > > org.apache.jasper.servlet.JspServletWrapper#destroy) > > > > Would it be possible to have a way to release/cleanup the jsp context > > through the instance manager or to call destroyInstance properly? > > I think wrapping the call to destroy in a try/catch would be the way to > go. It would be worth a check to see if there are any other places where > similar issues could occur with JSPs. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: leak if jspServlet.destroy() fails
Think org.apache.jasper.runtime.TagHandlerPool#release can be affected too - I'm not sure where it is called in the codebase but the pattern is the same. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-07-01 18:10 GMT+02:00 Romain Manni-Bucau : > +1 > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > 2016-07-01 18:06 GMT+02:00 Mark Thomas : > >> On 01/07/2016 16:41, Romain Manni-Bucau wrote: >> > Hello guys, >> > >> > if a jspDestroy() throws an Exception then the instance manager is not >> > called which can lead to some leaks depending the implementation (see >> > org.apache.jasper.servlet.JspServletWrapper#destroy) >> > >> > Would it be possible to have a way to release/cleanup the jsp context >> > through the instance manager or to call destroyInstance properly? >> >> I think wrapping the call to destroy in a try/catch would be the way to >> go. It would be worth a check to see if there are any other places where >> similar issues could occur with JSPs. >> >> Mark >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> >
Re: leak if jspServlet.destroy() fails
Hi all,
is (jsp) generated code for tags suffering from the same kind of issue? For
a c:out I get:
private boolean
_jspx_meth_c_005fout_005f0(javax.servlet.jsp.PageContext
_jspx_page_context)
throws java.lang.Throwable {
javax.servlet.jsp.PageContext pageContext = _jspx_page_context;
javax.servlet.jsp.JspWriter out = _jspx_page_context.getOut();
// c:out
org.apache.taglibs.standard.tag.rt.core.OutTag
_jspx_th_c_005fout_005f0 =
(org.apache.taglibs.standard.tag.rt.core.OutTag)
_005fjspx_005ftagPool_005fc_005fout_0026_005fvalue_005fnobody.get(org.apache.taglibs.standard.tag.rt.core.OutTag.class);
_jspx_th_c_005fout_005f0.setPageContext(_jspx_page_context);
_jspx_th_c_005fout_005f0.setParent(null);
// /fail.jsp(30,0) name = value type = null reqTime = true required
= true fragment = false deferredValue = false expectedTypeName = null
deferredMethod = false methodSignature = null
_jspx_th_c_005fout_005f0.setValue((java.lang.Object)
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${'
, &'}", java.lang.Object.class,
(javax.servlet.jsp.PageContext)_jspx_page_context, null));
int _jspx_eval_c_005fout_005f0 = _jspx_th_c_005fout_005f0.doStartTag();
if (_jspx_th_c_005fout_005f0.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE) {
_005fjspx_005ftagPool_005fc_005fout_0026_005fvalue_005fnobody.reuse(_jspx_th_c_005fout_005f0);
return true;
}
_005fjspx_005ftagPool_005fc_005fout_0026_005fvalue_005fnobody.reuse(_jspx_th_c_005fout_005f0);
return false;
}
Wonder if the reuse() shouldn't be in a finally block - in particular
for custom tags. Wdyt?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-01 19:25 GMT+02:00 Mark Thomas :
> On 01/07/2016 17:28, Romain Manni-Bucau wrote:
> > Think org.apache.jasper.runtime.TagHandlerPool#release can be affected
> too
> > - I'm not sure where it is called in the codebase but the pattern is the
> > same.
>
> I've doing a review of all calls to destroyInstance() now. There is at
> least one further issue as well as the tag one you spotted.
>
> Mark
>
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-07-01 18:10 GMT+02:00 Romain Manni-Bucau :
> >
> >> +1
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> >> <http://rmannibucau.wordpress.com> | Github
> >> <https://github.com/rmannibucau> | LinkedIn
> >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> <http://www.tomitribe.com> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >> 2016-07-01 18:06 GMT+02:00 Mark Thomas :
> >>
> >>> On 01/07/2016 16:41, Romain Manni-Bucau wrote:
> >>>> Hello guys,
> >>>>
> >>>> if a jspDestroy() throws an Exception then the instance manager is not
> >>>> called which can lead to some leaks depending the implementation (see
> >>>> org.apache.jasper.servlet.JspServletWrapper#destroy)
> >>>>
> >>>> Would it be possible to have a way to release/cleanup the jsp context
> >>>> through the instance manager or to call destroyInstance properly?
> >>>
> >>> I think wrapping the call to destroy in a try/catch would be the way to
> >>> go. It would be worth a check to see if there are any other places
> where
> >>> similar issues could occur with JSPs.
> >>>
> >>> 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
>
>
Re: leak if jspServlet.destroy() fails
well the instanceManager.destoy should be called whatever happens I think
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-13 20:51 GMT+02:00 Violeta Georgieva :
> Hi,
>
> 2016-07-12 23:53 GMT+03:00 Romain Manni-Bucau :
> >
> > Hi all,
> >
> > is (jsp) generated code for tags suffering from the same kind of issue?
> For
> > a c:out I get:
> >
> >
> > private boolean
> > _jspx_meth_c_005fout_005f0(javax.servlet.jsp.PageContext
> > _jspx_page_context)
> > throws java.lang.Throwable {
> > javax.servlet.jsp.PageContext pageContext = _jspx_page_context;
> > javax.servlet.jsp.JspWriter out = _jspx_page_context.getOut();
> > // c:out
> > org.apache.taglibs.standard.tag.rt.core.OutTag
> > _jspx_th_c_005fout_005f0 =
> > (org.apache.taglibs.standard.tag.rt.core.OutTag)
> >
>
> _005fjspx_005ftagPool_005fc_005fout_0026_005fvalue_005fnobody.get(org.apache.taglibs.standard.tag.rt.core.OutTag.class);
> > _jspx_th_c_005fout_005f0.setPageContext(_jspx_page_context);
> > _jspx_th_c_005fout_005f0.setParent(null);
> > // /fail.jsp(30,0) name = value type = null reqTime = true required
> > = true fragment = false deferredValue = false expectedTypeName = null
> > deferredMethod = false methodSignature = null
> > _jspx_th_c_005fout_005f0.setValue((java.lang.Object)
> > org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${'
> > , &'}", java.lang.Object.class,
> > (javax.servlet.jsp.PageContext)_jspx_page_context, null));
> > int _jspx_eval_c_005fout_005f0 = _jspx_th_c_005fout_005f0.doStartTag();
> > if (_jspx_th_c_005fout_005f0.doEndTag() ==
> > javax.servlet.jsp.tagext.Tag.SKIP_PAGE) {
> >
>
> _005fjspx_005ftagPool_005fc_005fout_0026_005fvalue_005fnobody.reuse(_jspx_th_c_005fout_005f0);
> > return true;
> > }
> >
>
> _005fjspx_005ftagPool_005fc_005fout_0026_005fvalue_005fnobody.reuse(_jspx_th_c_005fout_005f0);
> > return false;
> > }
> >
> > Wonder if the reuse() shouldn't be in a finally block - in particular
> > for custom tags. Wdyt?
> >
> >
>
> Currently the implementation [1], [2] is based on the fact whether or not
> the tag handler implements TryCatchFinally [3]
>
> May be we should revise it and to put these (reuse, release,
> destroyInstance) always in try/finally
>
> Regards,
> Violeta
>
> [1]
>
> https://github.com/apache/tomcat/blob/trunk/java/org/apache/jasper/compiler/Generator.java#L2562
> [2]
>
> https://github.com/apache/tomcat/blob/trunk/java/org/apache/jasper/compiler/Generator.java#L2585
> [3]
>
> http://docs.oracle.com/javaee/6/api/javax/servlet/jsp/tagext/TryCatchFinally.html
>
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-07-01 19:25 GMT+02:00 Mark Thomas :
> >
> > > On 01/07/2016 17:28, Romain Manni-Bucau wrote:
> > > > Think org.apache.jasper.runtime.TagHandlerPool#release can be
> affected
> > > too
> > > > - I'm not sure where it is called in the codebase but the pattern is
> the
> > > > same.
> > >
> > > I've doing a review of all calls to destroyInstance() now. There is at
> > > least one further issue as well as the tag one you spotted.
> > >
> > > Mark
> > >
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > &l
more protection around pauseNonContainerThread()?
Hi guys, I got several cases in prod where pauseNonContainerThread() get stucked (ie the thread is blocked but no other thread is actually working and can release it). I'm not really sure of the cause - I suspect some timeouts but can't guarantee it. Just for information I'm using JAX-RS 2 @Suspended with CXF which is built on top of Servlet 3 AsyncContext. Question is: can tomcat kind of enforce it to be released either using a configurable timeout for this wait or something equivalent to avoid such a case? Goal is to avoid as much as possible to fully lock the container in the caller doesn't handle properly the async usage (hypothesis being tomcat doesn't have a bug on that area). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>
Re: more protection around pauseNonContainerThread()?
PS: this pauseNonContainerThread breaks CXF apps cause they synchronize an instance (AsyncResponseImpl) which potentially deadlock with tomcat cause of that. Would be nice to solve it in a manner not requiring all apps/libs to know that. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-08-17 15:55 GMT+02:00 Romain Manni-Bucau : > Hi guys, > > I got several cases in prod where pauseNonContainerThread() get stucked > (ie the thread is blocked but no other thread is actually working and can > release it). > > I'm not really sure of the cause - I suspect some timeouts but can't > guarantee it. Just for information I'm using JAX-RS 2 @Suspended with CXF > which is built on top of Servlet 3 AsyncContext. > > Question is: can tomcat kind of enforce it to be released either using a > configurable timeout for this wait or something equivalent to avoid such a > case? Goal is to avoid as much as possible to fully lock the container in > the caller doesn't handle properly the async usage (hypothesis being tomcat > doesn't have a bug on that area). > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> >
Re: more protection around pauseNonContainerThread()?
~business code (simplified):
public void myBusiness(AsyncResponse wrapperOfAsyncContext) {
new Thread() {
@Override
public void run() {
wrapperOfAsyncContext.synchronizedDispatch();
}
}.start();
wrapperOfAsyncContext.synchronizedMethod();
}
If timing is good (and encountered enough to say it is in real life) then
both method call will lock cause:
1. for the user thread: the dispatch call will call pauseNonContainerThread
to wait the myBusiness thread to end (actually a bit more but you get the
idea)
2. synchronizedMethod will lock on synchronizedDispatch
so synchronizedMethod is lock on synchronizedDispatch which is lock on
the pauseNonContainerThread of the caller/http thread so both threads are
locked.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-09-02 16:33 GMT+02:00 Mark Thomas :
> On 02/09/2016 14:45, Romain Manni-Bucau wrote:
> > PS: this pauseNonContainerThread breaks CXF apps cause they synchronize
> an
> > instance (AsyncResponseImpl) which potentially deadlock with tomcat cause
> > of that. Would be nice to solve it in a manner not requiring all
> apps/libs
> > to know that.
>
> Can you provide more details of what is going on in this case? I can see
> potential ways for this to break but the app has to do some pretty odd
> things to make that possible.
>
> Mark
>
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-08-17 15:55 GMT+02:00 Romain Manni-Bucau :
> >
> >> Hi guys,
> >>
> >> I got several cases in prod where pauseNonContainerThread() get stucked
> >> (ie the thread is blocked but no other thread is actually working and
> can
> >> release it).
> >>
> >> I'm not really sure of the cause - I suspect some timeouts but can't
> >> guarantee it. Just for information I'm using JAX-RS 2 @Suspended with
> CXF
> >> which is built on top of Servlet 3 AsyncContext.
> >>
> >> Question is: can tomcat kind of enforce it to be released either using a
> >> configurable timeout for this wait or something equivalent to avoid
> such a
> >> case? Goal is to avoid as much as possible to fully lock the container
> in
> >> the caller doesn't handle properly the async usage (hypothesis being
> tomcat
> >> doesn't have a bug on that area).
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> >> <http://rmannibucau.wordpress.com> | Github
> >> <https://github.com/rmannibucau> | LinkedIn
> >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> <http://www.tomitribe.com> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: more protection around pauseNonContainerThread()?
This is an interesting quote cause i understand as it is implemented in
tomcat but also means any usage would potentially lead to deadlocks or
container integration to ensure thread safety is done right making in both
cases the spec unusable or hard to use from a user perspective. Should it
be pushed back to the spec?
Le 3 sept. 2016 18:28, "Mark Thomas" a écrit :
> On 02/09/2016 15:47, Romain Manni-Bucau wrote:
> > ~business code (simplified):
> >
> > public void myBusiness(AsyncResponse wrapperOfAsyncContext) {
> > new Thread() {
> > @Override
> > public void run() {
> > wrapperOfAsyncContext.synchronizedDispatch();
> > }
> > }.start();
> > wrapperOfAsyncContext.synchronizedMethod();
> > }
> >
> > If timing is good (and encountered enough to say it is in real life) then
> > both method call will lock cause:
> >
> > 1. for the user thread: the dispatch call will call
> pauseNonContainerThread
> > to wait the myBusiness thread to end (actually a bit more but you get the
> > idea)
> > 2. synchronizedMethod will lock on synchronizedDispatch
> >
> > so synchronizedMethod is lock on synchronizedDispatch which is lock on
> > the pauseNonContainerThread of the caller/http thread so both threads are
> > locked.
>
> Hmm.
>
> The relevant text from the Servlet spec is (for both dispatch() and
> complete()) is:
>
> "If any of the dispatch methods are called before the
> container-initiated dispatch that called startAsync has returned to the
> container, then the call will not take effect until after the
> container-initiated dispatch has returned to the container."
>
> The critical question is what does "...will not take effect until..." mean.
>
> Currently, Tomcat implements this as "...will block until...". I'll look
> into what it would take to implement this as "...note the request and
> execute it once...". Whether or not we change this will depend a lot on
> how complicated the change would be.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: more protection around pauseNonContainerThread()?
Hi Mark,
tested on a lighter sample reproducing the issue pretty easily (real one
would need 8.5) and your patch fixed it keeping the sample working fine
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-09-03 20:38 GMT+02:00 Mark Thomas :
> On 03/09/2016 18:08, Romain Manni-Bucau wrote:
> > This is an interesting quote cause i understand as it is implemented in
> > tomcat but also means any usage would potentially lead to deadlocks or
> > container integration to ensure thread safety is done right making in
> both
> > cases the spec unusable or hard to use from a user perspective. Should it
> > be pushed back to the spec?
>
> It wouldn't hurt for the EG to clarify exactly what they meant by
> "...will not take effect until...". If it is intended that it might
> include blocking the thread making the call, stating that explicitly
> would be good.
>
> Meanwhile, try the following patch and let me know how you get on. It
> achieves the same result (hopefully) without the blocking. The unit
> tests pass but I want to think about it some more (and add some
> comments) before committing.
>
> http://people.apache.org/~markt/patches/2016-09-03-
> async-refactoring-tc9-v1.patch
>
> Mark
>
>
> >
> > Le 3 sept. 2016 18:28, "Mark Thomas" a écrit :
> >
> >> On 02/09/2016 15:47, Romain Manni-Bucau wrote:
> >>> ~business code (simplified):
> >>>
> >>> public void myBusiness(AsyncResponse wrapperOfAsyncContext) {
> >>> new Thread() {
> >>> @Override
> >>> public void run() {
> >>> wrapperOfAsyncContext.synchronizedDispatch();
> >>> }
> >>> }.start();
> >>> wrapperOfAsyncContext.synchronizedMethod();
> >>> }
> >>>
> >>> If timing is good (and encountered enough to say it is in real life)
> then
> >>> both method call will lock cause:
> >>>
> >>> 1. for the user thread: the dispatch call will call
> >> pauseNonContainerThread
> >>> to wait the myBusiness thread to end (actually a bit more but you get
> the
> >>> idea)
> >>> 2. synchronizedMethod will lock on synchronizedDispatch
> >>>
> >>> so synchronizedMethod is lock on synchronizedDispatch which is lock on
> >>> the pauseNonContainerThread of the caller/http thread so both threads
> are
> >>> locked.
> >>
> >> Hmm.
> >>
> >> The relevant text from the Servlet spec is (for both dispatch() and
> >> complete()) is:
> >>
> >> "If any of the dispatch methods are called before the
> >> container-initiated dispatch that called startAsync has returned to the
> >> container, then the call will not take effect until after the
> >> container-initiated dispatch has returned to the container."
> >>
> >> The critical question is what does "...will not take effect until..."
> mean.
> >>
> >> Currently, Tomcat implements this as "...will block until...". I'll look
> >> into what it would take to implement this as "...note the request and
> >> execute it once...". Whether or not we change this will depend a lot on
> >> how complicated the change would be.
> >>
> >> 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
>
>
Re: more protection around pauseNonContainerThread()?
Hello guys,
wonder if there is an estimated date for this fix to be included in a
release. I'm starting to gather the project dependencies we need for next
tomee release and tomcat is on the radar due to this one.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-09-05 10:03 GMT+02:00 Mark Thomas :
> On 05/09/2016 08:14, Romain Manni-Bucau wrote:
> > Hi Mark,
> >
> > tested on a lighter sample reproducing the issue pretty easily (real one
> > would need 8.5) and your patch fixed it keeping the sample working fine
>
> Thanks for testing. The patch was a bit of a hack. The 'correct' fix
> will be to update the state machine. Now I know that this patch fixes
> the problem, I'll look at putting together a 'proper' fix for the next
> round of releases.
>
> Mark
>
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-09-03 20:38 GMT+02:00 Mark Thomas :
> >
> >> On 03/09/2016 18:08, Romain Manni-Bucau wrote:
> >>> This is an interesting quote cause i understand as it is implemented in
> >>> tomcat but also means any usage would potentially lead to deadlocks or
> >>> container integration to ensure thread safety is done right making in
> >> both
> >>> cases the spec unusable or hard to use from a user perspective. Should
> it
> >>> be pushed back to the spec?
> >>
> >> It wouldn't hurt for the EG to clarify exactly what they meant by
> >> "...will not take effect until...". If it is intended that it might
> >> include blocking the thread making the call, stating that explicitly
> >> would be good.
> >>
> >> Meanwhile, try the following patch and let me know how you get on. It
> >> achieves the same result (hopefully) without the blocking. The unit
> >> tests pass but I want to think about it some more (and add some
> >> comments) before committing.
> >>
> >> http://people.apache.org/~markt/patches/2016-09-03-
> >> async-refactoring-tc9-v1.patch
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Le 3 sept. 2016 18:28, "Mark Thomas" a écrit :
> >>>
> >>>> On 02/09/2016 15:47, Romain Manni-Bucau wrote:
> >>>>> ~business code (simplified):
> >>>>>
> >>>>> public void myBusiness(AsyncResponse wrapperOfAsyncContext) {
> >>>>> new Thread() {
> >>>>> @Override
> >>>>> public void run() {
> >>>>> wrapperOfAsyncContext.synchronizedDispatch();
> >>>>> }
> >>>>> }.start();
> >>>>> wrapperOfAsyncContext.synchronizedMethod();
> >>>>> }
> >>>>>
> >>>>> If timing is good (and encountered enough to say it is in real life)
> >> then
> >>>>> both method call will lock cause:
> >>>>>
> >>>>> 1. for the user thread: the dispatch call will call
> >>>> pauseNonContainerThread
> >>>>> to wait the myBusiness thread to end (actually a bit more but you get
> >> the
> >>>>> idea)
> >>>>> 2. synchronizedMethod will lock on synchronizedDispatch
> >>>>>
> >>>>> so synchronizedMethod is lock on synchronizedDispatch which is lock
> on
> >>>>> the pauseNonContainerThread of the caller/http thread so both threads
> >> are
> >>>>> locked.
> >>>>
> >>>> Hmm.
> >>>>
> >>>> The relevant text from the Servlet spec is (for both dispatch() and
> >>>> complete()) is:
> >>>>
> >>>> "If any of th
classResources.start() can be duplicated
Hi guys,
StandardRoot does that at the moment (taken the 8.5.5 as a reference for
this mail):
for (List list : allResources) {
for (WebResourceSet webResourceSet : list) {
webResourceSet.start();
}
}
// This has to be called after the other resources have been started
// else it won't find all the matching resources
processWebInfLib();
// Need to start the newly found resources
for (WebResourceSet classResource : classResources) {
classResource.start();
}
This works well in a plain Tomcat but suppose you configure class resources
before that method (statically or programmatically through a listener) then
the iteration over allResources iterates over classesResources and then it
is done again. Doesn't hurt much excepted this log:
14:09:57.362 [main] INFO org.apache.catalina.util.LifecycleBase - The
start() method was called on component
[org.apache.catalina.webresources.JarResourceSet@2ee5c08d] after start()
had already been called. The second call will be ignored.
Would it be possible to modify it to be:
for (List list : allResources) {
for (WebResourceSet webResourceSet : list) {
if (webResourceSet != classResources) webResourceSet.start();
}
}
// This has to be called after the other resources have been started
// else it won't find all the matching resources
processWebInfLib();
// Need to start the newly found resources
for (WebResourceSet classResource : classResources) {
classResource.start();
}
?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
Re: classResources.start() can be duplicated
2016-09-29 15:14 GMT+02:00 Mark Thomas :
> On 29/09/2016 13:12, Romain Manni-Bucau wrote:
> > Hi guys,
> >
> > StandardRoot does that at the moment (taken the 8.5.5 as a reference for
> > this mail):
> >
> > for (List list : allResources) {
> > for (WebResourceSet webResourceSet : list) {
> > webResourceSet.start();
> > }
> > }
> >
> > // This has to be called after the other resources have been started
> > // else it won't find all the matching resources
> > processWebInfLib();
> > // Need to start the newly found resources
> > for (WebResourceSet classResource : classResources) {
> > classResource.start();
> > }
> >
> >
> >
> > This works well in a plain Tomcat but suppose you configure class
> resources
> > before that method (statically or programmatically through a listener)
> then
> > the iteration over allResources iterates over classesResources and then
> it
> > is done again. Doesn't hurt much excepted this log:
> >
> > 14:09:57.362 [main] INFO org.apache.catalina.util.LifecycleBase - The
> > start() method was called on component
> > [org.apache.catalina.webresources.JarResourceSet@2ee5c08d] after start()
> > had already been called. The second call will be ignored.
> >
> > Would it be possible to modify it to be:
>
> Happy to fix it, but the change below isn't right. It should be:
> list != classResources
>
> I'll fix this in the next couple of minutes.
>
>
+1! Thanks a lot
> Mark
>
>
> >
> > for (List list : allResources) {
> > for (WebResourceSet webResourceSet : list) {
> > if (webResourceSet != classResources) webResourceSet.start();
> >
> > }
> > }
> >
> > // This has to be called after the other resources have been started
> > // else it won't find all the matching resources
> > processWebInfLib();
> > // Need to start the newly found resources
> > for (WebResourceSet classResource : classResources) {
> > classResource.start();
> > }
> >
> >
> > ?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
8.5.6 @ central
Hi guys, seems 8.5.6 didnt hit central yet and is still in staging even if the announce was sent, as it intended? PS: I'm interested in 8.5.6 but other "co-"votes are in the same state I think Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>
Re: 8.5.6 @ central
Thanks! Le 12 oct. 2016 09:05, "Martin Grigorov" a écrit : > Hi, > > I've just released 8.0.38, 8.5.6 and 9.0.0.M11 from Apache Nexus to Maven > Central. > They must be publicly available in few hours. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Oct 12, 2016 at 7:54 AM, Romain Manni-Bucau > > wrote: > > > Hi guys, > > > > seems 8.5.6 didnt hit central yet and is still in staging even if the > > announce was sent, as it intended? > > > > PS: I'm interested in 8.5.6 but other "co-"votes are in the same state I > > think > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog > > <http://rmannibucau.wordpress.com> | Github <https://github.com/ > > rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > > <http://www.tomitribe.com> | JavaEE Factory > > <https://javaeefactory-rmannibucau.rhcloud.com> > > >
Re: getResourceAsStream() for a folder
@Svetlin: thanks to catch it, was intended for dev@tomcat (thanks gmail to
have completion ;))
dev@tomcat: can you check please the original question (in short:
getResourceAsStream("/some/folder")
returns a stream)
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-10-13 13:59 GMT+02:00 Svetlin Zarev :
> Hi,
>
> IMO this is a bug introduced with [1][2]. Although the root cause is in the
> bad impl. of FileResource [3] that ignores the IOException and despite the
> error, still returns a byte[] as if nothing bad happened.
>
>
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60146
> [2]
> https://github.com/apache/tomcat85/blob/5768426dd27422747f2b9b4da5a092
> 7ee3328ffb/java/org/apache/catalina/webresources/CachedResource.java#L267
> [3]
> https://github.com/apache/tomcat85/blob/5768426dd27422747f2b9b4da5a092
> 7ee3328ffb/java/org/apache/catalina/webresources/FileResource.java#L203
>
> PS: Maybe this should be forwarded to the tomcat dev list ?
>
> Kind regards,
> Svetlin
>
> 2016-10-13 12:06 GMT+03:00 Romain Manni-Bucau :
>
> > Hi guys,
> >
> > upgrading tomee to tomcat 8.5.6 I noticed request.getServletContext().
> > getResourceAsStream(path) now returns an empty stream for / (or an
> existing
> > folder probably). Not sure it is expected or unintended.
> >
> > Reading the spec it is not that clear to me since the folder is an
> existing
> > resource but not really a webresource so not it should be considered as a
> > resource and therefore having a stream (which doesn't mean much for a
> > folder).
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
>
Re: getResourceAsStream() for a folder
Thanks Mark!
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-10-13 16:05 GMT+02:00 Mark Thomas :
> On 13/10/2016 14:27, Mark Thomas wrote:
> > On 13/10/2016 13:13, Romain Manni-Bucau wrote:
> >> @Svetlin: thanks to catch it, was intended for dev@tomcat (thanks
> gmail to
> >> have completion ;))
> >>
> >> dev@tomcat: can you check please the original question (in short:
> >> getResourceAsStream("/some/folder")
> >> returns a stream)
> >
> > Thanks for the heads up. I'll take a look.
>
> Fixed.
>
> Mark
>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> >> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> <http://www.tomitribe.com> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >> 2016-10-13 13:59 GMT+02:00 Svetlin Zarev com>:
> >>
> >>> Hi,
> >>>
> >>> IMO this is a bug introduced with [1][2]. Although the root cause is
> in the
> >>> bad impl. of FileResource [3] that ignores the IOException and despite
> the
> >>> error, still returns a byte[] as if nothing bad happened.
> >>>
> >>>
> >>> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60146
> >>> [2]
> >>> https://github.com/apache/tomcat85/blob/5768426dd27422747f2b9b4da5a092
> >>> 7ee3328ffb/java/org/apache/catalina/webresources/
> CachedResource.java#L267
> >>> [3]
> >>> https://github.com/apache/tomcat85/blob/5768426dd27422747f2b9b4da5a092
> >>> 7ee3328ffb/java/org/apache/catalina/webresources/
> FileResource.java#L203
> >>>
> >>> PS: Maybe this should be forwarded to the tomcat dev list ?
> >>>
> >>> Kind regards,
> >>> Svetlin
> >>>
> >>> 2016-10-13 12:06 GMT+03:00 Romain Manni-Bucau :
> >>>
> >>>> Hi guys,
> >>>>
> >>>> upgrading tomee to tomcat 8.5.6 I noticed request.getServletContext().
> >>>> getResourceAsStream(path) now returns an empty stream for / (or an
> >>> existing
> >>>> folder probably). Not sure it is expected or unintended.
> >>>>
> >>>> Reading the spec it is not that clear to me since the folder is an
> >>> existing
> >>>> resource but not really a webresource so not it should be considered
> as a
> >>>> resource and therefore having a stream (which doesn't mean much for a
> >>>> folder).
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >>>> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> >>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >>>> rmannibucau> |
> >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >>>> <http://www.tomitribe.com> | JavaEE Factory
> >>>> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>>>
> >>>
> >>
> >
> >
> > -
> > 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
>
>
jaspic-api @ central
Hi guys, isn't jaspic api on central? If not wouldnt it be nice cause it contains the right default impl for tomcat? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>
tomcat-util and duplicated classes
Hi guys, is it normal tomcat-util and tomcat-util-scan define twice the file package? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>
Re: jaspic-api @ central
works great, thanks (side note: can you also do it with 8.5.x releases please if not yet planned?) Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-10-19 12:42 GMT+02:00 Mark Thomas : > On 19/10/2016 09:57, Mark Thomas wrote: > > On 19/10/2016 08:22, Romain Manni-Bucau wrote: > >> Hi guys, > >> > >> isn't jaspic api on central? > > > > Doesn't look like it. > > > >> If not wouldnt it be nice cause it contains > >> the right default impl for tomcat? > > > > I'll take a look. > > This should be fixed. I've uploaded a snapshot of trunk here: > https://repository.apache.org/content/repositories/ > snapshots/org/apache/tomcat/ > > If there are any issues, let us know and we can try and fix them before > the next round of releases. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
typo in javadoc: UriUtil?
Hi guys, second war: should be jar: in https://github.com/apache/tomcat/blob/trunk/java/org/apache/tomcat/util/buf/UriUtil.java#L134 I think, no? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>
Re: TC 8.5 and Log4J2 via Juli: Wrong location info
Hi guys, since now tomcat has Log API as a SPI doing 2 is easy ( http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/microwave-core/src/main/java/org/apache/microwave/logging/tomcat/Log4j2Log.java) and just a drop-in jar setup so not sure it needs to be in tomcat default delivery. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-10-25 15:28 GMT+02:00 Mark Thomas : > On 25/10/2016 14:17, Rainer Jung wrote: > > Hi everyone, > > > > when using TC 8.5 with the Log4J2 jul bridge the location info in the > > Log4J output points to the juli class DirectJDKLog instead of the Tomcat > > class with the juli log call. Only the category/logger name is correct: > > > > %c: org.apache.catalina.core.StandardServer (Example, correct) > > %C: org.apache.juli.logging.DirectJDKLog > > %l: org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:179) > > %M: log > > %F: DirectJDKLog.java > > %L: 179 > > > > The jul bridge does not try to fully populate al possible location info, > > but instead only the category name. Log4J then later gets the log > > location from the stack frame that calls the jul bridge which always > > gives org.apache.juli.logging.DirectJDKLog. > > > > It seems we either need to directly call the jul bridge without an > > intermediate logging impl class, or the Log4J2 jul bridge must be made > > more complex. > > > > Any opinion? Ideas? > > I did look at whether or not we could remove the use of DirectJDKLog - > essentially reducing JULI to the custom LogManager. My conclusion at the > time was it was possible but was a whole lot of effort for very little > benefit. Maybe this tips the balance? > > The other option would be to provide a dedicated log4j2 adadptor - maybe > along with appropriate adapters for other logging frameworks as well. > > > I know that the location info is expensive to get, but failing to > > support the correct location info is IMHO bad. The old adapter solution > > supported correct location info in log4j. > > I think we have two options: > > 1. Code to just java.util.logging as sufficient and let the logging > frameworks deal with hooking in to java.util.logging. This is > essentially the option that removes code. > > 2. Provide an adaptor for at least log4j2 and possible other frameworks. > This is essentially the option that adds code. > > Option 1 means less code but less flexibility. Option 2 is more code but > what we get in return is more flexibility maybe implementation options > for better performance. > > Another advantage of 1 is that it removes JULI as a dependency from much > of out code. This could make it simpler for others to re-use. > > Personally, I lean towards 1. but I'm not going to object if someone > wants to pursue 2. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: TC 8.5 and Log4J2 via Juli: Wrong location info
This has the issue but the fix is easy and 100% belonging to the Log impl jar: http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/microwave-core/src/main/java/org/apache/microwave/logging/log4j2/MicrowaveLogEventFactory.java and http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/microwave-core/src/main/resources/log4j2.component.properties Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-10-25 16:38 GMT+02:00 Rainer Jung : > Am 25.10.2016 um 15:33 schrieb Romain Manni-Bucau: > >> Hi guys, >> >> since now tomcat has Log API as a SPI doing 2 is easy ( >> http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk >> /microwave-core/src/main/java/org/apache/microwave/logging/ >> tomcat/Log4j2Log.java) >> and >> just a drop-in jar setup so not sure it needs to be in tomcat default >> delivery. >> > > I tried to plug in Log4j2Log.java using SPI. It gets used, but it doesn't > fix the problem. Now the location info points to Log4j2Log instead of > DirectJDKLog. The Problem of one indirection layer to much above Log4Js > has't changed. > > I think the jul log bridge removes one frame, which is the jul loger, > ending up taking the DirectJDKLog which vcalls the jul logger as its > location. Using your approach does no longer use jul, so log4j2 doesn't re > move a frame and again takes the wrong class Log4j2Log as its location info. > > I think delegating is not enough, you actually need to implement the > target API or extend a target implementation. > > Did you check the location info using the SPI approach? > > Regards, > > Rainer > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: TC 8.5 and Log4J2 via Juli: Wrong location info
2016-10-25 22:35 GMT+02:00 Rainer Jung : > Am 25.10.2016 um 17:07 schrieb Romain Manni-Bucau: > >> This has the issue but the fix is easy and 100% belonging to the Log impl >> jar: >> http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk >> /microwave-core/src/main/java/org/apache/microwave/logging/ >> log4j2/MicrowaveLogEventFactory.java >> and >> http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk >> /microwave-core/src/main/resources/log4j2.component.properties >> >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog >> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> <http://www.tomitribe.com> | JavaEE Factory >> <https://javaeefactory-rmannibucau.rhcloud.com> >> >> 2016-10-25 16:38 GMT+02:00 Rainer Jung : >> >> Am 25.10.2016 um 15:33 schrieb Romain Manni-Bucau: >>> >>> Hi guys, >>>> >>>> since now tomcat has Log API as a SPI doing 2 is easy ( >>>> http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk >>>> /microwave-core/src/main/java/org/apache/microwave/logging/ >>>> tomcat/Log4j2Log.java) >>>> and >>>> just a drop-in jar setup so not sure it needs to be in tomcat default >>>> delivery. >>>> >>>> >>> I tried to plug in Log4j2Log.java using SPI. It gets used, but it doesn't >>> fix the problem. Now the location info points to Log4j2Log instead of >>> DirectJDKLog. The Problem of one indirection layer to much above Log4Js >>> has't changed. >>> >>> I think the jul log bridge removes one frame, which is the jul loger, >>> ending up taking the DirectJDKLog which vcalls the jul logger as its >>> location. Using your approach does no longer use jul, so log4j2 doesn't >>> re >>> move a frame and again takes the wrong class Log4j2Log as its location >>> info. >>> >>> I think delegating is not enough, you actually need to implement the >>> target API or extend a target implementation. >>> >>> Did you check the location info using the SPI approach? >>> >>> Regards, >>> >>> Rainer >>> >> > Thanks for that hint. Actually I hadn't noticed this trick to overwrite > the getSource() logic. > > I'm not sure though, how dangerous this is due to possible effects on > Log4J2 in some webapp. IMHO the alternative LogEvent and LogEventFactory > impl must be made available for Tomcat use already in the CLASSPATH. The > server loader could already be too late. That means it is also visible to > any webapp. And activating it is done either via a system property, or a > resource named log4j2.component.properties which contains the property > > Log4jLogEventFactory=org.apache.juli.JuliLogEventFactory > > Again this resource IMHO must reside in the CLASSPATH. So both ways of > activating the alternative LogEvent impl also activate it for any Log4J2 in > any webapp. > > True or not, nothing prevents to run it in a logger classloader to isolate from webapp. That said if you want tomcat to log with log4j2 you likely also want the webapps to do the same IMO. Also tomcat has a classloader context selector so config can be per webapp or at least hook is there for that. > Although the code of the LogEvent looks compatible with the standard one, > this is only true as long as we consider Log4jLogEvent being the standard > one. Unfortunately the Log4J2 class LoggerConfig can use > DefaultLogEventFactory (which indeed uses Log4jLogEvent) but also > ReusableLogEventFactory, which uses thread-local MutableLogEvent. > > So I'm not sure how safe this replacement is. > > the properties config enforces it. It can get more config love but think it already works not bad. > For anyone who wants to experiment here's what I did: > > - create file log4j2.component.properties with the single line: > > Log4jLogEventFactory=org.apache.juli.JuliLogEventFactory > > - create class JuliLogEventFactory.java very similar to the one Romain > created. I'll paste it inline further down. > > - Put the class and the properties file into some new jar (tomcat-juli.jar > should also work) > > - Add the new jar and from Log4J2 log4j-api.jar, log4j-core.jar and > log4j-jul.jar to the CLASSPATH > > - Add a Log4J2 config (I have added its location to CLASSPA
Re: TC 8.5 and Log4J2 via Juli: Wrong location info
2016-10-26 8:26 GMT+02:00 Rainer Jung : > Am 25.10.2016 um 22:40 schrieb Romain Manni-Bucau: > >> 2016-10-25 22:35 GMT+02:00 Rainer Jung : >> >> Am 25.10.2016 um 17:07 schrieb Romain Manni-Bucau: >>> >>> This has the issue but the fix is easy and 100% belonging to the Log impl >>>> jar: >>>> http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk >>>> /microwave-core/src/main/java/org/apache/microwave/logging/ >>>> log4j2/MicrowaveLogEventFactory.java >>>> and >>>> http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk >>>> /microwave-core/src/main/resources/log4j2.component.properties >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog >>>> <http://rmannibucau.wordpress.com> | Github < >>>> https://github.com/rmannibucau> | >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>>> <http://www.tomitribe.com> | JavaEE Factory >>>> <https://javaeefactory-rmannibucau.rhcloud.com> >>>> >>>> 2016-10-25 16:38 GMT+02:00 Rainer Jung : >>>> >>>> Am 25.10.2016 um 15:33 schrieb Romain Manni-Bucau: >>>> >>>>> >>>>> Hi guys, >>>>> >>>>>> >>>>>> since now tomcat has Log API as a SPI doing 2 is easy ( >>>>>> http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk >>>>>> /microwave-core/src/main/java/org/apache/microwave/logging/ >>>>>> tomcat/Log4j2Log.java) >>>>>> and >>>>>> just a drop-in jar setup so not sure it needs to be in tomcat default >>>>>> delivery. >>>>>> >>>>>> >>>>>> I tried to plug in Log4j2Log.java using SPI. It gets used, but it >>>>> doesn't >>>>> fix the problem. Now the location info points to Log4j2Log instead of >>>>> DirectJDKLog. The Problem of one indirection layer to much above Log4Js >>>>> has't changed. >>>>> >>>>> I think the jul log bridge removes one frame, which is the jul loger, >>>>> ending up taking the DirectJDKLog which vcalls the jul logger as its >>>>> location. Using your approach does no longer use jul, so log4j2 doesn't >>>>> re >>>>> move a frame and again takes the wrong class Log4j2Log as its location >>>>> info. >>>>> >>>>> I think delegating is not enough, you actually need to implement the >>>>> target API or extend a target implementation. >>>>> >>>>> Did you check the location info using the SPI approach? >>>>> >>>>> Regards, >>>>> >>>>> Rainer >>>>> >>>>> >>>> Thanks for that hint. Actually I hadn't noticed this trick to overwrite >>> the getSource() logic. >>> >>> I'm not sure though, how dangerous this is due to possible effects on >>> Log4J2 in some webapp. IMHO the alternative LogEvent and LogEventFactory >>> impl must be made available for Tomcat use already in the CLASSPATH. The >>> server loader could already be too late. That means it is also visible to >>> any webapp. And activating it is done either via a system property, or a >>> resource named log4j2.component.properties which contains the property >>> >>> Log4jLogEventFactory=org.apache.juli.JuliLogEventFactory >>> >>> Again this resource IMHO must reside in the CLASSPATH. So both ways of >>> activating the alternative LogEvent impl also activate it for any Log4J2 >>> in >>> any webapp. >>> >>> >>> True or not, nothing prevents to run it in a logger classloader to >> isolate >> from webapp. That said if you want tomcat to log with log4j2 you likely >> also want the webapps to do the same IMO. Also tomcat has a classloader >> context selector so config can be per webapp or at least hook is there for >> that. >> > > I was more concerned about a webapp that does not use juli, but uses > Log4J2 directly (or via SLF4J etc.). We should not disturb the behavior of > such a webapp by our Tomcat log setup. > > Yes Tomcat is not yet able to filter resources by classloader (Loader could get a config for that with defaults, we d
Re: TC 8.5 and Log4J2 via Juli: Wrong location info
2016-10-26 11:50 GMT+02:00 Rémy Maucherat : > 2016-10-26 11:38 GMT+02:00 Rainer Jung : > > > Note that for the jul bridge to work, the Log4J2 jar files have to be put > > onto the CLASSPATH (otherwise the Log4J2 jul LogManager can't be used) > and > > so the resource pointing to the custom LogEventFactory must sit there as > > well. > > > > But it seems one of my early tests was wrong. The custom factory is *not* > > being loaded by a webapp local Log4J2 instance. At least not with the > setup > > I originally described. > > > > So putting the factory and the log4j2.component.properties file into the > > tomcat-juli.jar should be transparent (to webapps and also the setups > which > > do not use Log4J2 at all) and would be one solution to the original > problem > > of wrong location info. I still need to test behavior if webapps use juli > > as well. > > > > Whether we also want to directly support Log4J2 with an SPI provided Log > > implementation that delegates to Log4J2 is still open. Personally I find > it > > somewhat cleaner to point to the Log4J standard way (adding the jul > bridge > > and other log4j jar files as well as the LogManager system property) > > instead of needing to activate/add a separate TC jar file containing the > > new Log impl and SPI meta data. It seems the only way to activate the log > > impl via SPI is adding the containing jar to the class loader search path > > (likely CLASSPATH). > > > > One of the problems of using a standard logging framework was class > conflicts (the webapps can see a shared log4j, they can try to override it, > but it could cause issues). > If I got the original issue right, it is only about allowing a user to replace the default (JULi) so should be acceptable, no? > > Rémy >
Re: TC 8.5 and Log4J2 via Juli: Wrong location info
2016-10-26 16:02 GMT+02:00 Rémy Maucherat : > 2016-10-26 15:32 GMT+02:00 Romain Manni-Bucau : > > > If I got the original issue right, it is only about allowing a user to > > replace the default (JULi) so should be acceptable, no? > > > > Right, but once you place your logging framework in the main CL, you > could > run into issues. The default is indeed not affected. > > You can see it both way " i"m affected" or "yeah, I inherit from the ops config". That why I think it is good to let it be "up to the user". > Rémy >
potential NPE on 8.5.13
Hi guys,
seems on the last release we can get a NPE we didnt get before.
In org.apache.catalina.core.ApplicationMapping#getServletMapping for case
PATH pathInfo can be null so the toString() doesnt behave very well.
Got it with a @WebServlet("/foo/*")
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: potential NPE on 8.5.13
oops, hit enter too fast
important detail: it is in a request.getRequestDispatcher("WEB-INF/test.jsp"
).forward(request, response);
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-03-30 19:40 GMT+02:00 Romain Manni-Bucau :
> Hi guys,
>
> seems on the last release we can get a NPE we didnt get before.
>
> In org.apache.catalina.core.ApplicationMapping#getServletMapping for case
> PATH pathInfo can be null so the toString() doesnt behave very well.
>
> Got it with a @WebServlet("/foo/*")
>
> 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: potential NPE on 8.5.13
experienced it only on 8.5.13, 8.5.12 was working fine
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-03-30 19:53 GMT+02:00 Violeta Georgieva :
> Hi,
>
> 2017-03-30 20:41 GMT+03:00 Romain Manni-Bucau :
> >
> > oops, hit enter too fast
> >
> > important detail: it is in a
> request.getRequestDispatcher("WEB-INF/test.jsp"
> > ).forward(request, response);
>
> Do you experience this with 8.5.12 (latest release) or 8.5.13 (currently
> release that we vote)?
> We have a fix in 8.5.13 for an issue similar to what you describe.
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60882
>
> Regards,
> Violeta
>
> >
> > 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-03-30 19:40 GMT+02:00 Romain Manni-Bucau :
> >
> > > Hi guys,
> > >
> > > seems on the last release we can get a NPE we didnt get before.
> > >
> > > In org.apache.catalina.core.ApplicationMapping#getServletMapping for
> case
> > > PATH pathInfo can be null so the toString() doesnt behave very well.
> > >
> > > Got it with a @WebServlet("/foo/*")
> > >
> > > 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: potential NPE on 8.5.13
hmm, after a deeper check it seems it can be IDE related. I'll run tomee
test suite this night with that upgrade (8.5.13), think it could have been
due to a messy Idea cache. Will report tomorrow morning the results. Thanks
Violeta to have pointed this bugzilla out, helped to see that.
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-03-30 21:50 GMT+02:00 Romain Manni-Bucau :
> experienced it only on 8.5.13, 8.5.12 was working fine
>
>
> 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-03-30 19:53 GMT+02:00 Violeta Georgieva :
>
>> Hi,
>>
>> 2017-03-30 20:41 GMT+03:00 Romain Manni-Bucau :
>> >
>> > oops, hit enter too fast
>> >
>> > important detail: it is in a
>> request.getRequestDispatcher("WEB-INF/test.jsp"
>> > ).forward(request, response);
>>
>> Do you experience this with 8.5.12 (latest release) or 8.5.13 (currently
>> release that we vote)?
>> We have a fix in 8.5.13 for an issue similar to what you describe.
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=60882
>>
>> Regards,
>> Violeta
>>
>> >
>> > 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-03-30 19:40 GMT+02:00 Romain Manni-Bucau :
>> >
>> > > Hi guys,
>> > >
>> > > seems on the last release we can get a NPE we didnt get before.
>> > >
>> > > In org.apache.catalina.core.ApplicationMapping#getServletMapping for
>> case
>> > > PATH pathInfo can be null so the toString() doesnt behave very well.
>> > >
>> > > Got it with a @WebServlet("/foo/*")
>> > >
>> > > 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: potential NPE on 8.5.13
Seems it was it. TomEE is almost green with a "clean" 8.5.13.
Only issue I got was: javax.management.ServiceNotFoundException: Cannot
find operation getLastAccessedTimestamp
In a test we use JMX to get some meta about the sessions.
Issue comes from that
commit
org.apache.tomcat.util.modeler.ManagedBean#createOperationKey(java.lang.String,
java.lang.String[]) where the join value is not used and the signature with
a hook where the append would be done is not used as well.
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-03-30 22:00 GMT+02:00 Romain Manni-Bucau :
> hmm, after a deeper check it seems it can be IDE related. I'll run tomee
> test suite this night with that upgrade (8.5.13), think it could have been
> due to a messy Idea cache. Will report tomorrow morning the results. Thanks
> Violeta to have pointed this bugzilla out, helped to see that.
>
>
> 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-03-30 21:50 GMT+02:00 Romain Manni-Bucau :
>
>> experienced it only on 8.5.13, 8.5.12 was working fine
>>
>>
>> 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-03-30 19:53 GMT+02:00 Violeta Georgieva :
>>
>>> Hi,
>>>
>>> 2017-03-30 20:41 GMT+03:00 Romain Manni-Bucau :
>>> >
>>> > oops, hit enter too fast
>>> >
>>> > important detail: it is in a
>>> request.getRequestDispatcher("WEB-INF/test.jsp"
>>> > ).forward(request, response);
>>>
>>> Do you experience this with 8.5.12 (latest release) or 8.5.13 (currently
>>> release that we vote)?
>>> We have a fix in 8.5.13 for an issue similar to what you describe.
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=60882
>>>
>>> Regards,
>>> Violeta
>>>
>>> >
>>> > 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-03-30 19:40 GMT+02:00 Romain Manni-Bucau :
>>> >
>>> > > Hi guys,
>>> > >
>>> > > seems on the last release we can get a NPE we didnt get before.
>>> > >
>>> > > In org.apache.catalina.core.ApplicationMapping#getServletMapping for
>>> case
>>> > > PATH pathInfo can be null so the toString() doesnt behave very well.
>>> > >
>>> > > Got it with a @WebServlet("/foo/*")
>>> > >
>>> > > 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: potential NPE on 8.5.13
thanks!
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-04-03 15:59 GMT+02:00 Violeta Georgieva :
> Hi,
>
> 2017-03-31 0:06 GMT+03:00 Romain Manni-Bucau :
> >
> > Seems it was it. TomEE is almost green with a "clean" 8.5.13.
> >
> > Only issue I got was: javax.management.ServiceNotFoundException: Cannot
> > find operation getLastAccessedTimestamp
> >
> > In a test we use JMX to get some meta about the sessions.
> >
> > Issue comes from that
> > commit
> org.apache.tomcat.util.modeler.ManagedBean#createOperationKey(java.lang.
> String,
> > java.lang.String[]) where the join value is not used and the signature
> with
> > a hook where the append would be done is not used as well.
>
> I believe this change below fixes this. The fix will be available in
> 8.5.14.
> http://svn.apache.org/viewvc?view=revision&revision=1789941
>
> Regards,
> Violeta
>
> >
> > 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-03-30 22:00 GMT+02:00 Romain Manni-Bucau :
> >
> > > hmm, after a deeper check it seems it can be IDE related. I'll run
> tomee
> > > test suite this night with that upgrade (8.5.13), think it could have
> been
> > > due to a messy Idea cache. Will report tomorrow morning the results.
> Thanks
> > > Violeta to have pointed this bugzilla out, helped to see that.
> > >
> > >
> > > 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-03-30 21:50 GMT+02:00 Romain Manni-Bucau :
> > >
> > >> experienced it only on 8.5.13, 8.5.12 was working fine
> > >>
> > >>
> > >> 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-03-30 19:53 GMT+02:00 Violeta Georgieva :
> > >>
> > >>> Hi,
> > >>>
> > >>> 2017-03-30 20:41 GMT+03:00 Romain Manni-Bucau >:
> > >>> >
> > >>> > oops, hit enter too fast
> > >>> >
> > >>> > important detail: it is in a
> > >>> request.getRequestDispatcher("WEB-INF/test.jsp"
> > >>> > ).forward(request, response);
> > >>>
> > >>> Do you experience this with 8.5.12 (latest release) or 8.5.13
> (currently
> > >>> release that we vote)?
> > >>> We have a fix in 8.5.13 for an issue similar to what you describe.
> > >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=60882
> > >>>
> > >>> Regards,
> > >>> Violeta
> > >>>
> > >>> >
> > >>> > 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-03-30 19:40 GMT+02:00 Romain Manni-Bucau <
> rmannibu...@gmail.com
> >:
> > >>> >
> > >>> > > Hi guys,
> > >>> > >
> > >>> > > seems on the last release we can get a NPE we didnt get before.
> > >>> > >
> > >>> > > In org.apache.catalina.core.ApplicationMapping#getServletMapping
> for
> > >>> case
> > >>> > > PATH pathInfo can be null so the toString() doesnt behave very
> well.
> > >>> > >
> > >>> > > Got it with a @WebServlet("/foo/*")
> > >>> > >
> > >>> > > 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>
> > >>> > >
> > >>>
> > >>
> > >>
> > >
>
scanning in embedded mode
Hi guys, on java 9 in embedded mode the app loader is no more a URLClassLoader so StandardScanner "fails" silently. Is it plan to read java.class.path as a fallback or something else? 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>
websocket and custom instantiator
Hi guys, on 9M15 it seems the default server configurator just uses a newInstance and not the instance manager. Any reason? Is it too hard to catch close and destroy instances properly? Issue is it makes hard to integrate with an IoC without needing some boilerplate in onopen() and onclose(). 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: websocket and custom instantiator
PS: same for encoders/decoders BTW 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> 2016-12-12 22:03 GMT+01:00 Romain Manni-Bucau : > Hi guys, > > on 9M15 it seems the default server configurator just uses a newInstance > and not the instance manager. Any reason? Is it too hard to catch close and > destroy instances properly? > > Issue is it makes hard to integrate with an IoC without needing some > boilerplate in onopen() and onclose(). > > 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: websocket and custom instantiator
2016-12-13 11:18 GMT+01:00 Rémy Maucherat : > 2016-12-12 22:03 GMT+01:00 Romain Manni-Bucau : > > > Hi guys, > > > > on 9M15 it seems the default server configurator just uses a newInstance > > and not the instance manager. Any reason? Is it too hard to catch close > and > > destroy instances properly? > > > > Issue is it makes hard to integrate with an IoC without needing some > > boilerplate in onopen() and onclose(). > > > > It gets registered a little bit later in WsSession. > > Hmm, didn't see it, do you have the class/method? > Ok for encoder/decoder, this is not done, but is it certain these objects > are injectable ? > > By spec not sure but would be nice to inject a reusable codec or serializer which can optimize the data (@Inject Jsonb for instance). Shouldn't cost much to tomcat since instance manager is there. > Rémy > > > > > > 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> > > >
websocket and lambdas
Hi guys,
is it under radar lambdas don't work with websocket programmatic API?
session.addMessageHandler(new MessageHandler.Whole() {
@Override
public void onMessage(final Request request) {
*// whatever*
}
});
If you convert it in a lambda ((MessageHandler.Whole) m -> {})
then tomcat is not able to extract the type. There are several solution on
the net I think about it so I guess it should be doable?
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: websocket and lambdas
right, so means the other addmessagehandler is seen as a shortcut
(convenient).
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>
2016-12-13 20:58 GMT+01:00 Violeta Georgieva :
> Hi,
>
> 2016-12-13 20:41 GMT+02:00 Romain Manni-Bucau :
> >
> > Hi guys,
> >
> > is it under radar lambdas don't work with websocket programmatic API?
> >
> > session.addMessageHandler(new MessageHandler.Whole() {
> > @Override
> > public void onMessage(final Request request) {
> > *// whatever*
> > }
> > });
> >
> >
> > If you convert it in a lambda ((MessageHandler.Whole) m -> {})
> > then tomcat is not able to extract the type. There are several solution
> on
> > the net I think about it so I guess it should be doable?
> >
>
> This is working for me
>
> Instead of:
>
> session.addMessageHandler(new MessageHandler.Whole() {
> @Override
> public void onMessage(String message) {
> *// whatever*
> }
> });
>
> this one:
>
> session.addMessageHandler(String.class, message -> {
> *// whatever*
> });
>
> Regards,
> Violeta
>
> > 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: Need to consider a replacement for */ in WAR URLs
Hi Mark Issue for 3rd party is whatever you choose it will not untegrate smoothly - !/ is often handled, more rarely but still when nested, never when something else - so wonder if tomcat needs urls and cant just handle nested ones without an url handler since tomcat owns them. Also means for the integration part that scanner can need to be reworked, a bit like xbean finder probably, to make consumer coding easier. Le 16 janv. 2017 12:24, "Mark Thomas" a écrit : > For the background see: > https://github.com/spring-projects/spring-boot/issues/7949 > > The short version is: > > * is seen as a wild card in some environments. > > The options are: > $ & ' ( ) * , - . : ; @ _ ~ > (all followed by /) > > Ideally we want a character that: > - is unlikely to appear in a file name (particularly at the end) > - does not have a special meaning that could conflict when using it in > combination with / in a URI to mark the start of the internal WAR path. > > Thoughts, comments, reasons for excluding one or more of these > characters welcome. > > Mark > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
release 8.5.11 and 9.0.0.M17
Hi guys, when is planned to release these 2 versions (I'm interested in getting them from central)? Votes passed 2 days ago but it is still not there. 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: release 8.5.11 and 9.0.0.M17
FYI it is now on central! Thanks guys 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-18 11:58 GMT+01:00 Mark Thomas : > On 18/01/2017 10:54, Romain Manni-Bucau wrote: > > Hi guys, > > > > when is planned to release these 2 versions (I'm interested in getting > them > > from central)? Votes passed 2 days ago but it is still not there. > > I released them from repository.a.o yesterday around the same time I > updated the website. I'd give it another 24 hours and then ping infra if > they haven't turned up. > > Mark > > > > > > 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> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: HTTP response reason phrases
Hi guys, 8.5 just being almost a N-1 spec version of tomcat 9 I think they should stay aligned as much as possible. Also note that fixing it in 8.5 will just delay the issue for 9.x. I'm not sure I see the blocking point to add a configuration for that (agree it is not spec compliant but it is a nice feature for broken clients which are widely spread in some languages) but please keep 8.5 and 9 aligned since migrations are expected (and are) smooth for now. 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-25 11:27 GMT+01:00 Rainer Jung : > Am 25.01.2017 um 11:09 schrieb Rainer Jung: > >> Am 24.01.2017 um 21:03 schrieb Mark Thomas: >> >>> On 24/01/2017 19:08, Christopher Schultz wrote: >>> >>> I'm wondering what the wider community thinks about this change and >>>> whether or not we should consider reverting it for Tomcat 8.5.x. >>>> >>> >>> 8.5.x has been out for 10 months and stable for 7. It is probably still >>> early enough that we are seeing issues from the early adopters. We >>> might, therefore, see more issues moving forwards. >>> >>> This change is listed in the change-log for 8.5.0. >>> >>> The root cause is non-specification compliant clients. I generally don't >>> view specification non-compliance in third party code a good reason to >>> make a change in Tomcat. >>> >>> Overall I am -0 on reverting the change for 8.5.x. >>> >> >> For 8.5 we should be aware of the fact, that 8.5 was meant as a quick >> replacement for 8.0 with a reduced support time for 8.0. We also used >> wording like "superseded" on the "Which version" page and probably the >> overall impression is people should soon switch from 8.0 to 8.5 and the >> switch is an easy one to do as long as you do not start to use the new >> features. >> >> Dropping the reason phrase probably is mostly motivated by the new >> language "A client SHOULD ignore the reason-phrase content." in RFC 7230 >> section 3.1.2. Although also the older RFC 2616 already allowed an empty >> reason phrase "Reason-Phrase = *" the language >> was less strict: "The client is not required to examine or display the >> Reason-Phrase.". >> >> IMHO it was only later that servers actually started to drop the reason >> phrase to save a few bytes. Originally it was deemed useful as the old >> spec states "The Reason-Phrase is intended to give a short textual >> description of the Status-Code. The ... Reason-Phrase is intended for >> the human user." >> >> The compatibility break with clients who do not confirm to the newer >> http spec and instead demand the reason phrase will break any >> communication with them. It is not a "be strict in what you send" >> situation for us as a server, because the spec does not require us to >> send an empty reason phrase. >> >> So given the fact that there's no workaround for people who need to >> support clients which require a non-empty reason phrase and also that >> our story for users of 8.0 is to migrate soon and easy to 8.5, I would >> be +1 for a configurable option to bring back reason phrases. Default >> would be "no reason phrases". >> > > I forgot: an option only for 8.5. Dropping it in 9.0 is fine for me. > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: HTTP response reason phrases
2017-01-25 20:51 GMT+01:00 Christopher Schultz : > Romain, > > On 1/25/17 5:30 AM, Romain Manni-Bucau wrote: > > 8.5 just being almost a N-1 spec version of tomcat 9 I think they should > > stay aligned as much as possible. > > Yes, but 8.5 is a N+0 spec version of Tomcat 8.0. I think since Tomcat > 8.5 is being pushed as the hurry-up upgrade for Tomcat 8.0, it should be > more compatible with Tomcat 8.0 when there is a choice. > > I think Rainer articulated this better than I could. > > I see (interesting to see that .5 is closer to 1 for some and to 0 for others ;)). However I think it doesn't change the fact it delay the issue for some time so would be curious to see the actual issue having it configurable, if none it is surely the best way to make everyone happy, no? > On 1/25/17 5:09 AM, Rainer Jung wrote: > > So given the fact that there's no workaround for people who need to > > support clients which require a non-empty reason phrase and also that > > our story for users of 8.0 is to migrate soon and easy to 8.5, I would > > be +1 for a configurable option to bring back reason phrases. Default > > would be "no reason phrases". > > -chris > > >
Re: InstanceListener, InstanceEvent: Unused?
Hi TomEE uses it but nothing justifying to keep the api - we can do it in another manner if needed. Le 4 janv. 2016 17:14, "Mark Thomas" a écrit : > Given that the Tomcat code doesn't contain any classes that implement > InstanceListener is looks to be unused internally. I'm wondering if > anyone else is using it. If not, there is a chunk of code we could > remove including a bunch of (admittedly simple/fast) calls made on every > request. > > Could we deprecate this in 8.0.x and remove it in 9.0.x? > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
regression due to https://bz.apache.org/bugzilla/show_bug.cgi?id=58867 ?
Hi guys,
in https://bz.apache.org/bugzilla/show_bug.cgi?id=58867 there is this diff:
-if (!docDir.exists()) {
-File warFile = new File(docBase + ".war");
-if (warFile.exists()) {
-URL war =
-new URL("jar:" + warFile.toURI().toURL() + "!/");
+File warFile = new File(docBase + ".war");
+URL war = null;
+if (warFile.exists()) {
+war = new URL("jar:" + warFile.toURI().toURL() + "!/");
+}
+if (docDir.exists()) {
+if (war != null && unpackWARs) {
+// Check if WAR needs to be re-expanded (e.g. if it has
+// changed). Note: HostConfig.deployWar() takes care of
+// ensuring that the correct XML file is used.
+// This will be a NO-OP if the WAR is unchanged.
+ExpandWar.expand(host, war, pathName);
+}
+} else {
so if you were deploying a StandardContext with a docDir set to a correct
path and if the war was next to this path then all was working smoothly ie
the manually exploded folder was deployed.
Now (8.0.32) the war is re-expanded in webapps (by default). Of course a
work around is to set unpackWARs to false but it is a regression in term of
behavior which is quite nasty IMO.
Was it really intended or is it a side effect of the fix?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
Re: regression due to https://bz.apache.org/bugzilla/show_bug.cgi?id=58867 ?
Hi mark,
if you put a war in a specific folder then expand it yourself next to the
war and do something like:
StandardContext ctx = new StandardContext();
// several set
ctx.setDocBase("/my/expanded/"); // /my/expanded.war exists since that's
where we come from
host.addChild(ctx);
then you get a duplicated deployment with autodeploy settings and unpackWAR
set to true. It sounds like the wrong behavior to me since the auto deploy
doesnt apply to /my/ folder but ${tomcat.base}/webapps - by default.
Tomcat class does it for instance, TomEE does it too and fixed it
preventing unpacking and several tools around tomcat as well. I guess - can
check if needed - a plain tomcat installation can get it setting an
absolute docBase on .
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2016-02-09 1:35 GMT+01:00 Mark Thomas :
> On 8 February 2016 21:21:36 GMT+00:00, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
> >Hi guys,
> >
> >in https://bz.apache.org/bugzilla/show_bug.cgi?id=58867 there is this
> >diff:
> >
> >-if (!docDir.exists()) {
> >-File warFile = new File(docBase + ".war");
> >-if (warFile.exists()) {
> >-URL war =
> >-new URL("jar:" + warFile.toURI().toURL() +
> >"!/");
> >+File warFile = new File(docBase + ".war");
> >+URL war = null;
> >+if (warFile.exists()) {
> >+war = new URL("jar:" + warFile.toURI().toURL() +
> >"!/");
> >+}
> >+if (docDir.exists()) {
> >+if (war != null && unpackWARs) {
> >+// Check if WAR needs to be re-expanded (e.g. if
> >it has
> >+// changed). Note: HostConfig.deployWar() takes
> >care of
> >+// ensuring that the correct XML file is used.
> >+// This will be a NO-OP if the WAR is unchanged.
> >+ExpandWar.expand(host, war, pathName);
> >+}
> >+} else {
> >
> >
> >so if you were deploying a StandardContext with a docDir set to a
> >correct
> >path and if the war was next to this path then all was working smoothly
> >ie
> >the manually exploded folder was deployed.
> >
> >Now (8.0.32) the war is re-expanded in webapps (by default). Of course
> >a
> >work around is to set unpackWARs to false but it is a regression in
> >term of
> >behavior which is quite nasty IMO.
> >
> >Was it really intended or is it a side effect of the fix?
>
> Can you explain the problem more clearly please. Reference to a specific
> example with file names would help.
>
> I can make some assumptions about what I think you are reporting but a
> clearer explanation would be a better starting point.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: regression due to https://bz.apache.org/bugzilla/show_bug.cgi?id=58867 ?
Thanks a lot Mark!
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2016-02-10 16:17 GMT+01:00 Mark Thomas :
> On 09/02/2016 08:29, Mark Thomas wrote:
> > On 09/02/2016 07:33, Romain Manni-Bucau wrote:
> >> Hi mark,
> >>
> >> if you put a war in a specific folder then expand it yourself next to
> the
> >> war and do something like:
> >>
> >> StandardContext ctx = new StandardContext();
> >> // several set
> >> ctx.setDocBase("/my/expanded/"); // /my/expanded.war exists since that's
> >> where we come from
> >> host.addChild(ctx);
> >>
> >> then you get a duplicated deployment with autodeploy settings and
> unpackWAR
> >> set to true. It sounds like the wrong behavior to me since the auto
> deploy
> >> doesnt apply to /my/ folder but ${tomcat.base}/webapps - by default.
> >
> > Thanks for the additional detail. I was indeed making some invalid
> > assumptions about what the problem was.
> >
> > I'll take a look at this later today.
>
> Sorry for the delay. I got side-tracked.
>
> This is fixed in trunk and 8.0.x and will be in the next release of each
> (in around a month's time).
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Context path: any technical reason to ignore it?
Hi guys, in /META-INF/context.xml was used a lot for tomcat 6/7 and doesn't work anymore since tomcat 8 (didn't check if it has been backported, can be). It is documented but I don't get why this feature has been removed. typically checking if path is null or not before setting ContextName would be enough to keep the feature working. Do I miss anything? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com>
Re: Context path: any technical reason to ignore it?
On a personal side i tend to agree and like to have filesystem aligned with the deployment but I have to admit I saw path usage in META-INF/context.xml being quite large (in real deployments or in tooling integration). I understand your example but it is true at each level including conflicting names in conf/* or server.xml. Now 90% of the usages are to strip the version from the war name (most build tools generate mywar-1.2.3[.QUALIFIER]. Maybe a flag to strip it on tomcat side would solve most of the cases and don't encourage that much the risk you refer to? Something like: Wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2016-02-18 11:56 GMT+01:00 Mark Thomas : > On 18/02/2016 10:42, Romain Manni-Bucau wrote: > > Hi guys, > > > > in /META-INF/context.xml was used a lot > > for tomcat 6/7 and doesn't work anymore since tomcat 8 (didn't check if > it > > has been backported, can be). > > > > It is documented but I don't get why this feature has been removed. > > typically checking if path is null or not before setting ContextName > would > > be enough to keep the feature working. > > > > Do I miss anything? > > Yes. Consider the following: > > test1.war with META-INF/context.xml containing > test2.war with no context.xml > > Put them both in the appBase of a default, running Tomcat instance. What > happens? > > If you want to change the path, either: > - change the name of the WAR > or > - locate it outside the appBase and put a context.xml file in > conf// > > The only place path is used is if the Context is defined in server.xml > and defining contexts in server.xml is strongly discouraged. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Context path: any technical reason to ignore it?
2016-02-18 12:02 GMT+01:00 Konstantin Kolinko : > 2016-02-18 13:42 GMT+03:00 Romain Manni-Bucau : > > Hi guys, > > > > in /META-INF/context.xml was used a lot > > for tomcat 6/7 and doesn't work anymore since tomcat 8 (didn't check if > it > > has been backported, can be). > > > > It is documented but I don't get why this feature has been removed. > > typically checking if path is null or not before setting ContextName > would > > be enough to keep the feature working. > > > > Do I miss anything? > > > The "path" attribute is allowed only when Context element is declared > in server.xml. In all other cases it is ignored in Tomcat > 5.5/6.0/7.0/8.0/9.0 as far as I remember (for the last ~5 years). It > does not work in 6/7, contrary to your claim. > > Seems true, saw it a lot in tomcat 7 apps and assumed it was there so used. Was probably silently ignored. > > The main reasons are reducing ambiguity and implementation of > (auto)deployment. Note that > > 1. There are several steps that occur before context.xml is read. > 2. Deployment is protected by a lock keyed by web application name or > path. Look for "serviced", "isServiced". > > Should still be doable when constructing the StandardContext and before it is added to the host. Just means the standard context needs to be built and check can't be done just on filename but I don't see it as a blocker. I'm not a big fan of this (potential) feature but I have to admit it can save you some headache and time when you don't control the full server or deployment process. In cloud environments it would also be a simple and potentially "tomcat-standard" way to configure the path. Any hope to get the feature? > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Context path: any technical reason to ignore it?
2016-02-18 17:20 GMT+01:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Romain, > > On 2/18/16 6:00 AM, Romain Manni-Bucau wrote: > > On a personal side i tend to agree and like to have filesystem > > aligned with the deployment but I have to admit I saw path usage in > > META-INF/context.xml being quite large (in real deployments or in > > tooling integration). > > My preference would be to refuse to deploy an application with a > "path" attribute in a context.xml file. I haven't studied the code > well enough to know if it's possible (or reasonable) to know whether > the context is being configured based upon a context.xml file or from > within server.xml. > > It is possible AFAIK since the context.xml is created from a file in this case so we know which one. > > I understand your example but it is true at each level including > > conflicting names in conf/* or server.xml. > > > > Now 90% of the usages are to strip the version from the war name > > (most build tools generate mywar-1.2.3[.QUALIFIER]. > > You mean when parallel deployment is NOT in use? > > Yep, parallel deployment would just add another suffix not influencing the path so the user doesnt care for the purpose of this thread. > > Maybe a flag to strip it on tomcat side would solve most of the > > cases and don't encourage that much the risk you refer to? > > > > Something like: > > > > > > I think this can still lead to undefined behavior when different web > applications overlap. We would have to either throw up our hands and > say "caveat deployor" or do a whole bunch of work to cover this edge cas > e. > > My vote would be to make users follow the existing rules. Removing a > version number from a WAR is easy: use conf/[engine]/[host]/[app].xml > and point it to the WAR file outside of the appbase. Done. > > Ok, now let's assume you control only the content of the .war you deploy (not the name since it is in a continuous deployment (or test) tooling, not the conf/ since it is a shared instance where you team doesnt have access. I think the cost of handling path - without breaking current conflicting name feature, just need few code changes - is worth the headache the users have. That said if really an issue for tomcat can you at least: - log an error (warn maybe?) saying path is ignored. Since there is a setter it is swallowed silently. - open a way to force it from the webapp even if it logs a warning (maybe a flag userForced). Today even forcing it manually through a listener it is ignored (= there is no real good moment in a prod instance - with other advanced listeners we don't control - to do so). Worse case having a server.xml flag can be a degraded option which can maybe be enough in practise. > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlbF7zoACgkQ9CaO5/Lv0PDdmwCgvFBMRFCb0OcnSpbX0G85JtUf > JoMAn3o31j2N4buEDStCSy8ikVAtMQ70 > =N+M6 > -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 9.0.13
+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: AccessLogValve using STDOUT
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 > >
