Re: Inconsistencies makebase.sh
On Tue, 3 Jul 2018 20:09:44 +0200 Michael Osipov wrote: > Friends, > > I still see some inconsistencies and portability issues: > > 1. Some expressions, some are not. It should be consistently quoted > to avoid whitespace issues or similar. > 2. "cp -a" is not portable. Some platforms don't have it, e.g., HP-UX > which I use for approx 10 years with Tomcat. > 3. Evaluation uses sometimes backticks sometimes $(). Seems > inconsistent. Make sure to shellcheck the script, or any scripts https://www.shellcheck.net/ https://github.com/koalaman/shellcheck -- William L. Thomson Jr. pgplAPv6tca8o.pgp Description: OpenPGP digital signature
Re: Tomcat source layout (was: JDK 11 EA 18)
On Tue, 26 Jun 2018 09:07:32 +0200 Emmanuel Bourg wrote: > Le 26/06/2018 à 05:21, William L. Thomson Jr. a écrit : > > > Because I am crazy :) > > I personally would support a move to a Maven directory layout even if > we stick to Ant as the main build system for now. I think it's good > to use a standard project layout, it looks immediately familiar to > newcomers. That is the idea, just to standardize stuff. Not switch build systems. > That said, I don't really understand why you can't use Ant to build > Tomcat in Gentoo. Ant is rather reasonably easy to bootstrap and we > have no problem using it to build Tomcat from sources in > Debian/Ubuntu. The problem with Ant and Gentoo has nothing to do with Tomcat really. Tomcat has built fine for years via Ant on Gentoo and still does. But it is the Gentoo specific Ant eclass, bash functions library. Plus packaging and dealing with Ant Tasks. That is a bit cumbersome to maintain. All around dealing with Ant is more work. I rather avoid. Presently Gentoo is stuck on <= 1.8 till ant eclass and others are updated, and other things. The ant eclass also requires complicated XML re-writers in python to modify classpath, source/target and now release in build.xml. Which adds more overhead, complexity, and things to maintain. For some things like Netbeans and other projects it failed to re-write all source/targets. I tossed these rather than maintain, to complex, there are better ways. https://github.com/gentoo/gentoo/blob/master/eclass/java-ant-2.eclass https://github.com/gentoo/gentoo/blob/master/eclass/ant-tasks.eclass I am using a more simplistic method of straight javac using a Gentoo bash eclass. That looks for stuff in standard locations. Reason for my request to change Tomcat directory layout. Most the logic is here https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/java-pkg-simple.eclass Plus legacy eclass till I re-write, it is already heavily modified. https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/java-utils-2.eclass My way does not require build.xml modifications, or anything there. I can ensure always source/target/release, as I am doing the compile directly. No worries on classpath pollution, accidentally using shipped jars, or other. Which for ant at times required symlinks to system jars in build system and other cumbersome stuff. Dealing with Ant is a lot of work and things to maintain. For example for tomcat-serlvet-api, always used a stand alone build.xml, separate from one tomcat ships with. Since there is no means to build only those jars easily. Without heavy modifications to default build.xml. Thus creating a standalone build.xml, more to maintain. https://github.com/gentoo/gentoo/tree/master/dev-java/tomcat-servlet-api/files Then to prevent downloads, and other things not needed in the default build.xml. You need to modify build.xml and usually create a patch. Which is also cumbersome to deal with, more to maintain. https://github.com/gentoo/gentoo/tree/master/www-servers/tomcat/files My way requires no patches, guaranteed source/target/release, classpath, etc. All in a more reliable and simple way that requires less effort to maintain over a long term. Across hundreds of packages, maintained by a single person :) -- William L. Thomson Jr. pgpmBIIIwsIWp.pgp Description: OpenPGP digital signature
Re: JDK 11 EA 18
On Mon, 25 Jun 2018 23:21:47 -0400 "William L. Thomson Jr." wrote: > On Mon, 25 Jun 2018 19:40:27 -0400 > Christopher Schultz wrote: > > > I'm confused about what you're asking, here. Do you want Tomcat to > > change its own directory layout? > > Ideally yes, like a directory per jar, with > > src/java/main > src/java/resources Totally messed that up... src/main/java src/main/resources -- William L. Thomson Jr. pgpESPesoUYDT.pgp Description: OpenPGP digital signature
Re: JDK 11 EA 18
On Mon, 25 Jun 2018 19:40:27 -0400 Christopher Schultz wrote: > I'm confused about what you're asking, here. Do you want Tomcat to > change its own directory layout? Ideally yes, like a directory per jar, with src/java/main src/java/resources Jetty is good example or Netbeans https://github.com/eclipse/jetty.project https://github.com/apache/incubator-netbeans > Why? Because I am crazy :) It makes packaging it easier IMHO. Each directory contains what ends up in a given jar. Right now they are all mixed together in java, including resources. Fine if you use the build system. But then its all or nothing. Cannot really build a jar, or just those needed/wanted. Tomcat on Gentoo used to use ant and was a monolithic package short of servlet-api. Which still exists in Gentoo. https://github.com/gentoo/gentoo/blob/master/www-servers/tomcat/tomcat-9.0.7.ebuild https://github.com/gentoo/gentoo/blob/master/dev-java/tomcat-servlet-api/tomcat-servlet-api-9.0.7.ebuild I have split it out to be a package per jar. Its working great, it was just a bit of a pain to find what goes in each jar. If that changes, I will have to match jar contents again. Make sure correct classes are going in the correct jar, and resources. See all the tomcat-* packages here, one per jar https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/dev-java Some are a bit tricky to package I have to remove some files or specify which to include. It is not really ideal. Example of matching jar contents https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/tomcat-jasper/tomcat-jasper-.ebuild#L39 Then I have a meta package, that just pulls in all others to form the actual tomcat installation. Meta package https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/www-servers/tomcat/tomcat-.ebuild The individual packages allow for embedded use and for development etc. Like say using Tomcat in Netbeans. This way Netbeans has access to all Tomcat jars, but does not require a server package to be installed. Even better Netbeans can have its own "Tomcat install", linking in jars into its own local server space with its own config, etc. Before others were doing stuff with the server package. If making an embedded app, you can pull in what jars you need, rather than building all of tomcat and having init scripts and other stuff laying around unused. Just makes it a bit more modular. A different way of shipping Tomcat :) -- William L. Thomson Jr. pgp0e4GA3mO9H.pgp Description: OpenPGP digital signature
Re: JDK 11 EA 18
On Fri, 22 Jun 2018 08:41:20 +0100 Mark Thomas wrote: > > Rather than repeating what has been said many times before, I suggest > you look in the archives for past discussions on source structure. > They are usually part of a discussion about switching to Maven as a > build system. While restructure would be a step in such direction. I am not suggesting switching build systems. It would not matter for my needs, as I would bypass Maven or Gradle just the same as Ant. I took part on one discussion long ago regarding Tomcat and Maven when I officially maintained Tomcat on Gentoo. I can see how its likely come up many times since. Though my objections then have now passed as I am not using any build system. Maven and Gradle are not easily integrated into Gentoo's Portage. Even Ant was a pain and I have tossed out that integration. Though my 2 cents now would be Gradle vs Maven. Seems few if any know about things Maven is built on like Plexus and Modello. Otherwise the build system is moot to me. None the less I would think moving stuff into sub-modules per jar and moving resources into their own directories to help with development and such. Just shows where stuff resides. Though some is shared in like bootstrap I believe. It was just the one difficulty I had in packaging Tomcat on Gentoo my new way using straight javac via bash Gentoo elcasses. Plus the one hiccup as I had to get resources from sources. That was interesting to see Tomcat running missing most resources. I am past that self inflicted issue with resources now. Changing layout is some what moot. Short of when new files are added I must add to specific jars. That may get a bit hairy. Will cross that bridge then. Either way thanks for considering the feedback on project structure! -- William L. Thomson Jr. pgp82Zl1mUF1Y.pgp Description: OpenPGP digital signature
Re: JDK 11 EA 18
Turns out my issues were due to resources ending up in a sub-directory, prefixed with java/org, like find out in sources. One aspect I would like to see done if possible. Tomcat mixes a lot of stuff into the same directories. Its layout and what not started before the normal java conventions now such as; src/main/java src/main/resources It would be great if tomcat could move towards such structure. My problem was due to grabbing resources that are mixed in with sources. Then failing to strip java/ from the path as I copied over the files into the jar. Various properties and xml files. I understand some properties files need be in the same folders but other stuff like xml. But many of those can be merged at build time. Packaging hundreds of Java applications. Very few mix in resources with source files. Thus my logic for handling such cases was off. Self inflicted problem, but would help if project layout was better. Utopian would be moving various pieces into sub-directories for the various jars. I had to be creative to get my jars to be the same as those from upstream. Due to sources all being mixed together. Beyond mixing resources and java sources. -- William L. Thomson Jr. pgpYnuuyN2sMc.pgp Description: OpenPGP digital signature
JDK 11 EA 18
I was also running into this on EA 17, but 18 is current. I had Tomcat and all my stuff, some Jersey and minor Webapps without issues on JDK 11 EA 9 up to like Tomcat 9.0.6, I think also 9.0.7. As of late I am not able to start much. The base Tomcat starts but all webapps fail with "ManagedBean is not found in *", as seen below. I have tried many things to resolve unsuccessfully. I am looking for suggestions. Not sure if this is JDK changes, some missing dependency on bootstrap classpath or within the container, lib directory. Seems to be something in the JDK. It builds fine, and starts. Just no webapps. Thanks in advance for any ideas on how to fix!!! Background I am doing things a bit abnormal. Running Gentoo building from source without ant, tomcat split into many packages, all deps built from source, etc. It all been working fine for sometime even on JDK 11. tomcat-* packages here https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/dev-java Meta package https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/www-servers/tomcat Exception snippets org.apache.catalina.deploy.NamingResourcesImpl.initInternal namingResources.mbeanCreateFail javax.management.MBeanException Caused by: java.lang.Exception: ManagedBean is not found with ContextResource at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:152) ... 12 more org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans Exception creating UserDatabase MBeans for UserDatabase java.lang.IllegalArgumentException: Cannot create UserDatabase MBean for resource UserDatabase Caused by: javax.management.MBeanException at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:308) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:172) ... 15 more Caused by: java.lang.Exception: ManagedBean is not found with MemoryUserDatabase at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:307) ... 16 more org.apache.catalina.deploy.NamingResourcesImpl.initInternal namingResources.mbeanCreateFail javax.management.MBeanException Caused by: java.lang.Exception: ManagedBean is not found with ContextResource at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:152) ... 43 more -- William L. Thomson Jr. pgpiMJPHTXKcH.pgp Description: OpenPGP digital signature
Re: Can't compile Tomcat 6 on Java 5 on OS X
On Thu, 2007-12-06 at 12:22 -0800, mraible wrote: I'm getting the following error when trying to build Tomcat 6 today. compile: [javac] Compiling 1045 source files to /Users/mraible/dev/tomcat6/output/classes [javac] /Users/mraible/dev/tomcat6/java/org/apache/jasper/compiler/JDTCompiler.java:38: package org.eclipse.jdt.core.compiler does not exist [javac] import org.eclipse.jdt.core.compiler.IProblem; [javac] ^ [javac] /Users/mraible/dev/tomcat6/java/org/apache/jasper/compiler/JDTCompiler.java:39: package org.eclipse.jdt.internal.compiler does not exist [javac] import org.eclipse.jdt.internal.compiler.ClassFile; [javac] ^ Looks like your missing ecj, which during build time Tomcat looks for a jdt.jar. On Gentoo we package it as ecj.jar, and I rename the symlink to it on build. Not sure what it is called by default. Actually one of the things I would like to see Tomcat stop doing is rebundling that jar. Since it ends up later on as jasper-jdt.jar. Which I have to double check on, but am pretty sure it's just a renaming. If just renaming I will likely hack around that, and/or patch the build system on Gentoo for that. Since presently it causes that jar to be copied, verses symlinked. So people don't benefit when ecj is updated per bug, or etc. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Bootstrap redirecting stdout/err via system.set
On Wed, 2007-11-28 at 18:28 +0100, jean-frederic clere wrote: William L. Thomson Jr. wrote: But I believe the argument is that applications should do their own stderr/out redirection and not to it external of the app. As in not via bash/shell redirection and sending that to a log file. The app should be doing that internally. That is what daemon is doing. Was that referring to an external daemon, as in jsvc, or the Daemon as part of the class that is called in Bootstrap and responsible for starting Tomcat? Seems odd no one has commented on this so far. Unless it's due to ignorance on my behalf. I am not that familiar with Tomcat source code, or internals on starting and etc. Slowly tracing things down there. So please excuse my lack of knowledge or ignorance there. Now I noticed several classes including Embedded make a System.setErr call. If any of those are invoked as part of Boostrap starting, no clue atm. But seems like if that logic exists in other place. If Boostrap or something it called, invokes doesn't set that. Then it makes a good case that it should be set. Since it's set when Tomcat is started via other means. I have since switched my own apps over to this. It's quite nice and provides me a way to catch what otherwise might have been uncaught exceptions. Via logging them to a file that I have redirected stderr and stdout to. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Bootstrap redirecting stdout/err via system.set
On Wed, 2007-11-28 at 09:29 +0100, jean-frederic clere wrote: William L. Thomson Jr. wrote: Recently on Gentoo I was looking to improve how we start Tomcat. Specifically how we capture stdout/stderr output from Tomcat on start and redirect it to catalina.out. Have to tried to use jsvc from http://commons.apache.org/daemon/ for that? We presently use start-stop-daemon. Which has some --stdout --stderr options coming. It nastily send that stuff to /dev/null, if the --background flag is passed along. We had a long time bug/feature request for jsvc. I considered it, but elected to not go that route. If people want Tomcat on port 80 they can do port forwarding or etc. Which allows Tomcat to remaining running as a non-root user or etc. Nor the need for jsvc to accomplish that. So it's kinda moot. But I believe the argument is that applications should do their own stderr/out redirection and not to it external of the app. As in not via bash/shell redirection and sending that to a log file. The app should be doing that internally. So if I am using start-stop-daemon, or jsvc. It doesn't really change that aspect. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Bootstrap redirecting stdout/err via system.set
On Wed, 2007-11-28 at 09:47 -0500, William L. Thomson Jr. wrote: On Wed, 2007-11-28 at 09:29 +0100, jean-frederic clere wrote: William L. Thomson Jr. wrote: Recently on Gentoo I was looking to improve how we start Tomcat. Specifically how we capture stdout/stderr output from Tomcat on start and redirect it to catalina.out. Have to tried to use jsvc from http://commons.apache.org/daemon/ for that? We presently use start-stop-daemon. Which has some --stdout --stderr options coming. It nastily send that stuff to /dev/null, if the --background flag is passed along. We had a long time bug/feature request for jsvc. I considered it, but elected to not go that route. Forgot link to bug :) http://bugs.gentoo.org/show_bug.cgi?id=75224 -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Bootstrap redirecting stdout/err via system.set
On Wed, 2007-11-28 at 18:28 +0100, jean-frederic clere wrote: William L. Thomson Jr. wrote: But I believe the argument is that applications should do their own stderr/out redirection and not to it external of the app. As in not via bash/shell redirection and sending that to a log file. The app should be doing that internally. That is what daemon is doing. Yes but that's still Tomcat relying on jsvc or in my case start-stop-daemon. Something EXTERNAL to Tomcat. That doesn't effect say Tomcat out of the box when started via catalina.sh. Again, other properties are being set in Bootstrap jar. I am specifically asking if there is reason to not redirect stdout/stderr there via system properties. Which would eliminate needing to do it external of Tomcat be it shell redirection, jsvc, start-stop-daemon or etc. I am NOT looking for suggestions are alternatives like jsvc. I am SPECIFICALLY asking if Tomcat Developers have considered doing the redirection internally in Bootstrap or not. If it's been discussed, the pros and cons. If it hasn't been discussed if it could be, and/or taken under consideration for addition in future versions. After thinking about it myself. I think I will likely take this approach with most of my apps. I can surely made the mods to Bootstrap.java and provide that via a patch on Gentoo. But I don't want to deviate from upstream without at least discussing it first. I am not looking to engage in a discussion of how to do this external to tomcat via jsvc, bash/shell rediction, start-stop-daemon, or other external means. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Bootstrap redirecting stdout/err via system.set
Recently on Gentoo I was looking to improve how we start Tomcat.
Specifically how we capture stdout/stderr output from Tomcat on start
and redirect it to catalina.out. Presently due to our use of
start-stop-daemon and some issues it comes with. We are using the normal
redirection to capture the output. catalina.out 21
In getting feedback to alternatives to our present approach, like that
suggested in comment #5 on the following bug[1]. Another inquired as to
why Tomcat wasn't capturing and redirecting it's own stdout/stderr via
system properties?
Like how .home and .base are set now.
public void setCatalinaHome(String s) {
System.setProperty( catalina.home, s );
}
public void setCatalinaBase(String s) {
System.setProperty( catalina.base, s );
}
Which would alleviate the need to capture and redirect that stuff
externally of Tomcat. Is there a reason this is not currently done? Has
this approach been considered before? Something like
System.setOut(aPrintStream);
System.setErr(aPrintStream);
Where the location would be configurable via a var or etc with a default
specified.
Basically others are suggesting I write a wrapper class or etc to
Bootstrap to set those properties there. I guess we could do that on
Gentoo. But would like to get upstreams input there. Much less I would
likely patch Bootstrap before wrapping it.
http://bugs.gentoo.org/show_bug.cgi?id=162379
--
William L. Thomson Jr.
Gentoo/Java
signature.asc
Description: This is a digitally signed message part
Re: [Fwd: [Security] - **Updated** Important vulnerability disclosed in Apache Tomcat webdav servlet]
On Sun, 2007-10-21 at 14:03 -0400, William L. Thomson Jr. wrote: On Sun, 2007-10-21 at 17:41 +0100, Mark Thomas wrote: William L. Thomson Jr. wrote: I take it down streams should run with the first patches to work around this vulnerability till next release. I already applied the one liner, kinda glad I did not apply the other last night ;) Please advise, thanks. You need a version of the second patch for a complete fix. If you want logging - apply my version, if you don't - apply Remy's. Both fix the problem, just in slightly different ways. We'll have to wait and see which way the voting goes for which patch gets incorporated into the code base. That's what I am interested in, and willing to wait a bit for. Don't want to appear to be taking sides or adding in my own opinion based on which one to apply/go with or not. Prefer to stick with what ever direction upstream goes in and/or recommends. For what it's worth, I am thinking logging might be best. Mostly because to my understanding one must be authorized in webdav or etc to be able to exploit the vulnerability. So it's more of an attack from within, and IMHO it's even more important to log those. It's one thing to be attacked from the outside world, but being attacked from within can be worse. Since in theory they are trusted to a point. Either way I do agree with the other post on being consistent with other projects. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [Fwd: [Security] - **Updated** Important vulnerability disclosed in Apache Tomcat webdav servlet]
On Tue, 2007-10-23 at 00:39 +0100, Mark Thomas wrote: William L. Thomson Jr. wrote: Mostly because to my understanding one must be authorized in webdav or etc to be able to exploit the vulnerability. To be clear, authorisation is not required for this vulnerability. Of course, if you open up write access without authorisation then you are taking on a whole bunch of other risks. Thanks for the clarification. This was misleading http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5461 This one is not as clear, but implies via remote authenticated users http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5461 Could be all are assuming no one in their right educated mind would open write access up to the world. But ya never know :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [Fwd: [Security] - **Updated** Important vulnerability disclosed in Apache Tomcat webdav servlet]
On Sun, 2007-10-21 at 09:09 -0400, Mark Thomas wrote:
Rémy Maucherat wrote:
Since it's an obvious hacking attempt, I chose to use this method
instead:
documentBuilder.setEntityResolver
(new EntityResolver() {
public InputSource resolveEntity(String publicId,
String systemId)
throws SAXException, IOException {
return new InputSource(new StringReader());
}
});
- no logging, replace with blank text (I was using an ISE right before
instead of an input source, but there's no real justification)
I don't think no logging for an obvious hacking attempt is a good idea.
I also think that there is a slim chance of a legitimate use of an
entity and in this case the logging gives the administrator a chance
of working out why something isn't working.
I take it down streams should run with the first patches to work around
this vulnerability till next release. I already applied the one liner,
kinda glad I did not apply the other last night ;) Please advise,
thanks.
--
William L. Thomson Jr.
Gentoo/Java
signature.asc
Description: This is a digitally signed message part
Re: [Fwd: [Security] - **Updated** Important vulnerability disclosed in Apache Tomcat webdav servlet]
On Sun, 2007-10-21 at 17:41 +0100, Mark Thomas wrote: William L. Thomson Jr. wrote: I take it down streams should run with the first patches to work around this vulnerability till next release. I already applied the one liner, kinda glad I did not apply the other last night ;) Please advise, thanks. You need a version of the second patch for a complete fix. If you want logging - apply my version, if you don't - apply Remy's. Both fix the problem, just in slightly different ways. We'll have to wait and see which way the voting goes for which patch gets incorporated into the code base. That's what I am interested in, and willing to wait a bit for. Don't want to appear to be taking sides or adding in my own opinion based on which one to apply/go with or not. Prefer to stick with what ever direction upstream goes in and/or recommends. Thanks much :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Update build.properties.default for new JDT URL
On Sun, 2007-10-07 at 07:14 +0200, Peter Rossbach wrote: Thanks to report it, I hope we can fix it before 6.0.15 tag. FYI, this can likely be done for 5.5.x as well. On Gentoo we are presently shipping/compiling 5.5.25 with 3.3. 6.0.x is still using 3.2, but I will bump that next time I touch package or ebuild. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Inlining dependencies
Jason, On Wed, 2007-08-01 at 14:01 -0400, Jason Corley wrote: It took us quite a while in JPackage to come up with something that did not require the tomcat SRPM to be distributed with three additional projects sources or to heavily patch tomcat itself. Eventually we settled on a custom ant task (written by Matt Wringe) P.S. If anyone is interested in the ant build.xml stubs they are here: Thank you very much for sharing info on how you all were able to come up with a solution. It's very possible I will see about adapting something similar based on what you all are doing. Really want to close the long standing bug, and provide a whole and complete tomcat from source on Gentoo. :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Inlining dependencies
On Tue, 2007-07-31 at 14:59 -0400, Yoav Shapira wrote: It's all done in Ant tasks: look for how the Tomcat build handles Jakarta Commons DBCP for example. I absolutely despise how that is built. It makes building that jar a complete NIGHTMARE. Presently we do not offer than jar on Gentoo and I have no plans to. Or worse potential ways to. Because I will have to hack around our packaging system to even make an attempt. Hard coding versions of a libraries sources within another package, and not as a package dependency. But as additional sources for Tomcat :(. Despite a newer version of those libraries already existing on the system. Which also means they have downloaded a copy of that packages sources, but might not have installed the sources. It is the oldest bug wrt to Tomcat on Gentoo :( http://bugs.gentoo.org/buglist.cgi?quicksearch=tomcat It came up in the past here, where others also disliked the process of how it was built. But so far has fallen on deaf ears. I have not had the time or chance to address the issue and provide you all with a code work around. http://marc.info/?l=tomcat-devm=115808287528288w=2 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. I see there are some slight modifications. Other than the re-branding and re-packaging. Which at the end of the day I really fail to see the benefit to this approach. Verses just shipping collections, pool, and dbcp. Not to mention many drivers have their own factories. But recently as a user discovered. This is not a valid work around for Global resources. As that is hard coded no matter what is configured in server.xml to use tomcat-dbcp.jar. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Removing the examples (JSP/servlet) in TC Binaries
Just FYI, on Gentoo we do not install or provide the examples by default. One must set the examples USE flag for examples to be installed. Because of such they were kinda moot issues for the recent security issues for us on Gentoo. Most running TC in production, or are actually using it for webapps and etc don't really care about the examples. Most times they are in the way IMHO, same goes for root default webapps. Short of displaying a page after someone installs and starts Tomcat so they know it's up and running. Although there are many ways to determine that, requesting a default web page is only one. Seems in more cases than not the examples and default stuff is not used. Examples IMHO surely can be shipped in their own binary release. Still included in source releases. Default webapp is up to you all. We install that by default atm, since people used to complain about getting a blank page from Tomcat. I got tired of saying blank != 404 :) So nothing can be a valid response. Given that the examples have a known security issue. It does not seem logical to ship Tomcat binaries with the examples enabled. Being as how a newb is likely the only one to use them. So they are also being subjected to a vulnerability right off the bat. Despite it being a major/minor vulnerability. Do you all really want newbs exposed off the bat? In that regard, separate bundled, or disabled in binary release would be the ideal ways to go IMHO. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Versioning in sources
On Thu, 2007-05-24 at 13:14 +0200, Filip Hanik - Dev Lists wrote: I'll try to remember to do it for 5.5.x, Great, pretty sure it was always done in the past. At least till 5.5.23 which was left at 5.5.20. Remy will opt out doing it, so you shouldn't depend on it. Ok that's to bad. :( To Remy's defense, its kind of pain in the butt having a version number in SVN that get's tagged anyway, Ok, but that tends to differ from most all other open source app, but to each their own. Usually most FOSS apps releasing tagged sources will have the version reflected in the sources as well. So once the app is built, it's version is reflected within the software. Not just on package sources. To bad this was done in the past but won't be done in the future. FOSS projects should care just as much for source releases as binaries. But that is not always the case :( so you might be better off just keeping the version yourself, right now you're only releasing plain vanilla ASF stuff, Well I would not call it plain. But we prefer to not modify sources as much as possible. I am patching and modifying the build system. Since we don't want to download any deps. Much less compile/package stuff already compiled like servet/jsp api jars and etc. but in the future you could add stuff to the release, or modify it, and hence want to also modify the version number when you build I doubt we will ever modify the version number when we build. Beyond our -rX for that reflects ebuild revision #. I will just ad some sed or etc to the ebuild to take the source version of the tarball and make sure the prop file matches that. :( -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Announcing releases of tomcat native
On Wed, 2007-05-23 at 13:19 +0200, Mladen Turk wrote: For 6.0.13 the required version is 1.1.8 and recommended is 1.1.10 and that is clearly printed whenever Tomcat is started. I'm not sure what more is needed. According to the bug report, it required 1.1.10, and Tomcat failed to start with 1.1.8. http://bugs.gentoo.org/show_bug.cgi?id=179462 -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Announcing releases of tomcat native
On Wed, 2007-05-23 at 15:18 +0200, Rainer Jung wrote: I think he's trying to provide packages for a distro. So he wants to provide 1.1.8, 1.1.9, 1.1.10, ... whenever they are released (available). 100% Correct :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Versioning in sources
I could have swarn this was brought up recently but could not find mention of it in archives. Guess I should file a bug on it, but it's kinda a moot issue. It seems the sources for 6.0.x have not really been versioned. I have noticed it myself on occasion, but never cared enough to comment or etc. A user commented recently, which motivated me to act :) Anyway 6.0.x stuff is all 6.0.0-snapshot. Or something like that. Looking at latest 5.5.23 sources, they are versioned as 5.5.20 :( Now I can totally sed this stuff on compile/install/merge but would be nice if it could be addressed upstream. I am sure others downloading sources would prefer the default to match the version of the sources :) Minor issue, but kinda annoying just the same. Thanks much, and let me know if you would prefer I file a bug. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Versioning in sources
Filip, On Wed, 2007-05-23 at 18:37 +0200, Filip Hanik - Dev Lists wrote: hey William, what are you referring to? any specific .java files that need a version number? Sorry should have been more specific, the problem lies in build.properties.default I was under the impression that we only tag each build, and then there is a small sucker in a property file that we swap out. It's the prop file being neglected :) ie, when you start 5.5.23 then you see May 23, 2007 6:35:55 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.23 Not here, with 6.0.13 I get May 23, 2007 1:15:58 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0-snapshot With 5.5.23, I get May 23, 2007 1:17:01 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5 Not sure what that's about with 5.5.23, since the prop file has 5.5.20, so should reflect that version but does not. 404, and other error pages also reflect the versions as shown in the log file and prop file. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Versioning in sources
On Wed, 2007-05-23 at 19:46 +0200, Filip Hanik - Dev Lists wrote: aah, that makes sense. Remember that the release manager is carrying his/her own build.properties, and if you build from source, you should too. in there you override any properties needed. That is why all binary builds are correct, but your build isn't. Sure, and I can sed this in the build process, but prefer to not modify upstreams stuff as much as possible. what you are asking for is that we update build.properties.default before tagging a release, correct? Yes, please. So that if one downloads versioned sources, and just builds it by invoking ant with all defaults. The resulting build version will match the sources it was built from. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Announcing releases of tomcat native
If possible when new versions of Tomcat native be announced on list? Seems Tomcat 6.0.13 requires 1.1.10. First I became aware of it, was when user reported the problem. Granted I should have discovered it before them when packaging and testing Tomcat 6.0.13 release. Either way would be easier to follow and be aware of if new releases were announced. Like is done for Tomcat and mod_jk. Granted I understand both of those require vote and etc before release. So more of an official release process there. Just not ideal to have to check download area for new releases. Thanks much :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Catalina is burning
On Sat, 2007-05-12 at 14:02 -0700, Bill Barker wrote: Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] http://www.cnn.com/2007/WEATHER/05/11/socal.fire.ap/index.html :( (although there are plenty of Catalinas around, the Catalina name in Tomcat refers to that island) http://news.yahoo.com/s/ap/20070512/ap_on_re_us/wildfires As a followup, it looks like Catalina mostly survived the fire. That's because the fire was in CATALINA_BASE, not CATALINA_HOME :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Candidate binaries for 6.0.11
On Thu, 2007-04-12 at 18:13 +0200, Remy Maucherat wrote: Yoav Shapira wrote: After playing with these candidate binaries for just an hour or so, things look good to me. Yes, they seem fine. Most likely however, I won't propose a vote on them, as I would prefer picking up the NIO fixes with a 6.0.12 tag. I will not request stabilizing of any version of 6.0.x on Gentoo that has the known NIO leak/issues. ( Despite not having any issues myself ) So would prefer to see a 6.0.12 with those fixes as well. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Quality check mod_jk-1.2.22
On Mon, 2007-04-02 at 14:55 +0200, Mladen Turk wrote: Hi all, The next version of mod_jk is approaching its release. A code snapshot is available at: http://people.apache.org/~mturk/jk-1.2.22-dev/ Little version funkiness? http://people.apache.org/~mturk/jk-1.2.22-dev/tomcat-connectors-1.1.22-dev-524775-src.tar.gz 1.1.22 ? Dropping versions huh :) I assume actual release will be 1.2.22. No need to re-package dev snapshot, just wanted to mention it. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Quality check mod_jk-1.2.22
On Mon, 2007-04-02 at 17:55 +0200, Mladen Turk wrote: William L. Thomson Jr. wrote: The next version of mod_jk is approaching its release. A code snapshot is available at: http://people.apache.org/~mturk/jk-1.2.22-dev/ Little version funkiness? 1.1.22 ? LOL, my bad, but you already know what I meant (1.2.22) Yep no worries, I have packaged and added to Gentoo's ~arch as 1.2.22_pre since we don't have a package name to reflect -dev. Should hit mirrors in a few hours. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Tagging TOMCAT_NATIVE_1_1_9
On Thu, 2007-03-29 at 13:22 +0200, Mladen Turk wrote: Hi, I'll tag the tcnative to 1.1.9. It fixes the JVM core in case the acceptor breaks when we are inside the Socket.accept, and adds OpenBSD platform detection. I never got a chance to make patch since I am not to familiar with configure. But would be nice for tcnative, to know during configure that it needs =apr-1.x. If a check can't be added less a patch. I will get with another Gentoo dev, and get a patch made and to you all. Thanks -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: 6.0.11 anyone
On Wed, 2007-03-28 at 07:55 -0600, Filip Hanik - Dev Lists wrote: sorry you had to go on for such a long rant, No worries, just providing info that may or may not be know. no one is asking to bundle or to make dependencies. simply asking that some other packages get built at the same time, Ok, so I must not be clear on the discussion. It seems like the build process of Tomcat was to include some extra jars that would go elsewhere in the binary release of Tomcat. But not something that would be a build time dependency. Is that not the case? Are you just trying to get another Apache project to be released in conjunction with Tomcat? Sorry, just not clear because there were comments about build time dependencies. And it was being brought up as part of another release of Tomcat. So I understood it to be another jar being included with Tomcat that is presently, not, and was in the past. I have gone and re-read the entire thread several times. Like the original comment that brought it all up oh, and can we have the JULI with support for commons-logging built as part of the standard build? Is that talking about the build of Tomcat? or build of another application? Because the follow up talks about keeping deps to a min, and a no nonsense build system for Tomcat. With the response, That doesn't mean that the JAR has to be in the lib directory, all I'm asking is that it is generated during our releases Which I assume to be Tomcat's lib directory. And the jar would go in another directory. I assume the extras.xml is a build file that will be part of Tomcat's build system? So I am mighty confused as to the discussion being about building other packages, that won't be bundled nor a dependency. The dependency part is clear. The won't be bundled, and building other packages is not clear. Will they be a separate bundle or download? Like the old embedded, compat stuff, etc. Sorry if all this is obvious and the plane is just flying over my head ;) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: 6.0.11 anyone
On Wed, 2007-03-28 at 14:51 -0600, Filip Hanik - Dev Lists wrote: man, you sure like to write. Doesn't take long to type ;) The buildscript command: ant -f extras.xml generates two files output\extras\tomcat-juli.jar output\extras\tomcat-juli-adapters.jar All i'm asking is that these two get generated at release time what I'm doing is publishing .jar files to a maven repository for containers that use Tomcat embedded or just want to use independent jars Ok, that makes sense. We are discussing how we can integrate and use maven with our packaging system on Gentoo. Also need to have an embedded version of Tomcat available for like JBoss. So, apache-tomcat-6.0.11.zip will NOT contain these jars. Ok great, I am 100% clear now. Thanks and sorry about all that. Despite us building from source. We try to make the resulting install provide what upstream does. So if those jars were in there, I would need to include them. But they won't so I don't ;) But they were generated during the build, and is available somewhere so that I can run the mavenize script, and push those files to ASF's maven repository. I was not clear on the generation vs packaging. Thanks and sorry for lengths. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: 6.0.11 anyone
On Tue, 2007-03-27 at 23:22 +0200, Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: oh, and can we have the JULI with support for commons-logging built as part of the standard build? if, yes, then I will be happy to do it IMO, no. I'd like to keep a no dependencies, no nonsense build :) Please and thank you. Tomcat 6.0.x build system and reduced dependencies is greatly appreciated, and IMHO a step in the right direction. Not saying not to bundle the stuff, just saying please keep deps to a minimum and no nonsense build ++ =) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: 6.0.11 anyone
On Tue, 2007-03-27 at 17:45 -0600, Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: oh, and can we have the JULI with support for commons-logging built as part of the standard build? if, yes, then I will be happy to do it IMO, no. I'd like to keep a no dependencies, no nonsense build :) I don't see any need to use log4j for Tomcat logging anyway, unless you like running into problems. it's more about being able to publish all our packages consistently. That is understandable. For example, Geronimo, needs to be able to have a unified logging system, and they do, commons logging. And right now, since those packages are not part of an official release, I can't publish that JAR unless I do it manually. I'd like to be able to publish the actual JAR out of the release. IMHO and pretty much the Gentoo Linux Java philosophy is bundled stuff is bad. FOSS Java apps tend to do it more than others. Please consider a slightly different viewpoint. But surely not trying to debate, or etc. Anytime deps are bundled as part of a release, you are locked into that version. If there are bug fixes and other releases. They don't tend to make it into other applications. Take Netbeans for example, current 5.5 version ships with a now outdated version of Tomcat 5.5, I believe 5.5.17, might be 5.5.20. Can't recall exactly. Just to be clear either way, current addition of commons-logging won't make much difference for us on Gentoo. Why? Because we install once instance of a given library, app or etc. We then provide all apps using that library, symbolic links to it said jar file or etc. Providing it's API/ABI etc compliant with other dependencies. If dependencies are fixed on a particular version. We slot it and allow for multiple instances to be installed. In Tomcat sense we install one version of Tomcat that say can be used with either Netbeans or Eclipse, in place of any version being shipped. ( Although not sure if eclipse plugins or etc ship tc, I know they have issues when tc is split via C_HOME/C_BASE as we do on Gentoo ) This allows for easier management. Say in this case, commons-logging has a new release. As it's package and updated it's updated for all applications using that slot. Now one might thing manually fetching a dep to be bad. (On Gentoo it's automated) However that also allows end user to make a choice on version to use. If it's been some time past primary app release, in this case Tomcat. Then it's possible what ever version they ship at the time is newer than the bundled version say in a previous Tomcat release. For a further example take Tomcat's jasper-jdt.jar or should I really call it by it's real name, Eclipse JDT. Or at least some of it. Which I can understand slimming the package down to all that is necessary. But that also means future updates to Eclipse JDT won't make it into Tomcat. On Gentoo, I might end up replacing that file with a symlink. For I am letting the build system do it's thing and repackage what it needs. So again not trying to really change the direction or debate this. Just providing a different view point. I can also understand our solution is quite limited to operating systems that allow for symbolic links. Then again from another point of view, could be more that allow for symbolic links than not ;) But in the end bundled stuff is bad IMHO. If it can be avoided it should be, and manually fetching deps is not a bad thing. Definitely when it's not pertinent to the application. But only a subset that might run on the application and want things available about of convenience. Consistency again I can understand, but does that mean things have to be consistent forever and not subject to change? Anyway, just some food for thought. Sorry for length, and hijacking thread topic a bit. Just felt it was kinda a good time to mention it all, since the discussion was along similar lines. Thanks for your time :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [ANN] Apache Tomcat 5.5.23 released
On Mon, 2007-03-12 at 13:57 -0400, Yoav Shapira wrote: It's a build environment thing. Ya gots to have the JavaMail and JavaActivationFramework jas on your build classpath (in whatever libs directory you chose to use in build.properties), or the JNDI mail session factory won't get built, and thus it won't get bundled in the distro. We should probably add a runtime class check (Ant available classname=.../) to the release Ant target that fails the build if that class isn't present. That way we'll be sure to never have this issue come up again. Those core optional dependencies or etc were/are a pita. Thus we have tons of dependencies I was never sure if they were needed or did anything on Gentoo. Due to lack of time, we have just always included all. Now it's good to find out they do activate/limit functionality within Tomcat. Further justifies their presence, or us including all optional packages during Tomcat build process. In fact we have dropped some like jmx/mx4j if a =1.5 jdk is used since it's present in the jdk. However it seems to have caused some very odd bug in catalina.jar. That only shows up when working with the manager app. I believe it was deploy app via manager app, restart tomcat, and then try to undeploy, to replicate problem. But only when Tomcat is built with =1.5 as bytecode 1.5, and some dropped dependencies. Jars not present at compile time. So seeing how another bug is caused when javamail and etc are not present. Then it might also explain the other bug in catalina.jar. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [ANN] Apache Tomcat 5.5.23 released
Packaged and available in a few hours for sync and emerge on Gentoo. Does this release effective make 5.0.28 obsolete? Or more so than before, since it seemed there were some outstanding issues keeping people from migrating beyond 5.0.28? Curious because I want to remove 5.0.28 from Gentoo entirely. It's been masked for the past couple of months. Which makes it pretty hard for anyone to install it, much less see recommendations to use =5.5.x. Thanks -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Tagging 5.5.24
On Sun, 2007-03-04 at 19:14 -0700, Filip Hanik - Dev Lists wrote: Sorry about the hassle, looks like some printStacktrace statements made their way into 5.5.23, creating an ugly and confusing startup. I will retag 5.5.24, Monday March 5th, 2007 at 12.00pm Mountain time. The build will be done shortly after, I will announce the binaries after I have run the TCK tests on them Please release sources officially ASAP. Seems the 5.5.20 sources are effected by http://www.zerodayinitiative.com/advisories/ZDI-07-008.html -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Tagging 5.5.24
On Mon, 2007-03-05 at 09:55 -0500, William L. Thomson Jr. wrote: On Sun, 2007-03-04 at 19:14 -0700, Filip Hanik - Dev Lists wrote: Sorry about the hassle, looks like some printStacktrace statements made their way into 5.5.23, creating an ugly and confusing startup. I will retag 5.5.24, Monday March 5th, 2007 at 12.00pm Mountain time. The build will be done shortly after, I will announce the binaries after I have run the TCK tests on them Please release sources officially ASAP. Seems the 5.5.20 sources are effected by http://www.zerodayinitiative.com/advisories/ZDI-07-008.html After re-reading I believe it's talking about mod_jk sources shipped in 5.5.20? Is that correct? -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Tagging 5.5.24
On Mon, 2007-03-05 at 16:00 +0100, Remy Maucherat wrote: After re-reading I believe it's talking about mod_jk sources shipped in 5.5.20? Is that correct? Yes. I don't think your users are building mod_jk from these sources. Correct, so we are ok. Just need to get 1.2.21 stabilized and mask the others. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [ANN] Apache Tomcat JK 1.2.21 Web Server Connector released
On Fri, 2007-03-02 at 18:26 +0100, Mladen Turk wrote: Cool. I'll create Windows binaries as soon as the sources gets synced with mirrors. Yeah that slowed me down a bit as well :) Packaged and available on Gentoo in ~arch. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [ANN] Apache Tomcat 6.0.10 released
Great job all, been waiting so long for this, about wet my pants :) But really my way of saying thanks is by making Tomcat 6.0.10 (release) available on Gentoo. Ebuild was just committed to tree, should hit mirrors and be available for sync ~4hrs or so. So long as no major bugs are filed, will be stable on Gentoo in ruffly 30 days. It's been pretty solid so far, so likely any bugs would be Gentoo specific, and likely my fault :) Otherwise thanks again and congrats. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Quality check mod_jk 1.2.21-dev
Packaged and available in a few hours for sync and emerge on Gentoo. Np with compiling or etc. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Quality check mod_jk 1.2.21-dev
On Mon, 2007-02-26 at 13:37 -0600, William A. Rowe, Jr. wrote: Will, this doesn't belong on Gentoo - it's a dev/quality check, no different than any other snapshot. Sure but it's sources of a future release, so I will make them available for anyone to test. Just as I would with alpha, beta, etc. If upstream has no use for this. Then surely I won't mind not doing bumps, etc for dev/qa snapshots or etc. Less work ++ (If you ship snaps on Gentoo, be our guest.) We don't really have a suffix for that. Some of the other stuff residing on p.a.o, I have recently suffixed with _pre. A _dev would be nice, other stuff get's _alpha, _beta, respectively. This one slipped by me, should have done _pre I guess. Not sure if we have anything in particular for snapshots. We can even do cvs/svn ones if we really want/need to follow development that closely. What ever upstream prefers, and of course downstream packager me. :) Now these do not go into stable, they go into ~arch which is experimental or testing. If really bad, they could go into overlay. But I prefer main tree/repository. For ease of use, and greatest exposure. These types of bumps are minor, and I like to test myself in my own envs. So can't hurt to make it available for others to test etc. But if I can ignore them, or etc, just confirm that, and I will do so from now on. Thanks much :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Quality check mod_jk 1.2.21-dev
On Mon, 2007-02-26 at 13:56 -0600, William A. Rowe, Jr. wrote: William L. Thomson Jr. wrote: These types of bumps are minor, and I like to test myself in my own envs. So can't hurt to make it available for others to test etc. +1 on testing that the packages all build in advance of any release, just please don't represent these as releases. Until you see those 3 +1's and an announce, they are not. Sure, I don't call them releases at all. Almost always mention what they are in logs as well, cvs and package changelog. Nor will I request stabilization of anything that is not an official release. No stable alpha's, beta's, etc. Granted this one I should have tagged _pre, or etc, so it might appear as a full release. Most people using ~arch on Gentoo, know they are running unstable where testing and breakage takes place. So it's not uncommon for snapshot/cvs/svn/dev/alpha/beta/etc stuff to go in there. Just ideally package name reflects that. Totally my bad with this one ;) If it's release soon enough will be moot. Otherwise I will go and rename package, and remove other one with incorrect name. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release build 5.5.22
On Thu, 2007-02-22 at 10:14 -0700, Filip Hanik - Dev Lists wrote: Jess Holle wrote: Filip Hanik - Dev Lists wrote: Ok folks, for those that want to see the 5.0.22, please provide some feedback. Without votes, I can't push out a release. [I'm sure you meant 5.5.22, not 5.0.22...] Do votes from non-commiters count in this regard, i.e. in a decisive manner as to whether a release is pushed out? The feedback from non-committers is definitely take into account, as more testing proves better for our releases. so this is something we do encourage I myself haven't run into any issues with it. It's been available on ~arch(unstable) Gentoo to install since the day it was announced. Although I have no way of telling if anyone has installed/emerged 5.5.22 or not. No bugs have been reported ;) I ran it for a bit on my development server, but then switched back to 6.0.10. Not for any reason other than preference. Also might be best on a new thread, but will 5.5.22 ship with ecj 3.1 or 3.2? I have upped the package on Gentoo to use 3.2, since we are trying to get rid of 3.1. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Tomcat 6.0.9 building failed
On Wed, 2007-02-21 at 11:35 -0500, William L. Thomson Jr. wrote: On Wed, 2007-02-21 at 14:55 +0100, Remy Maucherat wrote: Avramenko Andrew wrote: I haven't been able to build Tomcat 6 with JDK 1.6 either. Since building with JDK 1.5 works for me, I didn't try too hard to find out why it fails using 1.6. I've install JDK 1.5. The problem is the same. Can it be related to installed GCJ on this computer or ant which was built with GCJ, I've export right JAVA_HOME, but nevertheless.. ? It works for me. Given the error message, there seems to be a problem with the compiler (you can easily verify the imports exist in the source tree). It also compiles for anyone on Gentoo. We still have 6.0.9_beta in tree. No bugs have been filed about it failing to compile for people on Gentoo. I would assume that's a local issue. Nothing wrong with the sources and ability to compile them. Oh yeah, and I have been compiling it with Sun 1.6 jdk. I am sure others have as well. Sun 1.5 works as well. But we are using -source 1.5 -target 1.5 with both 1.5 and 1.6 jdks. Can't recall off hand if that is set/forced in the build system or not by default. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: New candidate binaries
On Tue, 2007-02-13 at 15:42 +0100, Remy Maucherat wrote: Hi, New candidate binaries are available for testing: http://people.apache.org/~remm/tomcat-6/v6.0.10/ A vote on these binaries will be called on Friday. Bumped packaged for anyone to install/test on Gentoo in ~arch. Just committed it to portage, so will take 4 or more hours before syncing to public mirrors. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: new 5.5 candidate, please test
On Tue, 2007-02-13 at 12:43 -0700, Filip Hanik - Dev Lists wrote: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.22/ Vote on Friday Keeping me on my toes today :) Seems there were some minor changes to build system, and I had to get commons-modeler 2.0 into tree as well. The result, 5.5.22 has been packaged and is available for anyone to install/test on Gentoo in ~arch. Just committed it to portage, so will take 4 or more hours before syncing to public mirrors. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Weekly builds
On Mon, 2007-02-12 at 11:04 -0500, Yoav Shapira wrote: I would caution that for some builds, you won't be able to get enough honest +1s because people won't have time to test in the given weekly window. But I would be glad to be wrong on this one, and we'll cross that bridge if/when we get there. I will try my best to follow and bump the package on Gentoo weekly. That should just reduce it mainly to emerging tomcat, which is a pretty simple processes. Hopefully allowing them to install/deploy/test faster. I've been OK with releasing at least one 6.0 build (6.0.9, and also one of the earlier ones IIRC) as Stable. I think it's ready. I've actually been kind of curious why some of the votes have only called for alpha/beta designation, without giving Stable as an option. I would love to see a stable 6.0.x =) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Weekly builds
On Mon, 2007-02-12 at 17:32 +0100, Henri Gomez wrote: I would love to see a stable 6.0.x =) Tomcat 6.0.9 is stable for my usage. 6.0.x all have been stable for me, but I don't use many advanced features, and no frame works atm. But, I'm not using facelets and others recents goodies, so my concern will be in which area Tomcat 6 is unstable ? We don't have to much enterprise stuff available atm on Gentoo. There is still work being done to get facelets packaged, myfaces, and jsfapi from Sun. We have struts, but that's about it, and not sure many are doing apps with it atm and Tomcat on Gentoo. But I am trying to push as many as I can in the direction of 6.0.x, to hopefully uncover and reveal any bugs or problems. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Building the Jasper compiler
On Mon, 2007-02-12 at 10:21 -0800, M Coffee wrote: Could I ask again for a reference to instructions on how to build the Jasper compiler? The Building.txt that comes with it does not work for me (Win2K, jdk 1.5, ant 1.7.0). It's not going to be on windows, but on Gentoo we will have a tomcat-jasper package. There was a jakarta-tomcat-jasper, that was old based on 5.0.28 sources, and I punted it from the tree since no one was using it. It's purpose was for Jetty, since Jetty uses Tomcat's Jasper. I had to rip out the guts, and make a build.xml specifically for tomcat-servlet-api. I will be doing the same at some point for tomcat-jasper. So if no one else responds with info, check the Gentoo viewcvs/svn for either the tree, or one of our java overlays in a few weeks. Presently I have no motivation to work on the package, but will see about it over the upcoming weeks. Once I do, you can take the build.xml and it should work on windows or etc. Or, would you let me know if it is not possible to build the Jasper compiler except through the Tomcat build? I am sure it's possible, but might be some steps involved. I would recommend looking at the existing build.xml for anything specific to jasper and rip that out and put into it's own build.xml. You will need to make your own compiling target, and omit any stuff that is not necessary to compiling or building jasper. I have been able to compile individual classes in jasper, so that's what I've been doing, and patching the working jar I have. But I'd rather be following an ant build process, just to be sure that all of the environment is being referenced correctly. Their used to be multiple build.xml's. Which on one level was nice for splitting up the package. But on another made some things really a pain. I much prefer the single build.xml to multiple. Is there a mailing list just for Jasper that I should be sending this question to? It's my understanding through past comments on this list that Jasper is an integral port of Tomcat. It was developed for Tomcat, it will change along with Tomcat versions. So this would be the right list and place, unless things have changed ;) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Building the Jasper compiler
On Mon, 2007-02-12 at 13:16 -0800, M Coffee wrote: William, Thanks for responding. No problem. This explains why I couldn't find an independent build process for Jasper. So I'll continue patching the jar, and wait for the development you do on Gentoo. I will try to remember to shoot you a heads up when I do. It will be the build.xml that you want. But really they are not bad to make, feel free to try yourself. If you do any work on the Jasper compiler, Nada, I am downstream, no contributions from me to upstream yet. I hope to in the future, but need the time and possible the skillz ;) please think about addressing the problem of getting reasonably good source code lines numbers (jsp or java would be fine) from a JSP compile error. It worked well in Tomcat 4, but the Jasper compiler in Tomcat 5 does a poor job of it. That's why we haven't switched our development environments to Tomcat 5, My focus these days is on 6.0.x. I hope you are wanting to build a 6.0.x Jasper. As I doubt I will be packaging a 5.5.x jasper, and I believe there was a jasper specific build xml with the 5.5.x branch. It's been a bit since I last dug in sources so can't recall from memory at this time. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Let's get 5.5.21 out the door...
On Fri, 2007-02-02 at 17:09 +0100, Remy Maucherat wrote: Mladen Turk wrote: Anyhow, a thing like Remy is doing for 6.0 would be nice to have. It offers a build before official tag Tagged sources are best here :) Tagged build does nothing for us, since we build from source. So if the builds are a pain, maybe just tagging sources is an option. But IMHO, I am more interested in seeing a 6.0.x release than 5.5.21 :) 5.5.21, could be a eternal beta like 5.0.30 for those sticking to that version. FYI, we have 6.0.7 beta, and 6.0.8 alpha packages available on Gentoo ~arch, unstable. Many are already switching to that, and I encourage it. I have run 6.0.x on my development server since 6.0.2. I will likely use on my production systems once there is an official release, non beta/alpha. Just tossing in my 2 cents. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release build 6.0.9 as alpha
On Thu, 2007-02-01 at 15:35 +0100, Remy Maucherat wrote: Candidate binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.9/ Has been packaged and is available for anyone to install/test on Gentoo in ~arch. Will update the download url, once it's moved. I just committed it to portage, so will take 4 or more hours before syncing to public mirrors. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
libtcnative configure check for apr version
If possible could the configure script for tomcat-native/libtcnative check for apr versions. I wasted quite some time with a libtcnative I compiled against apr 0.x instead of 1.x. Which allowed it to build, but was really tiny and not usable. If the configure checked for apr version 1.x or greater. Would have save much grief. Likely my own fault for not reading or knowing about the apr 1.x dependency. But a check in the configure script would make it idiot proof. :) Thanks -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: 6.0 status
On Thu, 2006-12-21 at 17:19 +0100, Remy Maucherat wrote: Admin: I didn't see anyone yet complain or ask for the admin webapp in 6.0, so I suppose it's really ok to not have it For Tomcat 5.5.20, since the admin webapp is not part of the binary download (don't recall it being in there). We added a use flag to control if the admin app was built/installed. I can't say it's been highly used. I know we did have requests from those not wanting the admin app. Which really was the reason for the admin USE flag. Since by default we were building and installing the admin web app. Users wanted a choice. Me personally I have not used it in years and never did extensively. I found it took more time than just editing the files directly. Could be just personal preference or habit. I just deleted the sucker after install. ;) These days it seems the manager apps get more use than the admin. No complaints here if the admin is no longer available. I will be happy to say to all Gentoo users that upstream does not provide or ship an admin webapp any more, so there is not one for/with 6.0.x. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: 6.0 status
On Thu, 2006-12-21 at 11:29 -0500, Yoav Shapira wrote: Four, we've only had alpha releases, and I assume the uptake on these has been fairly low. Once we label a release as beta or, even more, stable, we'll get a bunch more testers, and then we'll see if/how much complaining there is about the admin webapp. Tomcat 6.0.x ebuilds have been available on Gentoo since 6.0.2, bumped for 6.0.4, and now the current 6.0.6. However I have them masked since they are barely alpha per upstream. Once they hit beta or better I will umask. Although users can unmask themselves now if they so choose to. However from my experience with Gentoo users, only a fraction run unstable or ~arch. But most good system admins keep an eye on ~arch and run at least one development machine as unstable. If that will lead to more feedback, hard to say. I would assume at min, I will hear from some users, and will condense, then relay that info to upstream. Now in my own development env, I have run 6.0.2, 6.0.4, and 6.0.6. While my apps are nothing impressive. They have yet to have any issues, or etc. Painless migration from 5.5.20. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Alternate compilers
Greetings, With regard to compiling Tomcat. I just wanted to get a general feel for how the core Tomcat devs feel about compiling Tomcat with alternative jdks/compilers. Seems there are issues with compiling say Tomcat 5.5.x with ibm jdks, or when using ecj as the compiler. For example http://issues.apache.org/bugzilla/show_bug.cgi?id=39562 https://bugs.gentoo.org/show_bug.cgi?id=157018 Are these issues the Tomcat devs care to resolve? Is Tomcat meant to be compiled with a specific jdk/compiler like Sun's jdk? Is it looked down upon to compile tomcat with other jdks? Will they be supported if there are issues? On Gentoo there is lots of choices. One might argue to much, and causes issues or problems one would not normally run into. More so with Java apps since even the FOSS Java world has gotten used to shipping and distributing binaries. I just want to get a better idea of how upstream, Tomcat devs, feel on this matter. From an outside perspective it seems to have deps on sun jdks at times. Like with regard to Tomcat 6.0.2 seems it does not depend on mx4j/jmx. Since Sun 1.5 jdks provide that, but others don't have a jmx implementation. So we will use mx4j as a dep. But that is not how Tomcat binary will be built, and we will have a deviation there. Thanks -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Initial Feedback on Tomcat 6.0.2 build system
Greetings, Finally getting round to making a Gentoo ebuild for Tomcat 6.0.2. So far so good, much less dependencies, and etc. Much improvements from 5.5.x, all the way around. However I have one suggestion for now, and one problem. My suggestion is, would it be possible to have an if or unless added to targets like target name=build-docs Something like target name=build-docs if=build.javadoc or target name=build-docs unless=nobuild.javadoc Now for my problem. I got most of the way through compile then ran into this. BUILD FAILED /usr/portage/tmp/portage/www-servers/tomcat-6.0.2/work/apache-tomcat-6.0.2-src/build.xml:388: Warning: Could not find file /usr/portage/tmp/portage/www-servers/tomcat-6.0.2/temp/tomcat-native-1.1.7/tomcat-native.tar.gz to copy. I am a bit confused. Now granted we are not running the download targets for a variety of reasons. But the native sources seem to be inside of Tomcat. Why does it need a tar.gz as well as the sources? Shouldn't it build that out of the sources. Or is that being shipped on it's own or etc. Excuse me if I am totally in left field on this. My plan for the native stuff on Gentoo is to have a USE flag, more than likely jni, control if the native connector is built or not. Maybe optional openssl or require that since it seems most of the point to the native accelerator. However I am not getting what the native stuff has to do with building the java parts? Thanks -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
RE: Eclipse WTP and Tomcat 6.0.x ?
Sorry to interrupt, and excuse my ignorance on the matter, I am Netbeaner. However many are trying to use Eclipse with our system installed Tomcat on Gentoo. Tomcat installed via Gentoo ebuild, not a bundled one in Eclipse. The biggest problem people run into is that the Eclipse plugin does not respect CATALINA_BASE and CATALINA_HOME. It expects them to be the same, when it's been a long time design feature that they can be different. Now by default Netbeans assumes they are the same, but does allow one to specify both if they are different. The Tomcat Eclipse plugin or etc seems to lack that ability. So if you are going to be improving the support or working on it for future Tomcat releases. Would it be possible to address the _BASE/_HOME issue at the same time. Thanks and I know this is the wrong list for this. However, since the discussion was taking place, felt it was some what relevant. Thanks -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [VOTE] Releasing Tomcat Connectors 1.2.19
Apache Tomcat Connectors 1.2.19 is: [X] Stable - no major issues, no regressions -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: mod_jk 1.2.19 release candidate: ready to test
Did a quick revision bump of the new 1.2.18 ebuild I made the other day for Gentoo to 1.2.19. It compiled and has been running on my dev x86 box all day long. Haven't done as much webapp development as I should today. But no problems or errors etc. I will try to beat on mod_jk later on. :) Once the sources are on a mirror or etc, I will put the ebuild into portage ~arch (unstable/testing). -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Future of mod_jk jni worker
Your timing is perfect, not. I just added code to the mod_jk ebuild on Gentoo to build and install the JNI stuff, yesterday. :( Although no one requested it, and not sure if anyone ever will use it. Seems there was a name change there recently as well? jni_connect.so is now jk_jnicb.so or so it seems :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Future of mod_jk jni worker
On Sun, 2006-09-17 at 20:08 +0200, Rainer Jung wrote: Hi William, which mod_jk version is this based on? 1.2.18, using JK 1.2.18 Source Release tomcat-connectors-1.2.18-src.tar.gz Where can I have a look at the code? In the svn repository for the mod_jk code. Unless you are referring the code added to the Gentoo ebuild, which is very minimal, just passing stuff onto configure. Then installing the resulting binary http://sources.gentoo.org/viewcvs.py/gentoo-x86/www-apache/mod_jk/mod_jk-1.2.18.ebuild?rev=1.2view=markup -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Future of mod_jk jni worker
On Sun, 2006-09-17 at 21:19 +0200, Peter Rossbach wrote: Have you really test it at unix? No, I just added support for the package to build it. So if someone else wanted to use or test they could and etc. It works only with a full multithreaded one process mpm! JNI means: start tomcat inside an apache process. Good to know, docs and etc on it have been sparse or at least seem to be for quite some time. My last successfull test works with tomcat 5.0.22 and apache 2.0.xx (can't remember, Sorry), windows xp, java 1.4.2.xx. I think nobody really use it or can't switch to really working tcp communication. Drop it! +1 I am not really partial either way. I don't use or care if it goes away. Just the timing is interesting. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Source for Packages org.apache.tomcat.dbcp and below?
On Wed, 2006-09-13 at 15:07 +0200, Remy Maucherat wrote: The resultant package is significantly smaller, and there's no chance of version conflict if the user wants to put a different version of DBCP in the shared folder. Ok that makes sense. Thanks for the info. Any chance of Tomcat making it's own implementation? Even less chance of a version conflict then ;) Although it does not seem like Tomcat uses that jar. So if there was a version conflict, the user could remedy by removing one or the other of the conflicting dbcp jars. Basically the main problem on Gentoo is we don't want to have to pull in sources for 3 other commons apps in conjunction with Tomcat's sources just to build the naming-factory-dbcp.jar. Despite it looking like that's the only way. Otherwise we have to do some craziness just to build that one jar. Which for the end user I am not sure as to the benefit? Other than size or version conflict avoidance. In the mean time we are building Tomcat less that one jar. For those that must use Tomcat's naming factory, we have them fetch the jar from a binary copy of Tomcat. Otherwise they can use commons naming factory. Or since it most always pertains to JDBC usage, the naming factory in their JDBC driver. Are there any performance benefits or etc? What about bugs or etc if a bug is detected in commons-dbcp how does that get addressed in Tomcat? Any major hangups or reasons for Tomcat to not have it's own implementation? Aside from reuse of existing code and etc. Thanks -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Source for Packages org.apache.tomcat.dbcp and below?
On Wed, 2006-09-13 at 15:07 +0200, Remy Maucherat wrote: The resultant package is significantly smaller, Ok, not trying to nit pick this. But if we are talking about commons-dbcp.jar and naming-factory-dbcp.jar. The latter sure does not seem smaller? -rw-r--r-- 1 root root 106216 Jul 23 14:24 /usr/share/commons-dbcp/lib/commons-dbcp.jar -rw-r--r-- 1 wlt users 154109 Apr 14 14:09 Desktop/apache-tomcat-5.5.17/common/lib/naming-factory-dbcp.jar So it's not smaller by any means. Which would make sense since it's not just commons-dbcp being re-packaged. Aspects of commons-collections and commons-pool are included in naming-factory-dbcp.jar. If naming-factory-dbcp.jar could be built or etc with those as binary dependencies it would be fine. That would be more like the rest of Tomcat's build system. It's just that one jar, that has a unique way of being built. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Relation of jasper and servlet API to Tomcat
On Sun, 2006-08-20 at 13:43 -0700, Costin Manolache wrote: If you want to include the real tomcat in gentoo - please use the official label, follow the same procedure as our release, We do include the real Tomcat. Problem is aspects of Tomcat many other apps use. With regard to Jasper I believe it's just Jetty. But servlet-api, a bunch of packages depend on that one. How we version the servlet-api is still up for discussion. Since it's not really based on Tomcat versions. Jasper is another story, and Jasper's package version is likely to stay that of the version of Tomcat it came from. Source wise. and make sure the result of emerge is identical with what the user would get if he would get tomcat from ASF. For the most part were are there, short of one jar, naming-factory-dbcp.jar. However it's possible that Tomcat's on Gentoo could be built with newer versions of dependencies/bundled jars. If you have to patch - and the patch alters the structure or behavior - please don't call the result 'tomcat' :-) We do not modify Tomcat at all. The only patches are to like not download/compile etc jars that are dependencies of Tomcat, or will be bundled. We link those in since they will already exist on the system as a dependency of Tomcat. Beyond that the only thing the patches do is modify/exclude some targets. Since they lack any sort of condition that would allow a command line option for ant to control if those aspects are built. Like examples, docs, etc. We have use flags, if someone does not set examples, docs etc. We do not build/compile that stuff, much less install it. So our patches do not really modify Tomcat at all. Slight modifications to build.xml files only, and to control what get's built when, how, and with what. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: Relation of jasper and servlet API to Tomcat
Tim, Thank you very much for the info. For now at least I will make sure our Jasper package is kept in sync with Tomcat releases. On Sat, 2006-08-19 at 19:36 -0400, Tim Funk wrote: In different versions of Tomcat, Jasper could change a lot since its not a public api. But it's cool for other apps to use it right? It seems Jetty uses Tomcat's Jasper. The servlet api could also change in different Tomcat revisions too. But these changes are usually VERY minor and due to corrections/errata found in the spec. Ok, might just revision bump it as well with Tomcat to be safe, or go monitor the spec changes and etc :) Typically - when Tomcat changes - there was usually a change in Jasper too. So any Tomcat release would require a Jasper release. But there might or might NOT be a servlet api change. Great, that at least gives me some idea of how to maintain those other packages. It seems that Jasper will always be somewhat bound to Tomcat. So no hope of it being packaged or etc on it's own. Hopefully servlet api can, because in 2.4's case it seems to be the only available much less open source implementation. Allot of packages use it. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Relation of jasper and servlet API to Tomcat
Greetings, Over the past 7+ months I have been maintaining Tomcat on Gentoo. I have now become a Gentoo developer so I can officially become the Tomcat maintainer on Gentoo. With that said, I have a couple of things I am curious about. First off, is there any reason Jasper and Servlet-API can't be projects of their own? With their own binary releases. Reason I ask is that it seems other apps use Jasper, not just Tomcat. With regard to servlet-api, it seems to be the only open source implementation. Sun has yet to release 2.4, only 2.3. So the only 2.4 servlet api I can find is the one in Tomcat. On Gentoo we have 3 packages built from the same Tomcat sources. If Tomcat has a revision bump, does that mean Jasper or Servlet API changes as well? If so we have to revision bump 3 packages instead of just Tomcat. Also if I make a patch for servlet-api for Tomcat, the same patch also applies to the servlet API package as well. So multiple copies of the same patch. Much less if someone emerges both servlet api and Tomcat they end up with two copies. Which sorta defeats what we do on Gentoo. Which is to install a resource like log4j, commons stuff etc, once, and symlink it where ever it's needed or used. So you don't end up with different versions and multiple copies of jars and etc all over the place. Ideally it would be great if Jasper and Servlet API were on their own. Different sources and binary releases. Then they could be bundled with releases of Tomcat just as other stuff is bundled. That would make more sense if Tomcat specific things changed among revisions, but did not change Jasper or servlet api stuff. If this has already been discussed, is in the works or etc. I apologize for not seeing it, or being aware of it. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Compiling and buildig naming-factory-dbcp.jar
For the most part the Tomcat compiled from source on Gentoo provides all, and does all the binary one does. With the exception of one jar, naming-factory-dbcp.jar. From looking at the build.xml file it seems that to build that jar, .java files are needed from three other commons packages. Some of those files are modified, and all compiled and put inside naming-factory-dbcp.jar. So basically I have been unable to build that jar due to only having access to Tomcat's sources. Anything Tomcat would download and compile via ant, possibly in jar format, as dependencies, are their own packages on Gentoo. So they are all compiled, prior to Tomcat. They are then linked into locations in Tomcat's sources so compiling will work. At this time it seems I would have to have the package pull in 4 sources, Tomcat, commons-collections, commons-pool, and commons-dbcp. Then unpack the last three inside Tomcat. So ant can find what it needs to build the naming-factory-dbcp.jar. For some reason that all just seems wrong. Why borrow/take the files from other sources and re-bundle them? Why not make Tomcat's own implementation of them? Or at least modify it so that jar could be build via access to .class files, not .java sources. If they were binary dependencies it would not be an issue. But since it's source dependencies, and then compiling and bundling of those sources. There just is not a clean or straight forward way for me to build that jar on Gentoo. I have not had a chance to dig much further than the ant build.xml file for that jar. I know a patch or addressing it is preferred to just a discussion or etc about it. Just for someone else to do the work. However I just wanted to get more info before diving any further. Thanks -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Compiling Tomcat on Gentoo, log4j weirdness
I have as of December started to take over package/ebuild maintenance of Tomcat on Gentoo Linux. From interacting on irc, I get that many don't like us compiling. Such is such, and not looking to debate or discuss that. The issue is this, a few users, 2 so far, with custom apps using log4j are having problems. Specifically java.lang.NoClassDefFoundError: org/apache/log4j/Priority Now we are compiling Tomcat against log4j 1.2.13 instead of 1.2.12, but I doubt that is the problem. Currently at the moment we are still mainly compiling Tomcat with 1.4 jdk, but should be using 1.5 soon. I believe there might be a conflict with JULI or etc? The initial reporter, when we would put log4j in common/lib or shared/lib would crash Tomcat. The other get's the above CNFE. Now I have come across a few things via google where people with the official binary Tomcat, are having similar issues. So I am not sure if this is a result of us compiling Tomcat. Or issues with their custom apps and implementation of log4j. When they can run their apps via the binary just fine, it makes me believe it's something related to us compiling Tomcat. Any input is greatly appreciated. Pretty sure this is more developer related than user, since I am curious as to the inner workings, deps etc of Tomcat's new logging JULI. Still pretty confused with regard to Tomcat's Core Optional Libraries. Of which log4j is one. Not sure if log4j is required or not to make Tomcat whole during compile or what. For now it's all present, and if it can be left out. Might be optional for users at compile time. But I will cross that bridge once I resolve current issues. Thanks -- Sincerely, William L. Thomson Jr. Obsidian-Studios, Inc. http://www.obsidian-studios.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
