Re: Jakarta/IIS Integration
Hi James, Apache Tomcat has been an Apache top level project for years. It is no longer part of Apache Jakarta. http://tomcat.apache.org/ http://tomcat.apache.org/lists.html#tomcat-users The Tomcat user list is very active with many people who will help you answer this question. Let them know which version of Tomcat, Java, OS, etc. Regards, Dave On Dec 10, 2010, at 11:32 AM, Miner, James wrote: I have been working on this issue for a few days now. Last week, my client needed to refresh their development server and one of the web services applications that they were running did not come over in working order. To reinstall I needed to remove the Tomcat instance, and any references in the registries, uninstall everything and then reinstall. This has caused a few new problems, mainly that, because the application is configured to use IIS as its web server and Tomcat as its Java server, it needs a Jakarta instance to facilitate the Java handling back and forth. I've looked into this solution and cannot seem to find Jakarta (at least not a current version) on the Apache site. I did, however, find that Tomcat Connectors may have the functionality that I am looking for but, when I looked at the configuration guide included with the binary distribution it seemed to be a process more complicated than I, a business process analyst/Remedy developer, am comfortable performing on a client's box. As I said, this is a bit out of my area of expertise and I am looking for suggestions of any nature here. If there is a product that I missed, a step-by-step guide somewhere out there or anything that you believe would be helpful to me at this point, I will be more than happy to hear about it. As it is, I am at a stand-still with my actual work until I can get this issue resolved, so any help will be greatly appreciated. Thank you, James Miner Consultant/Service Support-Column Technologies 130 William Street, 8th Floor, New York, NY 10038 P: (917) 969-8331 E: jmi...@columnit.com - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: Slide lists
Hi - Or point Bugzilla and Gump to gene...@j (even discontinue Gump if the nags are bound to fall on deaf ears). Please do not - this discussion is a lot of traffic for gene...@j. Or, maybe this Apache POI person should finish his migration and unsubscribe? Best Regards, Dave - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
OT - Re: [VOTE] Commons moving to TLP
Sorry. No. Not on this list. (1) Go to http://tomcat.apache.com look for their email list and ask your question on that list. (2) Please learn to be much more polite, as you have been very rude in your earlier replies. (3) Questions belong in a new email message and not in a reply. Thank you very much. Regards, Dave On May 10, 2007, at 7:30 PM, Jean Carlo Salas wrote: did you why Apache Tomcat dosn't run in Vista?? On 5/10/07, Henri Yandell [EMAIL PROTECTED] wrote: On 5/10/07, Ted Husted [EMAIL PROTECTED] wrote: On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote: [ ] +1 I support the proposal [ ] +0 I don't care [x] -1 I'm opposed to the proposal because... I do not feel the draft resolution adequately addresses several remarks made in the discussion thread. I'm in agreement with Niall. I think both of the quotes below are mine, so I'll respond to those. The resolution should address issues raised as to the scope of the PMC and the use of the commons namespace. Comments on the other thread included remarks like * We'll do whatever the community wants to do. If someone proposes a Ruby library and we have a community interested in creating and supporting a Ruby library, then it would of course be strongly considered. Yep, I stand by this one. Look at Jakarta's resolution and what Jakarta does now - it's clear that the community overrules the resolution and I expect it's up to the board to complain if they feel it's gone too far. and * Multiple PMCs, one website. So we'd have Java Commons, Ruby Commons, BobsYourUncle Commons PMCs, and they'd all share a commons.apache.org website. This one was definitely a random suggestion. If we reach a point of impasse with another commons wanting to start, then I (with board hat on) think the solution would be to have multiple PMCs and 1 website. Or maybe that really means a portal and a site behind it. All hypothetical though - XML Commons is dead, DB Commons never happened and WS Commons is afaik not highly active. We do own the Commons space currently. But, as it stands, the resolution implies that the proposed PMC will be excluded to Java and would own both the top-level Commons project name and the commons.apache.org namespace. Neither remark is addressed. Yep. Personally I think that we don't need Java there. For two reasons: 1) It's community and day to day life that determines our scope, more so than a resoltion. 2) It's (let's face it) an easier sell without Java in the text. However the consensus was very clearly in favour of having Java in the resolution. snip Let the focus of this PMC remain on Java, but, in the Apache spirit of openness and collaboration, make way for other Apache Commons projects in other languages. Sure - but let's discuss that then rather than now. Hypotheticals will just keep us spinning emails out ad infinitum. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Enjoy your day!! http://jeank.awardspace.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move POI to TLP
I was thinking he was asking the same thing as you, but after composing an email like yours, I realized Shawn was asking if after going to TLP he would remain as a committer to POI. I am sure that the answer is yes all current POI committers remain POI committers. After going to TLP it will be easier for others to become POI committers because then it will the POI PMC votes that will bring them into the fold. If I am wrong then I hope someone with a better understanding will correct me. Regards, Dave On May 8, 2007, at 3:17 PM, Robert Burrell Donkin wrote: On Mon, 2007-05-07 at 15:36 -0500, Laubach, Shawn Contr 555 ACSS/GFLA1 wrote: So I can vote for this but then I'm not a committer anymore? Just curious. anyone can vote (and please feel free to do so). however only some votes are binding upon apache. in this case, it's Jakarta PMC votes. if POI graduates then only Apache POI PMC votes will be binding. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move POI to TLP
Call me a non-binding +1. Thanks to all for the POI! It is delicious! Thanks to Nick for the leadership! Regards, Dave Fisher On May 4, 2007, at 4:17 AM, Nick Burch wrote: Hi All After lots of discussion within POI, and Jakarta in general, we think POI is ready to graduate to its own TLP. Thanks to the magic of ApacheCon, lots of people have been on-hand to help finalise the proposal for this, which is attached below. So, now is the time to vote on the proposal: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Voting will close in one week. Cheers Nick WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the continued implementation of the library for manipulating files in various business formats currently known as Apache POI for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache POI Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache POI Project be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software and documentation related to the POI library based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, POI be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache POI Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache POI Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the POI PMC: * Nick Burch [EMAIL PROTECTED] * Amol S. Deshmukh [EMAIL PROTECTED] * Jason Height [EMAIL PROTECTED] * Marc Johnson [EMAIL PROTECTED] * Rainer Klute [EMAIL PROTECTED] * Yegor Kozlov [EMAIL PROTECTED] * Danny Muid [EMAIL PROTECTED] * Andrew C. Oliver [EMAIL PROTECTED] * Avik Sengupta [EMAIL PROTECTED] * Glen Stampoultzis [EMAIL PROTECTED] * Sean Sullivan [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Nick Burch be appointed to the office of Vice President, POI, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that all responsibility pertaining to the Apache POI sub-project and encumbered upon the Apache Jakarta PMC are hereafter discharged. - 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: [VOTE] Release Regexp 1.5
Henri, I appreciate what you did to help the POI project stand up and meet Apache requirements. It is an ongoing process - I think the subproject is close to doing it correctly and having a successful release! Cheers! Dave Fisher On Mar 19, 2007, at 10:58 PM, Henri Yandell wrote: On 3/18/07, Henri Yandell [EMAIL PROTECTED] wrote: On 3/14/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Henning Schmiedehausen wrote: You actually have to roll and sign a tarball/zip ball on which the vote happens. Release-then-Vote seems to be the only accepted way by the board these days; Thankfully, neither events in velocity-private nor board feelings apply here. Either Jakarta PMC votes for it or receives an resolution, before that happens, existing procedures [1] stay. There are (to my knowledge) three types of vote/release styles that have been happening at the ASF. 1) A vote to do a release, with no sign of release files. This is how this thread started and it's against ASF policy. 2) A vote on release-candidate files (or -dev in your case), and then a release that is trusted to be a repeat of the process used. This is currently a grey area policy-wise, and is where this release moved to with the ~/vgritsenko/*-dev files. 3) Creating the actual files that are going to be released and voting on them. There's pressure to go this way, but it's not the policy yet. personally I do prefer Vote-then-Release myself but that seems to be the way it is. Release-then-Vote has some nice parts, the actual release is really easy. That's nice if the release process has been painful as it means I don't have to remember how to do the damn thing. Vote-then-Release is nice in that you don't end up doing as many vote builds. Other parts of the ASF seem to do a release where they make a build and if it passes a vote it goes out, if it doesn't then they up the bugfix number and do it again (I don't think anyone actually has a build number, ie: 1.3.5.7). They also have an alpha/beta/GA thing that the version number doesn't show. Very confusing as a user I think. Mostly at this stage the mandate is that we have to be voting on release files, not on Hey, how about a release. This has been a pointless thread. Most of the people on the thread are Members, so if someone could kick it off on members@ then I think you'll see a much more informed discussion going on. This 'how we release' conversation has been bouncing around the ASF for 4 months now, the above is my best grok on the summary. I've not seen anyone yet speaking in favour of a view that we should have a vote on the idea of releasing and then someone does it when they can. Please bring that up on members@ Vadim - good luck. The reason for members existing (imo) is to provide a backbone to an otherwise disparate and completely unrelated huge set of communities. That means showing a bit more empathy and a bit less round and round arguments. Course, I'm grumpy and I've got zero patience for reading mailing list threads over 5 emails nowadays for some reason. Hen - 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: [VOTE] Release Regexp 1.5
I have a thought that may not be an immediate solution. Isn't the correctness of a release from a build point of view a testable condition? Shouldn't this be built in to the build system. The apache servers would not allow an invalid package. They define the pattern. Isn't this GUMP? Not knowing details but seeing emails. Otherwise you are cloaking a software challenge within adminstratium (http://en.wikipedia.org/wiki/Administratium) (Sorry, if I'm a little incoherent, I'm finishing an ironman front to back website release for work with last minute untested boss changes and bug fixes in the fortran - model went from 1 to 5 modes ) Regards, Dave Fisher On Mar 19, 2007, at 9:55 AM, sebb wrote: On 19/03/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? I don't have the references to hand, but I believe it is something to do with providing some form of legal protection. There may be other reasons as well. Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. As far as I know, only one formal vote is actually required by the ASF; this must be by the PMC on the release itself. On 3/19/07, sebb [EMAIL PROTECTED] wrote: snipped The problem here seems to be that it is not possible to use one vote to do both; therefore it seems to me that the sensible thing to do is to have two votes. -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - 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]
Re: [VOTE] Release Regexp 1.5
You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. The problem is that Vote-Then-Release leaves opportunities for the small details to get missed and you end up with a sloppy release. Examples include non-signed distributables, incomplete legal notices, missing or incorrect hashes. The worst is someone slipping in some malicious code in between the time the vote is cast and the release is made. I may be wrong, but the ASF already has agreements with all committers and PMCs. So, anyone slipping in malicious code into a release has already agreed not to do it. Anyone doing so is tagged. This means that any of these mistakes are bugs. And while we want everything to be perfect, not everything is that way. When a PMC votes on a release they should be approving the exact bits that hit the mirrors. That vote binds the ASF to be _legally_ responsible. The only way to have sufficient and appropriate oversight is to give the PMC a chance to check that these final steps of a release have been properly handled. Otherwise the PMC risks releasing a half baked product. So each project requires 3 release managers? The vote to release should appoint a release manager, and the manager should make the release. Their word is their bond. Who wants the reputation as a screw up? If the PMCs delegate it to another person then karma is reflected. It is completely appropriate for the ASF to set guidelines on release procedures. Appropriate as long as they don't treat contributers like children. The ASF should have policies that enable open source, and not discourage it. If someone screws up too many releases then the community can take away their karma. The ASF should automate all those bit manipulations. Didn't someone in this thread say that ant does 99% of it? Regards, Dave Fisher -- jaaron (who is not on the Jakarta PMC) - 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: [VOTE] Release Regexp 1.5
I always prefer to optimize my loops by unrolling them and doing each step differently. Funny to talk about pattern matching in a regexp thread :-D Burnt from my release time to have Yegor chew through some POI bugs ... Regards, Dave On Mar 19, 2007, at 5:41 PM, Andrew C. Oliver wrote: Yeah, well I consider voting on something that doesn't exist yet to be absurd. So there we are. This whole thread is absurd. There is no technical issue here. cvs tag FOOBAR_1_0_RC1 ant scp... ...crickets... cvs TAG FOOBAR_1_0 ssh... mv FOOBAR_1.0-RC1... FOOBAR_1.0-final... -andy -- From Windows/Exchange to Linux/Meldware Buni Meldware Communication Suite Email, Calendaring, ease of configuration/administration http://buni.org - 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: tomcat config
Try Context path=Projects docBase=c:\Projects debug=0/ Make sure that Context .../ is inside of Host name=localhost debug=0 appBase=webapps ... /Host Also, at least this is so for tomcat 4.1.31// Good luck/ Dave On Mar 15, 2007, at 2:19 PM, Richard Dunne wrote: After subscribing to apache mailing list, I tried mailing users@tomcat.apache.org and got a delivery failure message. I have a query re: tomcat configuration. If this is not the correct list, apologies, perhaps someone can point me in the right direction. I have installed tomcat 5 on my machine and got the page which states that if you are seeing this page then your installation of apache tomcat was successful. On that assumption I tried to access a file called index.jsp in a folder called Projects located at c:\ I entered the following line in server.xml: Context path=/ Projects docBase=c:\Projects debug=0/ I typed http://localhost:8080/Projects hoping to see index.jsp, but got a http error instead. Any ideas what may be causing the error? Richard. __ __ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Where should not-yet-commons-ssl go?
Hi Julius - I have a question. Does not-yet-commons-ssl allow me to virtual host multiple domain ssl certificates on a single socket on a Tomcat 4.1.31 server? That would be awesome if it does. Unofficial +1 Regards, Dave Fisher On Feb 23, 2007, at 11:57 AM, Julius Davies wrote: Hi, Jakarta-General, Let's vote on where to put this code! Here's the code right now: http://juliusdavies.ca/commons-ssl/ Forgive my newbieness; I hope these are the right options: [+1] Sub-module in Httpcomponents. [+1] Sandbox. [+1] Full Incubator. [-1] not-yet-commons-ssl is not a good project for Apache because... I'm fine with majority rules, assuming there are no -1 votes. Some background: http://wiki.apache.org/jakarta/JakartaBoardReport-February2007 The code grant for the not yet commons SSL (formerly named commons-ssl), has been completed, so we can progress to having a vote where SSL should end up on general and based on that result take the correct incubator path (legal / full incubation). Let's just get this vote out of the way, and then we can move on to other issues in the appropriate venue (HttpComponents, or Sandbox, or Incubator). My original proposal to jakarta-general about the project is here: http://www.mail-archive.com/general@jakarta.apache.org/msg12790.html Yesterday I released not-yet-commons-ssl-0.3.7. Changes described at the bottom of this email. My intention is for 0.3.7 to be the last release outside of Apache. By the way, there's one undocumented feature of common-ssl that's been quite fun: http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/ OpenSSL.html :-) yours, Julius ps. My vote is: [+0] - Abstaining because I'm too much of a newb to really understand what I'm voting for. On 2/23/07, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Thu, 2007-02-22 at 10:20 -0800, Julius Davies wrote: not-yet-commons-ssl-0.3.7 released! http://juliusdavies.ca/commons-ssl/download.html Hi Julius, What are your plans regarding not-yet-commons-ssl? Is there anything still blocking the incubation process? There are already two Apache projects (HttpComponents and Synapse) that can potentially benefit from collaboration with not-yet-commons-ssl. So, there is a lot of interest in seeing things moving forward. Oleg Features as of not-yet-commons-ssl-0.3.7: 1. useStrongCiphers() used by default. -- --- 40 bit and 56 bit ciphers are now disabled by default. To turn them back on call useDefaultJavaCiphers(). 2. addAllowedName() adds some flexibility to the CN verification. -- --- Here's a code example using cucbc.com to connect, but anticipating www.cucbc.com in the server's certificate: SSLClient client = new SSLClient(); client.addAllowedName( www.cucbc.com ); Socket s = client.createSocket( cucbc.com, 443 ); This technique is also useful if you don't want to use DNS, and want to connect using the IP address. 3. SSLServer can re-use a Tomcat-8443 private key if running from inside Tomcat. -- --- SSLClient server = new SSLServer(); server.useTomcatSSLMaterial(); 4. RMI-SSL support improved. -- --- Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server sockets. Anonymous server-sockets (port 0) will always be set to port 31099. Analyzes the server certificate CN field and tries to set java.rmi.server.hostname to something compatible with that. Probably the only free implementation around that does a good job on the hostname verification! 5. KeyMaterial constructor blows up earlier. -- --- If a JKS or PKCS12 file is provided that isn't going to work (e.g. no private keys), the KeyMaterial constructor throws an exception right away. 6. getSSLContext() now available to help inter-op with Java 5 SSL- NIO libraries. -- --- Oleg has been working hard on SSL-NIO for the Apache httpcomponents library. Go check it out! 7. Fixed bug where SSLClient couldn't be used with javax.net.ssl.HttpsURLConnection on Java 1.4.x -- --- I was wrapping the SSLSocket, but Java 1.4.x guards against that inside HttpsURLConnection and throws this exciting exception: java.lang.RuntimeException: Export restriction: this JSSE implementation is non-pluggable. at com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl.checkCreate (DashoA6275) at sun.net.www.protocol.https.HttpsClient.afterConnect(DashoA6275) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect( DashoA6275) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream
Jakarta Voting
Hi Jakarta Board- A suggestion after reading with interest the recent POI vs. Jakarta smoke and flames threads. I think that Jakarta needs a voting application that can include PMC quorum requirements, direct email vote requests, committer approval, etc. Maybe it already exists? Anyone want to +1 this ;-) Regards, Dave Fisher - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
