Re: Jakarta EE 11 may be changing minimum Java version to 17
> On Feb 20, 2024, at 8:08 AM, Mark Thomas wrote: > > Looking at the latest version of the Jakarta EE 11 release plan, the minimum > Java version has been dropped to Java 17. > > https://jakartaee.github.io/platform/jakartaee11/JakartaEE11ReleasePlan > > On that basis I think we have no choice but to reduce the minimum Java > version for Tomcat 11 to Java 17. Implementations are not required to support Java 17, it is simply now one of the allowed options. We can absolutely continue with java 21 (or any JDK 17 or up) if we like. The decision was made to allow implementations to certify with 17 support if they wanted as none of the specs took advantage of Java 21 features, so there is no real basis to reject their certification requests. It is still hoped there will be implementations that take advantage of Java 21 features and brag publicly about them. -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [DISCUSS] EOL date for 8.5.x
> On Oct 21, 2022, at 12:12 PM, Christopher Schultz > wrote: > > I'm wondering if I should migrate my applications to 9.0 or 10.x and start > re-writing imports. The flexibility of Tomcat 10.x is just incredible. I'm > kind of leaning toward skipping 9.x. Do it! :) -David smime.p7s Description: S/MIME cryptographic signature
Re: [DISCUSS] EOL date for 8.5.x
> On Oct 7, 2022, at 2:27 AM, Mark Thomas wrote: > > Hi all, > > I don't think there is a need to make a decision on this quickly, but based > on past experience and the current discussions about Jakarta EE 11 I think > this is something we need to start thinking about. > > Some key facts: > > - Tomcat 7.0.x reached EOL on 31 March 2021 > - EOL dates for major versions tend to be 3-4 years apart > - We aim to support 3 major versions in parallel - currently 8.5.x, > 9.0.x and 10.1.x. > - Tomcat 11 will implement Jakarta EE 11 > - Current Jakarta EE discussions are around a release in ~1 year > - Ideally, Tomcat 8.5.x EOL would be just after Tomcat 11 is declared > stable > > Based on the above I think EOL for 8.5.x should be either 31 March 2024 or 30 > Sept 2024 depending on when we think Jakarta EE 11 will be released. > > Jakarta EE releases have tendency to slip so I think the 30 Sept 2024 is > probably the more likely. However, it is much easier to delay an EOL date > than to bring to bring it forward so my current thinking is to announce 31 > March 2024 as the EOL date for 8.5.x and keep in mind that we can extend that > if we want to. > > Thoughts? Sounds good to me. From a TomEE perspective, the only release streams that'd be affected are TomEE 7.1 and 7.0. Both of those already have unmaintained dependencies with CVEs, so releases of them have already stopped. -David smime.p7s Description: S/MIME cryptographic signature
Re: Possible Connector doc update with NIO & NIO2
> On May 19, 2022, at 5:16 PM, David Blevins wrote: > > - useSendfile > Quick correction. This one seems to be common between NIO, NIO2 and Apr and has the same description in all three. Potentially it could go in the "Common Attributes" section. -David smime.p7s Description: S/MIME cryptographic signature
Possible Connector doc update with NIO & NIO2
Hey All, I was picking through the connector docs generating some code from the descriptions and I noticed there are a handful of properties common between NIO and NIO2. - socket.appReadBufSize - socket.appWriteBufSize - socket.directBuffer - socket.directSslBuffer - useSendfile These attributes have the exact same description in both the NIO and NIO2 sections. Should they be moved into the "Java TCP socket attributes" section which is somewhat dedicated to attributes NIO and NIO2 have in common? Note, I do definitely see there are attributes with the same name but different descriptions/defaults. In particular: - socket.bufferPool - socket.processorCache Should I submit a PR to move some or all of the first 5 or should they be left where they are? -David smime.p7s Description: S/MIME cryptographic signature
Re: Potential mention on the website
> On Mar 31, 2022, at 12:13 PM, Christopher Schultz > wrote: > > Mark, > > On 3/29/22 19:40, Mark Thomas wrote: >> I worry that putting much more than a simple link on the which version page >> could cause confusion. Something like: >> "For users wanting a Java EE / Jakarta EE container that supports additional >> specifications like XXX see Apache TomEE." > > +1 > >> My preference is for a new menu item - probably under misc - called "Related >> Apache Projects" (a shorter, snappier title preferred) where we can link to >> the various ASF projects related to Tomcat and have a paragraph or two on >> each project. > > I like this. What else might qualify? If it's really only TomEE (and flavors > thereof), we could name that section "Enterprise .. something". > >> Off the top of my head, there is Ant (initially created to build Tomcat), >> Commons Pool, DBCP, Modeler, Daemon (all spun off from Tomcat), httpd, TomEE >> and probably a bunch I have forgotten about. > > Digester, another Tomcat graduate. > > Other than TomEE (and httpd), those are all dependencies / upstream from > Tomcat, which IMO puts TomEE in a slightly different bucket. I would say that > httpd isn't really "related" to Tomcat other than (a) they are both ASF > projects and (b) they are both web servers. But there's also ATS, ATC and > probably one or two other web servers under ASF umbrella I haven't heard of > yet. On httpd, I know a very large number of Tomcat/TomEE users I see in the wild use httpd in front for load balancing. I think a related projects page could be pretty great if we: - Mentioned why it is potentially interesting to Tomcat users and provided a pointer or two. I.e. treat it as documentation, not just a list of links. The section would still have to be brief -- no taking up a whole or even half a page. - Gave people a reason to look at it by linking to in other sections of the website beyond the left nav. It would be context dependent. For example, if we're talking about load balancing, we mention httpd and link to https://tomcat.apache.org/related.html#httpd. The whichversion.html could have the one sentence that mentions TomEE as a way to get more Jakarta EE impls on Tomcat out-of-the-box and link to https://tomcat.apache.org/related.html#tomee Could be a nice balance. We could still mention things like TomEE where needed, but they'd be going to a page with a great big "related projects" title and a clear statement these are external projects, which would allow us to give a bit more information on why it's useful for Tomcat people without potentially confusing people in thinking it's a Tomcat thing. Thoughts? -David smime.p7s Description: S/MIME cryptographic signature
Re: Potential mention on the website
> On Mar 28, 2022, at 10:12 AM, Christopher Schultz > wrote: > > David, > > On 3/26/22 14:13, David Blevins wrote: >> I've never had the bravery to ask > > Why the heck not? Perhaps it's a Geronimo hangover, but I never wanted to risk creating a situation where people felt forced or inadvertently create conflict. > >> but would there be some willingness to consider adding a mention of >> TomEE on the Tomcat website? > > I'm up for it. I can't imagine anyone on the Tomcat PMC would have any > problem with this. Anyone? > >> Any sign of pushback and I'll happily drop -- it's far more important >> to maintain good will, respect boundaries and keep things friendly. >> If there was some warmness to the idea, perhaps something very subtle >> at the bottom of the Tomcat description on the front page, "For >> distributions of Tomcat that contain Jakarta REST, Jakarta CDI, >> Jakarta Enterprise Beans (EJB) and similar specifications see Apache >> TomEE." > I guess the question would be "where is the best place to put this?" Does > TomEE have versions that track Tomcat versions in any way? Or do you just use > whatever version is "best at the time of packaging" or whatever? > > For example, relegating TomEE to the "download" page(s) would mean that > someone would have to know they want to download a specific Tomcat version, > then decide at the last second that they instead want TomEE. If you don't > release new versions every month (ish, like we do), then we could easily get > out of sync. It's a mix. Each TomEE major version will fix itself to a Tomcat major version. - TomEE 7 (Java EE 7) uses Tomcat 8.5 - TomEE 8 (Java EE 8) uses Tomcat 9 - TomEE 9 (Jakarta EE 9.x) uses Tomcat 10 TomEE 9 is still in milestone, but should be released in a few months. We've been basing our version numbers on the Java EE / Jakarta EE spec number. For Tomcat 10.1, TomEE 10, Jakarta EE 10, they'll be pretty close and might possibly sync perfectly at 11 -- for a while at least. On release speed, we definitely don't keep up with Tomcat pace -- we're more once a quarter than once a month. As well it can take us many months longer to reach final as there's a lot more in the box to certify. > I'm thinking that maybe what we should do it put TomEE on the "Which > version?" page (https://tomcat.apache.org/whichversion.html). Below the grid > of spec versions and associated Tomcat versions, we could put a heading which > says something along the lines of "Jakarta Foo + Bar are packaged with TomEE" > and just throw the user over to whatever page at TomEE makes the most sense. > > My only concern would be to properly inform users what is happening. I'm an > Eclipse user and any time I have to download a new version from their web > site I have to re-learn the differences between "Eclipse IDE for Java > Developers" and "Eclipse IDE for Java and DSL Developers" and "Eclipse IDE > for Enterprise Java and Web Developers" and I guess whatever the hell Thelia > is, now. > > I wouldn't want anyone to inadvertently install TomEE if all they really want > is Tomcat or "only" install Tomcat when they need the additional features and > APIs that TomEE provides. Perhaps just a reference to here would be > sufficient: https://tomee.apache.org/comparison.html I'm open to what people think is the right. The whichversion.html page idea could be good. A nice thing about a heading on the whichversion.html page is that it's something we can link to in the tomcat.apache.org website, say "https://tomcat.apache.org/whichversion.html#tomee; or something. When twitter polls like this happen we can paste the link and hopefully not see 50% of people saying "yes": - https://twitter.com/brunoborges/status/1507591056086343681 There were several TomEE mentions there, but my experience is unless they see it mentioned on the Tomcat website they often perceive it skeptically as a competitive effort against Tomcat. Under the heading we could have a few sentences with a bit more detail on which specs (the most popular ones as the full list is large), perhaps the Tomcat to TomEE version mapping, and a link to the https://tomee.apache.org/comparison.html page. Something brief, that's no bigger (ideally smaller) than the "Alpha / Beta / Stable" heading so as not to distract too much. If people are up for it, a very brief mention on the main page that links to the whichversion.html page would be effective. My gut is unless we put something there, most people won't see it and we'll likely only educate 5% or 10% of people who say "yes" to polls like one above. -David smime.p7s Description: S/MIME cryptographic signature
Potential mention on the website
Hey All, I've never had the bravery to ask, but would there be some willingness to consider adding a mention of TomEE on the Tomcat website? Any sign of pushback and I'll happily drop -- it's far more important to maintain good will, respect boundaries and keep things friendly. If there was some warmness to the idea, perhaps something very subtle at the bottom of the Tomcat description on the front page, "For distributions of Tomcat that contain Jakarta REST, Jakarta CDI, Jakarta Enterprise Beans (EJB) and similar specifications see Apache TomEE." Thoughts? -David smime.p7s Description: S/MIME cryptographic signature
Re: Potentially changing utilityThreadsAsDaemon default in 10
> On Aug 31, 2020, at 12:27 PM, Rémy Maucherat wrote: > > > On Mon, Aug 31, 2020 at 8:39 PM Mark Thomas wrote: > >> On 31/08/2020 17:17, David Blevins wrote: > >> Hey All, > >> > >> Curious if there would be any willingness to change the default of this to > >> true for Tomcat 10 prior to final release. > >> > >> - > >> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/core/StandardServer.java#L195 > > > > Unlikely based on the information provided. Making the utility threads > > daemon threads looks like a hack to work around a problem elsewhere. I'm > > more interested in tackling the root cause. > > I added the option because "you never know", but I don't quite see why it's a > good idea to interrupt this sort of work. I think the flag is only useful because the current default is true. The first default you put was false and I definitely agree with your commit message on it: "Those threads are not bad candidates for non daemon by default, given they are managed by an executor." [1] I agree with that as historically all pools in Tomcat were set as daemons, including all http thread pools. The main thread where `Catalina.start()` ran was the only non-daemon thread that could prevent a JVM exit. If you didn't set `await` in Catalina you got the intended consequence that no threads would be left holding the JVM open. This was a great contract for embedded environments like unit tests. In these scenarios where you did not want Tomcat internals hold the JVM open you just needed to take care to set `await` to false and all worked fine. The concern is when we add new threads that don't adhere to that contract everyone's embedded setups now break. - https://stackoverflow.com/questions/55382691/how-to-check-why-jvm-is-not-able-to-terminate - https://github.com/spring-projects/spring-boot/issues/17139 The reason I say the flag is limitedly useful is as Mark points out this flag doesn't have any influence over Tomcat standalone usage. There await is set to true and therefore the explicit `stop()` phase is called which will shutdown the utility pool, daemon or not. So while the change was invisible to standalone users, for all embedded users it was a breaking change over 9.0.13. When we introduce a breaking change like that causes people's unit tests or embedded environments to not terminate, everyone has to learn the hard way about the new flag and figure out how to work it in. I think the root issue is not actually about which is safer daemon or non-daemon threads, really more about adding new shutdown requirements in the middle of a major version. All the refactoring you did that whole month does underline how even with a lot of deliberation it's very tough to know which way to lean. It's usually those flip-flop situations where it's not clear what the right answer is that end up getting you. I'm incredibly grateful there is at least a flag there. What I would recommend is we agree on some sort of daemon thread policy. Some options: - All threads outside Catalina's "main" should be daemon by default - The daemon setting of threads outside Catalina's "main" should default to the value of Catalina.await - The daemon setting of threads outside Catalina's "main" should default to the value of some new very well-documented setting Thoughts? -David [1] https://github.com/apache/tomcat/commit/75489c324730511ab5ff12a0ee3606b7c8926726 smime.p7s Description: S/MIME cryptographic signature
Potentially changing utilityThreadsAsDaemon default in 10
Hey All, Curious if there would be any willingness to change the default of this to true for Tomcat 10 prior to final release. - https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/core/StandardServer.java#L195 The current default prevents a JVM shutdown and effectively means setting this to either true or false has no effect: - https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/startup/Catalina.java#L91 -David smime.p7s Description: S/MIME cryptographic signature
Re: CDI support improvements
> On Jun 12, 2019, at 6:35 AM, Rémy Maucherat wrote: > > On Wed, Jun 12, 2019 at 11:11 AM Mark Struberg > wrote: > > Rémy's enhancements are great - the better and cleaner the integration, the > better for all those projects. > But Romain and David are also correct: it's very easy to become a committer > on all the involved projects, especially for people known to deliver > outstanding code and to be excellent community players! I'll restate my position below just to be clear I am a fan of the effort. > Having a build reference to TomEE or OWB in Tomcat would introduce cycles in > our builds. This is not really a good thing. > > That did not seem very practical to me so the said code is quite Tomcat-like > right now and most importantly it needs the fixes made in 9.0.21, so it won't > work with any older Tomcat. If you really can take it over (and un-Tomcatize > the code, I suppose), no problem. The "Tomcat-like" is the part I really like. Some historical perspective from my eyes: - In Geronimo we did the integration "outside" Tomcat, by stripping it down - In TomEE we did the integration "inside" Tomcat, but making no changes I see this as a first attempt to potentially make some things easier in Tomcat itself and that is exciting and worth encouraging. > > > B.) We should also try to keep code and responsibilities at a single place > and shall try to avoid duplications. This has nothing to do with 'ownership' > - shuch a concept doesn't exist at the ASF anyway. But it has a lot to do > with users knowing exactly where to look at if they are searching for a bug > or even want to contribute a new feature. > > Ok, so I guess I don't need to do anything further in that area since you > prefer to continue covering it. I'll move on to other items on my todo list > then. I personally wouldn't want to see that. I restate that from my perspective, I'd be happy to make every attempt to drop no-longer-needed code from TomEE and uptake the newer code in Tomcat. My only pause is if people actually want a CDI integration here. If people think it's worth at least a poke, however, I'm all in. Is this something people would want and what is the best way to do it here-here? (not in one of our personal repos) -David
Re: CDI support improvements
> On Jun 11, 2019, at 12:02 PM, Mark Thomas wrote: > > On 11/06/2019 19:37, David Blevins wrote: >> >> At a high level, is there a desire to start supporting more "EE" like specs >> such as CDI, JAX-RS, JPA, etc? > > Make it easier to integrate? Sure. > > Implement additional specs? No. That's been my understanding as well. > On Jun 11, 2019, at 12:21 PM, Rémy Maucherat wrote: > > Ok, so the plan (my plan, actually) here is that I noticed CDI (and JAX-RS) > is the building block of many other APIs (like the Microprofile), so there's > a need to be able to use it in a "clean and light [and] in Tomcat spirit" way > (as you said). I had a look at OWB and CXF and while the support is there, it > needs some work (especially for the latter) and is certainly not user > friendly (again, esp for the latter). Note that the work is also in Tomcat > itself, since I'm in a good position to make changes and improvements as > needed. > > As for the answer, it would still be "no" at this point, since at most these > could be considered as a couple extra optional modules like the jdbc pool, or > maybe "build them yourself" poms. If CDI integration code were to live here, I'd probably want to see us rebase TomEE on top of it. That would probably mean occasional CDI-related PRs, documentation, dev threads, user questions, etc. It's a bit of a can of worms even if it's an add-on, which is why I ask the above. In the event people here prefer not to open that can of worms of supporting Tomcat+CDI integration code, it and you would be more than welcome in TomEE. We could have a "Tomcat+CDI" dist of TomEE that used just the new code. As noted above, we'd probably rebase the other TomEE dists on that one. It's been 8 years and I definitely have appetite for a fresh perspective (just like you, speaking for myself only not all of TomEE). I'm a fan wherever it lives. My concern would be if it happens here and isn't actually welcome. I would feel very awkward sending people over to help maintain it. -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: CDI support improvements
Hi All, At a high level, is there a desire to start supporting more "EE" like specs such as CDI, JAX-RS, JPA, etc? Completely understood if the answer is "depends." I suspect it would depend on if the code is clean and light in Tomcat spirit. I write this not from the perspective of "let's move a bunch of TomEE code into Tomcat", but more of "let's write cleaner newer code in Tomcat and retire equivalent TomEE code." That's not a specific proposal, just curious if appetite has developed in recent years to entertain tip-toeing beyond the same set of specs. -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau wrote: > > > > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat a écrit : > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau > wrote: > > Once done it can be hosted on both side.Owb has the advantage to be know by > users, tomcat to be a more natural home for an integration. At the end it is > mainly synchronizing both projects for a consistent communication and code > "move" IMHO. > > For deep tomcat/cxf integration, you can use > http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core module. > Technically it uses an embedded flavor but it would be easy to move to a > standalone one through a listener based on a small refactoring in > Meecrowave#start. The good part are the lifecycle and scanning integrations + > the tooling to make testing and dev simple - > http://openwebbeans.apache.org/meecrowave/. > > Ok, I think things look reasonably good using CDI extensions (looking at the > Geronimo mp implementation you did) except the default CXF "servlet" > integration. I think right now the "servlet" integration from the > cxf-rt-transports-http package is "bad" and that the one from Meecrowave (in > org.apache.meecrowave.cxf) is more likely to be the way to go (it derives > from cxf-integration-cdi). > > So this looks a lot closer to Meecrowave than I originally expected, with a > lot of "buts" though: > - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal here is > a "Meecrowave for Tomcat" > > Guess this one can converge - at least for TomEE it did and we have a tons of > flavors, I dont see a blocker to unify it here to. > > - The JAR has all of Tomcat, log4j, API JARs, etc, while it should here be > based off Tomcat, the javax APIs and OWB already present in the Tomcat OWB > implementation JAR (the classic "tomcat7" or the modernized "tomcat-owb") > > The jar is just one flavor of meecrowave - assuming you reference the fatjar, > you should still be able to use it as plain unitary dependencies. > The missing part here is to extract from Meecrowave master class all the > logic to "glue" the stack in Tomcat (mainly extracting it in a Listener I > guess and ignoring the specific launcher config?) > > - log4j would need to be removed as well > > It is already supported, in this IT we drop log4j, johnzon, cxf: > https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32 > > - plenty of configuration files and options in the JARs, but I guess that's > the way it is since all the subcomponents are so flexible > > Yep, but all are also settable from a listener or a centralized file, we are > really free here. > > > > > More technically: openwebbeans does not need properties files you can pass > Properties when you create the WebBeansContext, this is what tomee does. Same > for cxf and its bus ;). > > Ok, I'll have a look at that, it's better than properties files (but similar). > > Biggest short term challenge is to align scanners but it is very doable, long > term it is to drop big core jars in all 3 libs for smaller bundles ;). > > Ok. > > Feel free to shout if you need help or more precise pointers. > > Rémy > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Migrate to git
Vote is closed I'm just a lurker, but non-binding +1 from me :) Great to see this! -David > On Feb 21, 2019, at 8:13 AM, Mark Thomas wrote: > > This is a VOTE to migrate the primary source code repository for Apache > Tomcat 9.0.x, 8.5.x and 7.0.x from svn to git. > > The migration will be performed as per: > https://cwiki.apache.org/confluence/display/TOMCAT/Git+migration > > with the following changes: > - 8.0.x will not be migrated > - the tag name format will be changed from "TOMCAT_9_0_5" to "9.0.5" > - the branches will be named master, 8.5.x and 7.0.x > > The proposed date (subject to Infra agreement) for the migration is 26 > Feb 2018. > > The migration process will be: > - Make svn read only for trunk, 8.5.x and 7.0.x > - Turn off the svn->git replication for trunk, 8.5.x and 7.0.x > - Make git://git.apache.org/tomcat.git read/write for me only > - Perform the migration as set out in the wiki with the modifications > described above > - Check the migration > - Make git://git.apache.org/tomcat.git read/write for all committers > (Note: This automatically makes https://github.com/apache/tomcat > read/write as well) > > The critical work is done at this point. The following tasks are more > clean-up and may end up being spread over several days. > > - Confirm there are no open PRs for https://github.com/apache/tomcat85 > and then delete it and git://git.apache.org/tomcat85.git > - Confirm there are no open PRs for https://github.com/apache/tomcat70 > and then delete it and git://git.apache.org/tomcat70.git > - Update the CI systems to pull the source from git > - Create /source.html and replace /svn.html with a redirect to > /source.html > - Update migration guide to pull diffs from gitweb > - Update Tomcat Native to pull in source from git hash > - Fix anything else we have forgotten about. > > If anything goes wrong and we can't fix is easily, the fallback is to > make svn read-write and go back to using svn while we clean up the git > side of things, figure out what went wrong and come up with a better > migration plan. > > [ ] +1 Go ahead with the migration > [ ] -1 Postpone the migration because... > > The vote will be open for at least 72 hours. > > 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: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi folks! Great to see this thread picking up steam. On Jun 10, 2015, at 6:12 AM, Mark Thomas ma...@apache.org wrote: On 10/06/2015 13:34, Fjodor Vershinin wrote: And what about code backward compatibility for Geronimo, should code ported back, or new Geronimo release can use our implementation? Re-use by downstream consumers of Tomcat like TomEE and Geronimo is certainly a goal. The TomEE folks tend to provide feedback when we do something that makes their life difficult so I'd expect them to speak up if they spot a problem. We'll happily be waiting for the code upstream. :) I wouldn't worry about backwards compatibility for Geronimo. That would probably be difficult to achieve. Keep in mind that Geronimo may wish to re-use the code (or just some of the patches) but if you need to change something you should feel free to do so. Agree. I'd focus on making the code as tight and clean as possible. On Jun 10, 2015, at 6:31 AM, Mark Thomas ma...@apache.org wrote: On 10/06/2015 14:04, Arjan Tijms wrote: Tomcat already has some dedicated configuration files for this. My expectation is that all of Tomcat's existing authentication mechanisms would be made available at the container level (BASIC, DIGEST, FORM, CLIENT-CERT, SPNEGO). It should be a small step from there to replacing Tomcat's current authenticators with the appropriate JASPIC config. Is the hope that these existing forms of auth will be ported and plugged in through the JASPIC support? That would be quite excellent if so. -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Possible TomEE release news?
Wonder what people's thoughts are about possibly including TomEE releases in the Tomcat news feed on occasion? Having some mention of TomEE on tomcat.apache.org would be nice -- most users still do not know it exists. However, I've never mentioned it as I personally couldn't think of a good way to do that that didn't feel obtrusive or unnatural. This might be more palatable and less permanent. I remember Rémy did this some many years ago for an OpenEJB release once and it really helped. We have a TomEE 1.7.0 release coming out soon we could try it with. Thoughts? -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Loading drivers from outside server lib/
Hi All! Whipped up a short little patch to allow for JDBC drivers and interceptors to be loaded from the thread context class loader as well as the traditional way using effectively the server/lib/ based classloader. - https://issues.apache.org/bugzilla/show_bug.cgi?id=55444 We were using Commons DBCP which did allow for the driver classloader to be set explicitly. I was tempted to add similar setDriverClassLoader(ClassLoader) and getDriverClassLoader() methods to the PoolConfiguration interface, but it looked like the values there have been intentionally kept to primitive types. Wasn't sure that would be a welcome change. Happy to redo this in whichever way might be best. -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
On Aug 15, 2013, at 1:07 AM, Mark Thomas ma...@apache.org wrote: If you wanted to roll up your sleeves, we'd be more than happy to see it ported or reimplemented in TomEE. or Tomcat :) Even better! -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
On Aug 14, 2013, at 2:25 AM, Arjan Tijms arjan.ti...@gmail.com wrote: markt wrote No-one said it would be difficult. TomEE has already done it. We'd just need to lift the code. Difficulty really doesn't come into it. If there is a demand for it, it will get implemented. If there isn't, it won't. Thanks, that's clear! Btw, didn't you mean Geronimo there, or really TomEE? Last time I checked TomEE didn't have JASPIC implemented yet, but Geronimo of course has. Right, the code David J wrote some time ago is in Geronimo. If you wanted to roll up your sleeves, we'd be more than happy to see it ported or reimplemented in TomEE. It's a Full Profile requirement and there has been user-demand for seeing TomEE+ be full profile compliant. Something we'd never have done in EE 6 with JAX-RPC and other horrific legacy, but much of that is dropped in EE 7 Full Profile. -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 54361] New: Deploy release zip to Maven repository
On Sun, Dec 30, 2012 at 4:13 PM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=54361 Not sure how close I got on the deploy setup. If someone can tell me the build commands I'd have to run prior to this, I'll give it a whirl under a different groupid (something nexus will allow). -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Performance degrade
Was noticing that TomEE had gotten just a tad slower between the 1.0.0 (Tomcat 7.0.27) and the recently released 1.5.0 (Tomcat 7.0.30). I usually include a pure Tomcat binary or two in my performance testing so I have control group. The interesting thing is my control group seems to be my variable :) 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. Anyway, here's the raw data. Format is actual-time - reported-time. Really, just the actual time is significant. That's from process launch to Server startup in XX ms. Reported time is just totaling together the reported initialization and startup times, which is close but misses a few slivers. WAR confluence-4.1.9.war Server apache-tomcat-7.0.10.tar.gz 11552 - 11212 12597 - 12264 11731 - 11410 11960 ms average Server apache-tomcat-7.0.20.tar.gz 11346 - 11027 11382 - 11069 11593 - 11282 11440 ms average Server apache-tomcat-7.0.25.tar.gz 12789 - 12469 11055 - 10739 11336 - 11019 11726 ms average Server apache-tomcat-7.0.26.tar.gz 11350 - 11016 10962 - 10614 10999 - 10669 11103 ms average Server apache-tomcat-7.0.27.tar.gz 12897 - 12569 11642 - 11311 11389 - 11055 11976 ms average Server apache-tomcat-7.0.28.tar.gz 11462 - 11132 11128 - 10804 11288 - 10955 11292 ms average Server apache-tomcat-7.0.29.tar.gz 14976 - 14648 13919 - 13591 14527 - 14198 14474 ms average Server apache-tomcat-7.0.30.tar.gz 14515 - 14185 14383 - 14055 14520 - 14195 14472 ms average Server apache-tomcat-7.0.32.tar.gz 15140 - 14806 14724 - 14398 14663 - 14336 14842 ms average - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Updating the Wiki
I'd like to update this particular question of the wiki to make mention of TomEE. http://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q21 Is it possible to get write access or have someone make that update? -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Updating the Wiki
On Feb 10, 2012, at 1:55 PM, Mark Thomas wrote: On 10/02/2012 21:51, David Blevins wrote: I'd like to update this particular question of the wiki to make mention of TomEE. http://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q21 Is it possible to get write access or have someone make that update? It is an open wiki. The process is simple: 1. Create an account. 2. Make the change. My bad. Created the account but didn't realize I wasn't logged in. Added some text. Feel free to tweak. -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing zips to the maven repo
On Oct 14, 2011, at 12:07 AM, jean-frederic clere wrote: On 10/14/2011 02:01 AM, David Blevins wrote: We've been using plain Tomcat zips for creating TomEE in the OpenEJB maven build for a while now. So far that has been done by publishing the Tomcat zips to a maven repo in svn. Not the best idea to have them in svn, so we're trying to get them in the actual maven repo. It's pretty slick to be able to use the maven dependency plugin to download and unpack the zip so you can run integration tests and things like that. Arquillian does that. Or do like we do and download unpack with the dependency plugin, then add some wars zip up again with the maven assembly plugin. The current plan is to continue using the org.apache.openejb groupId. Do we (Tomcat) want to publish them ourselves in the org.apache.tomcat section of the repo? We already have a bunch of sources/binaries in the maven repo can't you build using it? - In other words what is missing or wrong? - I didn't notice the actual fully assembled Tomcat zip file. Is that there or you referring to the individual jars? The goal is to have this as a maven artifact: http://www.apache.org/dist/tomcat/tomcat-7/v7.0.22/bin/apache-tomcat-7.0.22.zip -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing zips to the maven repo
On Oct 14, 2011, at 6:05 AM, Olivier Lamy wrote: 2011/10/14 Mark Thomas ma...@apache.org: On 14/10/2011 09:15, Konstantin Kolinko wrote: 2011/10/14 David Blevins david.blev...@gmail.com: We've been using plain Tomcat zips for creating TomEE in the OpenEJB maven build for a while now. So far that has been done by publishing the Tomcat zips to a maven repo in svn. Not the best idea to have them in svn, so we're trying to get them in the actual maven repo. Can't maven be taught to download them from proper ASF mirrors? Possible using this plugin http://mojo.codehaus.org/wagon-maven-plugin/download-single-mojo.html That's where we started and eventually evolved into what we have now. The build would download the zip to the target directory of the module that needed it. The downside is every clean build you would have to re-download the zip. The thought then comes into mind, if there was only some place I could keep it and download it once and putting it in the ~/.m2/repository/ directory starts to look really tempting. At that point it became clear that it would be awkwardly recreating the maven download/mirror system. Adding the full .zip archive to any Maven repo just seems wrong to me (and using the ASF svn server for this is definitely a very bad idea) but if the folks managing the main Maven repo are happy with this then I have no objection. The Central Maven repo already contains huge distrib sample http://repo1.maven.org/maven2/org/apache/archiva/archiva-jetty/1.3.5/archiva-jetty-1.3.5-bin.zip which is ~29M. Right. Some more examples (glassfish, jboss, jetty): http://repo1.maven.org/maven2/org/glassfish/distributions/glassfish/3.2-b06/ https://repository.jboss.org/nexus/content/groups/public-jboss/org/jboss/as/jboss-as-dist/7.0.2.Final/ http://repo1.maven.org/maven2/org/mortbay/jetty/jetty-hightide/8.0.3.v20111011/ -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Publishing zips to the maven repo
We've been using plain Tomcat zips for creating TomEE in the OpenEJB maven build for a while now. So far that has been done by publishing the Tomcat zips to a maven repo in svn. Not the best idea to have them in svn, so we're trying to get them in the actual maven repo. It's pretty slick to be able to use the maven dependency plugin to download and unpack the zip so you can run integration tests and things like that. Arquillian does that. Or do like we do and download unpack with the dependency plugin, then add some wars zip up again with the maven assembly plugin. The current plan is to continue using the org.apache.openejb groupId. Do we (Tomcat) want to publish them ourselves in the org.apache.tomcat section of the repo? Not a Tomcat committer obviously, but would be happy to do the setup work so they could go up with the rest of the binaries. Thoughts? -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
ExtensionValidator scope
It doesn't appear ExtensionValidator will look in parent classloaders for extensions (e.g. tomcat.home/lib/). Has this ever been discussed and what would you imagine might be the best way to do it? -David - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 3.0 annotations ?
Cool. Feel free to ping me in freenode if you want; dblevins in
#openejb, #geronimo and #asfinfra.
-David
On Aug 7, 2009, at 9:30 AM, Filip Hanik - Dev Lists wrote:
I'll take a look at this after I'm done with the async stuff
On 08/04/2009 03:28 PM, David Blevins wrote:
On Aug 4, 2009, at 1:22 PM, Costin Manolache wrote:
Thanks - so objectweb instead of BCEL.
I'll try it out - it's a bit different from what I had in mind, it
looks
like xbean-finder first finds all classes and
than reads the files using the class loader ( but not
Class.forName, which
is good ) and keeps track of all annotations.
I was thinking of a simple File/zip based scanning, without any
class loader
- and just select the few
annotations we need and write a web.xml fragment as it goes,
without keeping
anything in memory.
I've been thinking about adding in a sort of filter for the
scanning. Something that could be supplied in the constructor.
Something simple like:
public interface Filter {
boolean accept(String annotationName);
}
Then you would implement that and be guaranteed to only have
metadata for the annotations you cared about. In this case @Filter
and @Servlet. I actually already experimented with it in a little
copy of the ClassFinder, would only take like 10 minutes to
integrate the change in.
In terms of keeping things in memory, there really isn't that much
in memory, especially if you filter out the annotations you don't
care about. As far as needing a classloader, that is only there so
we can return a list of classes (or methods, or fields, etc.) when
you ask for things that have a specific annotation. Someone has to
load the class to get the annotation data so it's just in the API
for convenience.
Another thing I've been experimenting with is some additional byte
code reading optimizations. Basically if you know your annotations
are class-level annotations only, you can get a boost in scan time
by just reading the top of the class def and skipping the rest.
The technique is proven, just need to think of an elegant way to
specify that is the behavior you want.
I guess in 3.0 a deploy tool / phase is absolutely needed - we
can't have
tomcat scan all files
each time it starts up, so the user will have to do something to
re-initiate
the scanning. Like touch
web.xml, or run a re-deploy tool.
I'm curious - why objectweb and not BCEL ?
We (OpenEJB) already had a bunch of code using ASM so that's what I
went with -- I wrote it OpenEJB and moved it over into XBean later
so others could use it. I also know a couple ASM guys and find
it's good getting direct tips for best performance as well as
getting any features in we need.
-David
On Tue, Aug 4, 2009 at 12:50 PM, David Jencks david_jen...@yahoo.com
wrote:
We use xbean-finder for this in geronimo/openejb/etc.
http://repo2.maven.org/maven2/org/apache/xbean/xbean-finder/3.5/
https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder
We also have a servlet 3.0 spec jar I've been trying to keep up
to date
with the glassfish javadocs.
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/specs/geronimo-servlet_3.0_spec/1.0-EA-SNAPSHOT/
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_3.0_spec
thanks
david jencks
On Aug 4, 2009, at 11:11 AM, Costin Manolache wrote:
Hi, anyone working on the @Filter, @Servlet annotation scanner for
tomcat-trunk ?
If I'm understanding it correctly, tomcat will have to read all
files in
classes and lib and look for the
annotation - and I would guess the only reasonable option is
looking at
bytecode.
I checked BCEL - seems reasonably easy, but if anyone has
different code -
I
would rather reuse it in
tomcat-lite :-)
BTW - there is a typo in javax.servlet.ServletRegistration -
should be
Dynamic, not Dynmaic.
I can fix it next time I get some free time...
Costin
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 3.0 annotations ?
FYI, ClassFinder is just one class and you're welcome to just take a
copy. Struts did the same.
-David
On Aug 7, 2009, at 12:55 PM, Costin Manolache wrote:
So far ASM looks good - the size of the jar is amazing. For tomcat-
lite I'll
probably use it instead of bcel - I'll first try directly, if I get
confused
by the callback style I'll use xbean-finder or the tree model.
Costin
On Fri, Aug 7, 2009 at 12:49 PM, David Blevins
david.blev...@visi.comwrote:
Cool. Feel free to ping me in freenode if you want; dblevins in
#openejb,
#geronimo and #asfinfra.
-David
On Aug 7, 2009, at 9:30 AM, Filip Hanik - Dev Lists wrote:
I'll take a look at this after I'm done with the async stuff
On 08/04/2009 03:28 PM, David Blevins wrote:
On Aug 4, 2009, at 1:22 PM, Costin Manolache wrote:
Thanks - so objectweb instead of BCEL.
I'll try it out - it's a bit different from what I had in mind,
it looks
like xbean-finder first finds all classes and
than reads the files using the class loader ( but not
Class.forName,
which
is good ) and keeps track of all annotations.
I was thinking of a simple File/zip based scanning, without any
class
loader
- and just select the few
annotations we need and write a web.xml fragment as it goes,
without
keeping
anything in memory.
I've been thinking about adding in a sort of filter for the
scanning.
Something that could be supplied in the constructor. Something
simple
like:
public interface Filter {
boolean accept(String annotationName);
}
Then you would implement that and be guaranteed to only have
metadata for
the annotations you cared about. In this case @Filter and
@Servlet. I
actually already experimented with it in a little copy of the
ClassFinder,
would only take like 10 minutes to integrate the change in.
In terms of keeping things in memory, there really isn't that
much in
memory, especially if you filter out the annotations you don't
care about.
As far as needing a classloader, that is only there so we can
return a list
of classes (or methods, or fields, etc.) when you ask for things
that have a
specific annotation. Someone has to load the class to get the
annotation
data so it's just in the API for convenience.
Another thing I've been experimenting with is some additional
byte code
reading optimizations. Basically if you know your annotations are
class-level annotations only, you can get a boost in scan time by
just
reading the top of the class def and skipping the rest. The
technique is
proven, just need to think of an elegant way to specify that is
the behavior
you want.
I guess in 3.0 a deploy tool / phase is absolutely needed - we
can't
have
tomcat scan all files
each time it starts up, so the user will have to do something to
re-initiate
the scanning. Like touch
web.xml, or run a re-deploy tool.
I'm curious - why objectweb and not BCEL ?
We (OpenEJB) already had a bunch of code using ASM so that's what
I went
with -- I wrote it OpenEJB and moved it over into XBean later so
others
could use it. I also know a couple ASM guys and find it's good
getting
direct tips for best performance as well as getting any features
in we need.
-David
On Tue, Aug 4, 2009 at 12:50 PM, David Jencks david_jen...@yahoo.com
wrote:
We use xbean-finder for this in geronimo/openejb/etc.
http://repo2.maven.org/maven2/org/apache/xbean/xbean-finder/3.5/
https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-
finder
We also have a servlet 3.0 spec jar I've been trying to keep up
to date
with the glassfish javadocs.
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/specs/geronimo-servlet_3.0_spec/1.0-EA-SNAPSHOT/
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_3.0_spec
thanks
david jencks
On Aug 4, 2009, at 11:11 AM, Costin Manolache wrote:
Hi, anyone working on the @Filter, @Servlet annotation scanner
for
tomcat-trunk ?
If I'm understanding it correctly, tomcat will have to read
all files
in
classes and lib and look for the
annotation - and I would guess the only reasonable option is
looking
at
bytecode.
I checked BCEL - seems reasonably easy, but if anyone has
different
code -
I
would rather reuse it in
tomcat-lite :-)
BTW - there is a typo in javax.servlet.ServletRegistration -
should be
Dynamic, not Dynmaic.
I can fix it next time I get some free time...
Costin
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands
Re: 3.0 annotations ?
No, it scans via ASM for security reasons and only loads classes (with
no initialization) once you ask for classes that have a specific
annotation.
Sample code:
ClassFinder finder = new ClassFinder(webapp.getClassLoader(),
webappLibUrls);
for (Class? servlet : finder.findAnnotatedClasses(Servlet.class)) {
// .. do your processing
}
for (Class? filter : finder.findAnnotatedClasses(Filter.class)) {
// .. do your processing
}
// and so on
Additions are welcome if there are any features you might need.
-David
On Aug 4, 2009, at 1:18 PM, Filip Hanik - Dev Lists wrote:
does it load all the classes?
I think byte code check might make more sense if that is the case
Filip
On 08/04/2009 01:50 PM, David Jencks wrote:
We use xbean-finder for this in geronimo/openejb/etc.
http://repo2.maven.org/maven2/org/apache/xbean/xbean-finder/3.5/
https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder
We also have a servlet 3.0 spec jar I've been trying to keep up to
date with the glassfish javadocs.
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/specs/geronimo-servlet_3.0_spec/1.0-EA-SNAPSHOT/
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_3.0_spec
thanks
david jencks
On Aug 4, 2009, at 11:11 AM, Costin Manolache wrote:
Hi, anyone working on the @Filter, @Servlet annotation scanner for
tomcat-trunk ?
If I'm understanding it correctly, tomcat will have to read all
files in
classes and lib and look for the
annotation - and I would guess the only reasonable option is
looking at
bytecode.
I checked BCEL - seems reasonably easy, but if anyone has
different code - I
would rather reuse it in
tomcat-lite :-)
BTW - there is a typo in javax.servlet.ServletRegistration -
should be
Dynamic, not Dynmaic.
I can fix it next time I get some free time...
Costin
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 3.0 annotations ?
On Aug 4, 2009, at 1:22 PM, Costin Manolache wrote:
Thanks - so objectweb instead of BCEL.
I'll try it out - it's a bit different from what I had in mind, it
looks
like xbean-finder first finds all classes and
than reads the files using the class loader ( but not Class.forName,
which
is good ) and keeps track of all annotations.
I was thinking of a simple File/zip based scanning, without any
class loader
- and just select the few
annotations we need and write a web.xml fragment as it goes, without
keeping
anything in memory.
I've been thinking about adding in a sort of filter for the
scanning. Something that could be supplied in the constructor.
Something simple like:
public interface Filter {
boolean accept(String annotationName);
}
Then you would implement that and be guaranteed to only have metadata
for the annotations you cared about. In this case @Filter and
@Servlet. I actually already experimented with it in a little copy
of the ClassFinder, would only take like 10 minutes to integrate the
change in.
In terms of keeping things in memory, there really isn't that much in
memory, especially if you filter out the annotations you don't care
about. As far as needing a classloader, that is only there so we can
return a list of classes (or methods, or fields, etc.) when you ask
for things that have a specific annotation. Someone has to load the
class to get the annotation data so it's just in the API for
convenience.
Another thing I've been experimenting with is some additional byte
code reading optimizations. Basically if you know your annotations
are class-level annotations only, you can get a boost in scan time by
just reading the top of the class def and skipping the rest. The
technique is proven, just need to think of an elegant way to specify
that is the behavior you want.
I guess in 3.0 a deploy tool / phase is absolutely needed - we can't
have
tomcat scan all files
each time it starts up, so the user will have to do something to re-
initiate
the scanning. Like touch
web.xml, or run a re-deploy tool.
I'm curious - why objectweb and not BCEL ?
We (OpenEJB) already had a bunch of code using ASM so that's what I
went with -- I wrote it OpenEJB and moved it over into XBean later so
others could use it. I also know a couple ASM guys and find it's good
getting direct tips for best performance as well as getting any
features in we need.
-David
On Tue, Aug 4, 2009 at 12:50 PM, David Jencks
david_jen...@yahoo.comwrote:
We use xbean-finder for this in geronimo/openejb/etc.
http://repo2.maven.org/maven2/org/apache/xbean/xbean-finder/3.5/
https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder
We also have a servlet 3.0 spec jar I've been trying to keep up to
date
with the glassfish javadocs.
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/specs/geronimo-servlet_3.0_spec/1.0-EA-SNAPSHOT/
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_3.0_spec
thanks
david jencks
On Aug 4, 2009, at 11:11 AM, Costin Manolache wrote:
Hi, anyone working on the @Filter, @Servlet annotation scanner for
tomcat-trunk ?
If I'm understanding it correctly, tomcat will have to read all
files in
classes and lib and look for the
annotation - and I would guess the only reasonable option is
looking at
bytecode.
I checked BCEL - seems reasonably easy, but if anyone has
different code -
I
would rather reuse it in
tomcat-lite :-)
BTW - there is a typo in javax.servlet.ServletRegistration -
should be
Dynamic, not Dynmaic.
I can fix it next time I get some free time...
Costin
-
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: [PATCH] jasper - enum support for tag libs
On Sep 14, 2007, at 10:34 AM, Filip Hanik - Dev Lists wrote: - adding methods or altering the signature of the javax. APIs is clearly illegal yes, that would not be spec compliant, that's essentially what spec compliant means, that we pass the signature test (which we haven't done for a couple of years, until the Geronimo guy submitted the patches) On that note, is the issue with the annotations-api compliance cleared up. Happy to submit a patch if not. We're running into this in the OpenEJB 3.0 / Tomcat 6 integration and have to add delete this jar, add this one instead, restart to the setup instructions. If it is cleared up, any idea what release it might show up in -- just looking for something to mention in the docs. -- David Blevins - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
On Aug 1, 2007, at 1:30 AM, Rainer Jung wrote: David Blevins wrote: My personal opinion: java.util.logging very much lacks a good formatter. The default 2 line formatting of messages, splitting timestamps and message in separate lines, is not really useful in production. Many ad hoc log analysis practices work on a line oriented basis. Was wondering about that. I've heard people grumble about java.util.logging, but haven't (till now) heard anything specific. Maybe I wasn't paying close enough attention, but the Tomcat 6 log files still seem to follow the one line per message format. How did you pull that off? That's what I get: Aug 1, 2007 10:26:37 AM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-28680 Aug 1, 2007 10:26:37 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 2854 ms Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.13 Aug 1, 2007 10:26:40 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-28680 One line for timestamp, class and method, a second line for log level and message. That's the format of the default formatter, the simple log format. That's why it would be nice if someone took the burden of writing a better log formatter for j.u.l. Got it. Yea, that format is certainly grep unfriendly. Looks like Harmony has a formatter we could copy from and fix to not add the new line. http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/ modules/logging/src/main/java/java/util/logging/SimpleFormatter.java -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Inlining dependencies
Hi Guys, Really curious on what approach you used to inline all your 3rd party deps into org.apache.tomcat.util. Curious if you took them as is, or trimmed them down to just what you need. Were any tools used to help? Any disadvantages that you have noticed other than having to port fixes on those libs in? I've been wanting to do a similar thing in OpenEJB. Any input is appreciated. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inlining dependencies
On Jul 31, 2007, at 11:59 AM, Yoav Shapira wrote: Hey, On 7/31/07, David Blevins [EMAIL PROTECTED] wrote: Really curious on what approach you used to inline all your 3rd party deps into org.apache.tomcat.util. Curious if you took them as is, or trimmed them down to just what you need. Were any tools used to help? Any disadvantages that you have noticed other than having to port fixes on those libs in? IIRC we take a known version of a library and do a string replace on package names, essentially. It's all done in Ant tasks: look for how the Tomcat build handles Jakarta Commons DBCP for example. We don't trim them down AFAIK, nor do we have to do any porting because we re-grab the library (ideally from a known stable version) with every release. That's really cool. Thanks for the info. I'm just very impressed with how clean the result is and there's the obvious benefit of those library versions not conflicting with any apps deployed without the need for fancy classloader scoping. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Juli/Logging
So another topic, There's a thread going on in OpenEJB at the moment about possibly switching away from log4j for the reason that the logging config gets easily messed up in embedded environments (maven, specificaly) and of course to have one less dependency -- the 3.0 server is a bit beefier than the 1.0. I remembered not seeing log4j or commons logging in Tomcat 6 and started investigating -- how I discovered the inlining. Seems juli is a trimmed down version of commons-logging (attractive), but it isn't obvious what's driving the actual logging. Didn't see any inlined log4j classes. Are you using java.util.Logging or something else? Also noticed the javadoc of juli says it allows for per-classloader configuration of logging. What exactly does that mean? Thanks! -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
On Jul 31, 2007, at 2:27 PM, Rainer Jung wrote: Hi David, our default bundled JULI only has a binding for java.util.logging. On http://tomcat.apache.org/tomcat-6.0-doc/extras.html there is a very short description, how one builds a JULI, that is log4j enabled. The static binding was chosen, because commons- logging auto detection provided to many problems w.r.t. redeployment and classloader leaks. Cool, thanks. My personal opinion: java.util.logging very much lacks a good formatter. The default 2 line formatting of messages, splitting timestamps and message in separate lines, is not really useful in production. Many ad hoc log analysis practices work on a line oriented basis. Was wondering about that. I've heard people grumble about java.util.logging, but haven't (till now) heard anything specific. Maybe I wasn't paying close enough attention, but the Tomcat 6 log files still seem to follow the one line per message format. How did you pull that off? -David Regards, Rainer David Blevins wrote: So another topic, There's a thread going on in OpenEJB at the moment about possibly switching away from log4j for the reason that the logging config gets easily messed up in embedded environments (maven, specificaly) and of course to have one less dependency -- the 3.0 server is a bit beefier than the 1.0. I remembered not seeing log4j or commons logging in Tomcat 6 and started investigating -- how I discovered the inlining. Seems juli is a trimmed down version of commons-logging (attractive), but it isn't obvious what's driving the actual logging. Didn't see any inlined log4j classes. Are you using java.util.Logging or something else? Also noticed the javadoc of juli says it allows for per- classloader configuration of logging. What exactly does that mean? Thanks! -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- kippdata informationstechnologie GmbH Tel: 0228 98549 -0 Bornheimer Str. 33aFax: 0228 98549 -50 53111 Bonn www.kippdata.de HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417 Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann === kippdata informationstechnologie GmbH Tel: +49 228 98549 -0 Bornheimer Str. 33aFax: +49 228 98549 -50 D-53111 Bonn www.kippdata.de HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417 Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On Apr 6, 2007, at 5:03 AM, Remy Maucherat wrote: David Jencks wrote: but I won't put it in the org.apache package. There are not too many solutions to this problem, and (unfortunately for you, apparently) I think it's the most appropriate, or least inappropriate if you prefer. Just as a note, I'd be great if people didn't put classes directly in the org.apache namespace. If every java project at Apache did that, we'd have a mess real quick. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On Mar 24, 2007, at 10:42 PM, David Jencks wrote: On Mar 24, 2007, at 6:18 PM, Bill Barker wrote: Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] yo, I've been in touch with the folks at Geronimo. They use dependency injection, and have a suggestion on how they would like the annotation processor to be able to be injected into tomcat Here is the email http://marc.info/?l=geronimo-devm=117467149802844w=2 Here is the proposed patch: https://issues.apache.org/jira/secure/attachment/12354097/ GERONIMO-3010-1.patch A big huge -1 to the patch. It doesn't really provide anything to Tomcat that it isn't doing already. And to the extent that it is doing things differently, it is only adding complexity resulting in doing a much worse job. You might consider the idea of an object creation and destruction service rather than the current state of the patch which was not really intended for presentation as something to be applied as is to tomcat but as a demonstration that tomcat could be made to work with such a service. I figured that the first step was to investigate whether this was practical with minimal code changes in tomcat, and then think about how to further clean up the tomcat code. I've demonstrated to my own satisfaction that the idea can work, but the code could be simplified a lot. In its current state there is essentially no code that isn't already present in tomcat, although it's arranged slightly differently and is considerably more uniform. However, introducing a catalina dependancy into Jasper is a really huge no-no. Jasper is useful, and used without Tomcat. To break this would require a very good reason, which this patch certainly doesn't provide. How does this differ from the current org.apache.AnnotationProcessor? The only difference I can see is that I used the project namespace. I can't say I understand the thinking behind the package for org.apache.AnnotationProcessor. I'd take out the word LifecycleProvider, and replace it with something else as it conflicts with our own idea of Lifecycle. Ya, I don't much like the name either but those postConstruct and preDestroy methods are often called lifecycle methods. I had to call it something. Any better ideas? ManagedObjectFactory? I might suggest something like InstanceManager. IIUC, you'd have these two methods on it: createInstance(..) destroyInstance(..) Assuming I understand the proposal, the default Tomcat implementation would call through to the AnnotationProcessor and all would stay the same in that regard. Above that though, I could easily imagine someone using that interface in Tomcat to provide an implementation that did instance counting for the Tomcat management console and maybe even sending out JMX notifications on create/destroy. I'm not sure I understand the bits about dependencies between Jasper and Catalina. I grok that Jasper is not to be dependent on Catalina, but I wonder if there are any shared libraries between the two that might be a good home for the proposed interface. Are there any shared Tomcat project libs between Jasper and Catalina or does Jasper pretty much only use third-party libs (libs outside the tomcat project itself)? -David I'd like to get your feedback, this is a chance step for our two communities to work together. There's certainly interest on the geronimo side. Many thanks david jencks Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Support for injection-target
I took a look through the tc6.0.x/trunk source and see the support for java.annotation.Resource and related annotations. Didn't see offhand support for the related xml injection-target tag. Is this something you plan to implement or would want? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
