Re: Questions about CORBA
Dain Sundstrom пишет: If it comes down to fixing OpenORB or writing our own ORB, I think writing our own will be faster. OpenORB is quite difficult to understand and was written before many modern concepts like IoC were introduced. The biggest problem this the current OpenORB codebase is that it doesn't properly implement IIOP so it cant talk to any other ORBs (and it is difficult to find the code to fix). Can you provide an example? We using OpenORB for our products about 5 years, it properly work with OmniORB at less. Anyway, I say we stick with the sun orb until something better comes along. -dain On Jul 1, 2005, at 12:30 PM, Aaron Mulder wrote: On Fri, 1 Jul 2005, Jacek Laskowski wrote: I thought about it, but I like Alan's idea better to fix OpenORB issues instead of reinventing the wheel. I'd believe it's the fine and straight way to incorporate yet another open source project under Geronimo umbrella or grasp the CORBA concepts patching OpenORB and forking it at some time to create a new project. I'm leaning towards the former rather than the latter. I can't say that I fancy trying to implement an ORB from scratch. I was just trying to put all the options on the table. As for OpenORB, I don't know enough about the state of that project and what would need to be done to make any recommendation myself. Also, I'm not aware of any particular info on the Wiki, but again, I haven't been much involved in CORBA so far. Other than to curse at it, of course. :) It would be great to find a winning path forward. Aaron BTW, is there a wiki page about CORBA stuff? When I asked the question I first had looked at Wiki and couldn't find anything, so either it doesn't exist yet or is not easy to find. All in all, I'm sure we could add a bit more to Wiki now. The thread gives some alternatives to think about. Aaron Jacek
Re: Unified Tomcat/Jetty Plans
Rather than adding code to the builders to accept obsolete schema versions, I would rather provide a standalone tool to update old plans. I don't want to get into the business of supporting non-formally-released obsolete formats forever. Thoughts? thanks david jencks On Jul 3, 2005, at 11:14 PM, David Jencks wrote: On Jul 3, 2005, at 8:17 PM, Aaron Mulder wrote: Jeremy, No need to exaggerate. You can take a friendly tone and still make your point. No one's saying that altering configuration formats is a good thing, just that it will steadily get worse the more stable the server gets. And note that an unstable release is exactly that -- we need a well-documented Milestone 4 release to direct new users to. In the mean time, I'm trying to set up a weekly build environment here, so hopefully I'll put up a fresh unstable release from that tomorrow. Finally, as for the extra mile, I have no idea how to get XMLBeans to accept an XML file that could contain one of two namespaces, but is otherwise identical in content (to handle old Jetty files). Any constructive tips? I think this is fairly easy to do using an xmlcursor. I do a lot of it in SchemaConversionUtils to convert the namespace of the embedded naming and security elements to their actual namespaces. If we add this I think we should print a loud warning that the behavior will not be supported forever. I suppose for Tomcat we could implement a schema converter that would turn the Tomcat-specific elements into container-config elements, but this seems like a lot of work. If we get a lot of feedbcak from confused Tomcat users I'll be happy to look into if further. I would think that the tomcat integration is new enough so we don't have to worry about this. thanks david jencks Aaron P.S. To address Dain's comment, I think he'd agree we need to call a moratorium on config changes once we reach a certain level of pre-1.0 stability -- perhaps RC builds or whatever. On Sun, 3 Jul 2005, Jeremy Boynes wrote: So let me get this right ... * announce to the world we pass the CTS tests and put out an unstable release * just when people are looking at the project, change the deployment plans in an incompatible way * don't provide any upgrade tool, just tell users they need to edit all their existing plans * tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out And this is somehow supposed to encourage people to use this software? Aaron, I appreciate what you are trying to do. Please go the extra mile and make sure existing plans continue to work - it is not hard to do and will avoid putting off a lot of potential users. -- Jeremy Dain Sundstrom wrote: +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: War deployment problem in geronimo 1.0-208875
We are still using the eclipse compiler for jasper under jetty. david jencks On Jul 3, 2005, at 8:07 PM, Dain Sundstrom wrote: Actually we shouldn't require a JDK for JSP pages. It looks like the stack trace is coming from jasper and IIRC we have jasper configured to use eclipse compiler which doesn't need the tools.jar. Maybe the someone accidently removed the eclipse configuration, or my memory is wrong and we never set up our server to use the eclipse compiler. -dain On Jul 3, 2005, at 7:53 PM, Aaron Mulder wrote: OK, so is the answer that for now, we require a JDK and not a JRE? If so, that should get the original poster back on track. Aaron On Sun, 3 Jul 2005, Dain Sundstrom wrote: The tools jar hack will be needed until we delete the OpenORB stub/ tie compiler. I should have this change committed in the next few days, and then we can remove the hack code. -dain On Jul 3, 2005, at 6:20 PM, [EMAIL PROTECTED] wrote: After a quick look.. Geronimo's Daemon class is still calling ToolsJarHack.install(). Jasper2 (the JSP handling component) which is part of Tomcat as of version 5.5.0 bundles the eclipse JDT to allow tomcat to run on a JRE, according to http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ jasper-howto.html The Jetty doco also says Jasper2 is used by Jetty: http:// jetty.mortbay.org/jetty/readme.txt So it appears that the ToolsJarHack isn't needed, but has anyone tested both Tomcat and Jetty without tools.jar? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. Dain Sundstrom [EMAIL PROTECTED] wrote on 04/07/2005 06:50:39 AM: It is supposed to use the eclipse compiler so there should be no searching at all. -dain On Jul 3, 2005, at 12:49 PM, David Blevins wrote: On Sun, Jul 03, 2005 at 01:21:23PM +0200, Oliver Kiessler wrote: hi list, I just installed geronimo 1.0-208875 and deployed a simple webapplication with just a few JSP pages. The deployment via the deployer.jar went fine. But when I accessed the webapplication via the webbrowser I got the following error: HTTP ERROR: 500 Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/ lib/ ext/tools.jar RequestURI=/karma/ Powered by Jetty:// 13:10:19,660 INFO [Container] Started HttpContext[/,/] 13:10:26,860 WARN [/karma] /karma/: org.apache.jasper.JasperException: Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar at org.apache.jasper.compiler.TldLocationsCache.init (TldLocationsCache.java:252) at org.apache.jasper.compiler.TldLocationsCache.getLocation (TldLocationsCache.java:223) at org.apache.jasper.JspCompilationContext.getTldLocation (JspCompilationContext.java:519) [...] My system: Fedora core 4 Kernel 2.6.11-1.1369_FC4 java version 1.4.2_04 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode) Looks like there is an error finding the jar containing the javac compiler required for JSP support. It certainly won't find it in the jre directory. I know we have (or had) some code to deal with this. Anyone else have more info? -David
Re: Publishing unstable builds (i.e. unofficial releases)
On Sun, Jul 03, 2005 at 11:46:24PM -0600, Bruce Snyder wrote: On 7/3/05, Aaron Mulder [EMAIL PROTECTED] wrote: I have a box I can set up to run builds. It's not going to be an ssh host for the outside (e.g. you), but it can do nothing but pump out Geronimo builds. I was going to do the same thing on one of my servers, but I didn't see the value in it if I couldn't expose it to the public. I suppose offering the build artifacts that are produced is what's important. Maybe I should just take that route. Wow, this is great. I have enough scripts to go around! One of you can run the unnofficial release script and the other can run the build/test/spam script. That one doesn't run as cleanly as the unnofficial release script, but I can poke at it some more. Would be awesome to get the build failures and jar publishing going again. -David
Re: Scheduler addition to Geronimo...
Jeff Genender wrote: Hi, I am writing an article for DevWorks on hooking in third party apps into Geronimo. The article is basically about writing a GBean for Quartz. Its written and works pretty good. Then I got to thinking...why not just place the GBean/module into Geronimo, so Geronimo can have a powerful scheduler as part of its offering. Many app servers have a minimal daemon process at best, and I thought having a full scale scheduler as part of the Geronimo offering could be a great addition and will give it an edge. Quartz is developed by OpenSymphony and after reading their license, I do not see any GPL or LGPL attachments. Does anyone know the licensing of it? Anyone have objections or issues to adding it into the distibution? Jeff This is right on time for me, as I was looking for a way to achieve the same thing. JBoss has something similar built-in, so I assume Geronimo should follow, preferably with a better implementation :-) Thanks! Panagiotis
Re: Integration of Geronimo modules (Tx / JCA) in Spring
It'd be good to commit the code to some place (maybe Geronimo SVN?) so we can all share help maintain an easy-to-embed Spring enabled JCA container. I'll gladly help all I can too - though David is da man when it comes to JCA. (I've long wanted us to rename Geronimo's JCA container 'Jencks' in honour of our JCA genius :) On 2 Jul 2005, at 16:52, Thierry Templier wrote: David, No problem to send you the code ;-) I will package it and send it to you at the beginning of the next week. Thanks a lot for your help and your proposal of reviewing our code! Thierry This is great news! I think I will have a bit of time now to help out or at least review what you have done. Can you point me to your code? How can I help? Many thanks, david jencks Take a look at my blog: http://templth.blogspot.com/ __ _ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com James --- http://radio.weblogs.com/0112098/ ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
[jira] Created: (GERONIMO-700) Chaning cmp-field-name to field-name in CMP mapping
Chaning cmp-field-name to field-name in CMP mapping --- Key: GERONIMO-700 URL: http://issues.apache.org/jira/browse/GERONIMO-700 Project: Geronimo Type: Improvement Components: OpenEJB Versions: 1.0-M4 Reporter: Jacek Laskowski openejb-jar.xsd file declares cmp-field-name tag of cmp-field-mapping. It corresponds to field-name tag of the standard dd. As currently the mapping process is done manually it would be much easier if the files could be copied and pasted without tag name changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-700) Renaming cmp-field-name to field-name in CMP mapping
[ http://issues.apache.org/jira/browse/GERONIMO-700?page=all ] Jacek Laskowski updated GERONIMO-700: - Summary: Renaming cmp-field-name to field-name in CMP mapping (was: Chaning cmp-field-name to field-name in CMP mapping) Renaming cmp-field-name to field-name in CMP mapping Key: GERONIMO-700 URL: http://issues.apache.org/jira/browse/GERONIMO-700 Project: Geronimo Type: Improvement Components: OpenEJB Versions: 1.0-M4 Reporter: Jacek Laskowski openejb-jar.xsd file declares cmp-field-name tag of cmp-field-mapping. It corresponds to field-name tag of the standard dd. As currently the mapping process is done manually it would be much easier if the files could be copied and pasted without tag name changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
More TCK kudos
I would also like to chime in and thank those people who worked on the security and interop tests. Jeff Genender from Virtuas jumped right in and cranked out the JACC tests in no-time. Not only did he come in cold and dove into the intricacies of JACC and our implementation, he also was able to tangle with some hairy TCK issues; I am prohibited from going into details but suffice it to say he has some nasty bite marks you know where. Special thanks to Nachi, Jeff's wife, for putting up with her absent husband. Dain Sundstrom from IBM who didn't take technical limitations as a final answer and coded around the obstacles we ran into. We ran into many dead-ends but it was his can do attitude that got us through. Dain was able to dig into the intricacies of IIOP and come up with some great solutions in an incredibly short time. Dain was instrumental in coordinating the interop effort and was able to make sure that resources filled in gaps. Special thanks Marleta for putting up w/ an absent Dain and for, well, pretty much putting up w/ Dain. David Jencks, also from IBM. There is no piece of the Geronimo server that David hasn't had a significant hand in and interop was no exception. We didn't get to see him too much at JavaOne because he was holed up in a hotel room with Dave Blevins, cranking out tests. Not many people know that David took the TCK effort so seriously that he vowed never to cut his hair or shave until all the tests passed. We all eagerly wait to see the new David. ;) Thanks again guys! Regards, Alan
Re: Integration of Geronimo modules (Tx / JCA) in Spring
On Mon, Jul 04, 2005 at 10:11:38AM +0100, James Strachan wrote: It'd be good to commit the code to some place (maybe Geronimo SVN?) so we can all share help maintain an easy-to-embed Spring enabled JCA container. I'll gladly help all I can too - though David is da man when it comes to JCA. (I've long wanted us to rename Geronimo's JCA container 'Jencks' in honour of our JCA genius :) +1 to that :) -- David On 2 Jul 2005, at 16:52, Thierry Templier wrote: David, No problem to send you the code ;-) I will package it and send it to you at the beginning of the next week. Thanks a lot for your help and your proposal of reviewing our code! Thierry This is great news! I think I will have a bit of time now to help out or at least review what you have done. Can you point me to your code? How can I help? Many thanks, david jencks Take a look at my blog: http://templth.blogspot.com/ __ _ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger T?l?chargez cette version sur http://fr.messenger.yahoo.com James --- http://radio.weblogs.com/0112098/ ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: More TCK kudos
On Mon, Jul 04, 2005 at 02:25:32AM -0700, Alan D. Cabrera wrote: I would also like to chime in and thank those people who worked on the security and interop tests. Jeff Genender from Virtuas jumped right in and cranked out the JACC tests in no-time. Not only did he come in cold and dove into the intricacies of JACC and our implementation, he also was able to tangle with some hairy TCK issues; I am prohibited from going into details but suffice it to say he has some nasty bite marks you know where. Special thanks to Nachi, Jeff's wife, for putting up with her absent husband. Dain Sundstrom from IBM who didn't take technical limitations as a final answer and coded around the obstacles we ran into. We ran into many dead-ends but it was his can do attitude that got us through. Dain was able to dig into the intricacies of IIOP and come up with some great solutions in an incredibly short time. Dain was instrumental in coordinating the interop effort and was able to make sure that resources filled in gaps. Special thanks Marleta for putting up w/ an absent Dain and for, well, pretty much putting up w/ Dain. David Jencks, also from IBM. There is no piece of the Geronimo server that David hasn't had a significant hand in and interop was no exception. We didn't get to see him too much at JavaOne because he was holed up in a hotel room with Dave Blevins, cranking out tests. Not many people know that David took the TCK effort so seriously that he vowed never to cut his hair or shave until all the tests passed. We all eagerly wait to see the new David. ;) ROFL! Thanks again guys! + 10 Awesome work guys! -David
Re: Unified Tomcat/Jetty Plans
David Jencks wrote: Rather than adding code to the builders to accept obsolete schema versions, I would rather provide a standalone tool to update old plans. I don't want to get into the business of supporting non-formally-released obsolete formats forever. Thoughts? It's the easiest yet most elegant way I could read so far. I'd recommend that way...until another better one will surface ;) david jencks Jacek
Re: More TCK kudos
+1 Also, I do think that it is worth to notice that these two areas, and interop especially, are very complex. FWIW, I have stopped trying to follow IIOP related commits a long time ago as it was way above my understanding. As an aside, these guys have been/are really fast. Not many people know that ubiquitous David J. complains to have a slow laptop; my point of view is that he is simply faster than his laptop. So, I take my hat off to them; we owe them a lot! Gianny On 4/07/2005 7:25 PM, Alan D. Cabrera wrote: I would also like to chime in and thank those people who worked on the security and interop tests. Jeff Genender from Virtuas jumped right in and cranked out the JACC tests in no-time. Not only did he come in cold and dove into the intricacies of JACC and our implementation, he also was able to tangle with some hairy TCK issues; I am prohibited from going into details but suffice it to say he has some nasty bite marks you know where. Special thanks to Nachi, Jeff's wife, for putting up with her absent husband. Dain Sundstrom from IBM who didn't take technical limitations as a final answer and coded around the obstacles we ran into. We ran into many dead-ends but it was his can do attitude that got us through. Dain was able to dig into the intricacies of IIOP and come up with some great solutions in an incredibly short time. Dain was instrumental in coordinating the interop effort and was able to make sure that resources filled in gaps. Special thanks Marleta for putting up w/ an absent Dain and for, well, pretty much putting up w/ Dain. David Jencks, also from IBM. There is no piece of the Geronimo server that David hasn't had a significant hand in and interop was no exception. We didn't get to see him too much at JavaOne because he was holed up in a hotel room with Dave Blevins, cranking out tests. Not many people know that David took the TCK effort so seriously that he vowed never to cut his hair or shave until all the tests passed. We all eagerly wait to see the new David. ;) Thanks again guys! Regards, Alan
Re: Donation of a CORBA Orb
+1 Awesome! that's sounds excellent. On 7/4/05, Joern Larsen [EMAIL PROTECTED] wrote: Dear Devlist Trifork has been a J2EE Licensee since 2000 and we have a clean room implementation of the J2EE v 1.4 spec. and the product is called Trifork T4. This includes a full CORBA 2.3 implementation with CSIv2, transaction integration, etc. We would like to donate our CORBA ORB implementation as foundation for a new CORBA effort as part of the Geronimo project. We would like to get in touch with the people relevant to this. Best regards Joern -- -- -- Joern Larsen CEO WHO'S AT JAOO? - http://www.jaoo.dk --- EOS Trifork, Margrethepladsen 3, 8000 Århus C, Denmark Tel: +45 8732 8787 / Fax: +45 8732 8788 / Mob: +45 4072 8483 -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Scheduler addition to Geronimo...
I think the license is fine. It's Apache License 1.1 On Jul 3, 2005, at 11:33 PM, Jeff Genender wrote: Hi, I am writing an article for DevWorks on hooking in third party apps into Geronimo. The article is basically about writing a GBean for Quartz. Its written and works pretty good. Then I got to thinking...why not just place the GBean/module into Geronimo, so Geronimo can have a powerful scheduler as part of its offering. Many app servers have a minimal daemon process at best, and I thought having a full scale scheduler as part of the Geronimo offering could be a great addition and will give it an edge. Quartz is developed by OpenSymphony and after reading their license, I do not see any GPL or LGPL attachments. Does anyone know the licensing of it? Anyone have objections or issues to adding it into the distibution? Jeff -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Scheduler addition to Geronimo...
On Jul 4, 2005, at 12:51 AM, Jeremy Boynes wrote: Jeff Genender wrote: Hi, I am writing an article for DevWorks on hooking in third party apps into Geronimo. The article is basically about writing a GBean for Quartz. Its written and works pretty good. Then I got to thinking...why not just place the GBean/module into Geronimo, so Geronimo can have a powerful scheduler as part of its offering. Many app servers have a minimal daemon process at best, and I thought having a full scale scheduler as part of the Geronimo offering could be a great addition and will give it an edge. Quartz is developed by OpenSymphony and after reading their license, I do not see any GPL or LGPL attachments. Does anyone know the licensing of it? Anyone have objections or issues to adding it into the distibution? I've been thinking of this one for a while, so no, I'm happy someone else picked it up. Apart from licensing, from a technical note I would like to see how this would integrate with a central Work manager so that scheduled activities could be co-ordinated with other Work. Right, for example there's interest in doing JSR-237, the Work Manager API. I've told the spec leads that we'd be interested (so Apache would participate in the JSR) and there has been recent work started here geir -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Startup Scripts discussion ( GERONIMO-693 )
To get the ball rolling on startup scripts http://issues.apache.org/jira/browse/GERONIMO-693 , what do people think about basing the startup scripts (as much as possible) on tomcat's catalina.bat catalina.sh http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/bin/ (since they have been used for years and many users would be familiar with their style of configuration)? Here is my initial list of requirements for startup scripts for discussion. If anyone else has some requirements to add (please indicate priority.. e.g. mandatory or nice to have)? I will consolidate comments into a proposal (e.g. documenting command syntax). Server Startup: * script must specify -Djava.endorsed.dirs=lib/endorsed to ensure Tomcat works * allow plan names to be specified for advanced users. * start under JPDA debugger if 1st argument is jpda instead of start (optional JPDA_TRANSPORT JPDA_ADDRESS environment variables) * start under security manager (causes -Djava.security.manager and -Djava.security.policy==xx to be passed to the JVM) How should a policy file be specified? * specify directory for temporary files (e.g. GERONIMO_TMPDIR environment variable) * allow jvm options to be passed (e.g. JAVA_OPTS environment variable) * (for discussion) should the one server startup script also be used for starting Geronimo as a service? I don't plan to implement this initially, but would like to plan how we would do it. Currently Tomcat can be started as a service, but they don't use a script to start it as a service. See http://jakarta.apache.org/tomcat/tomcat-5.5-doc/setup.html . Does anyone know if there is a JIRA issue for starting Geronimo as a service? I can't find one. * (for discussion) Can we introduce some type of startup mode parameter that removes the need for people to remember to start the org/apache/geronimo/RuntimeDeployer configId). Could having such a parameter make manuals/books easier to write? I see a few possible modes of startup (please comment if you can think of others): - start with previous configuration (no configIds specified as arguments on Java command). This would be the default mode. - start with a specific list of configIds. Only these configIds will be started. - start with a minimal configuration for J2EE (this includes the org/apache/geronimo/RuntimeDeployer configuration). - (future) start with a minimal configuration for non-J2EE use. There was a discussion on the dev list - (future) start with a rolled back configuration? Server Shutdown == More thought needed here. Any comments? Deploy Tool Startup: = * starting under JPDA debugger * allow jvm options to be passed Currently the deploy tool accepts some parameters with two leading minus characters (e.g. --user system). The Tomcat startup scripts currently have parameters that have a single leading minus character (e.g. -security). Should the startup script parameters be using the same prefix (two leading minus characters) as the Java code or should it be using a different prefix? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
Re: Publishing unstable builds (i.e. unofficial releases)
On Jul 4, 2005, at 12:58 AM, Bruce Snyder wrote: On 7/2/05, David Blevins [EMAIL PROTECTED] wrote: So I created this script quite a while ago and just want to let the committers know how to run it. Have we found a server where this can be run successfully? I tried this on minotaur a while back and couldn't get past the port conflicts and had to give up because I was not aware of any other servers. Can we just shift the ports via some kind of cmd line or config? That way we can run periodically on minotaur and drop out nightlies automatically... geir While in San Francisco last week, Winston mentioned a four way Itanium server that was donated by Simula and Intel. Is this server available for only the Codehaus? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Unified Tomcat/Jetty Plans
On Jul 4, 2005, at 1:34 AM, Aaron Mulder wrote: As far as design work goes, we've historically not had the position of review-then-commit. I think we're trying to increase the amount of discussion and planning on the list, but I'm not prepared to go to a review-then-commit strategy. Are you? Short of that, yes, let's talk on the list as we have been, but we also need to be prepared to make adjustments to code that's committed as issues are identified. No, I don't think we're near review-then-commit at this time as I don't see the necessity to slow things down like that. That said, Jeremy has a point - in general if something will affect all users, we should get into the habit of bringing up for discussion first. Yeah, we're still early and yeah, things are changing, but there's a good balance we can find. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
RE: Unified Tomcat/Jetty Plans
Hi, Can you please take me off from the mailing list. Thanks, Rahul Jain -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: 04 July 2005 17:59 To: dev@geronimo.apache.org Subject: Re: Unified Tomcat/Jetty Plans On Jul 4, 2005, at 1:34 AM, Aaron Mulder wrote: As far as design work goes, we've historically not had the position of review-then-commit. I think we're trying to increase the amount of discussion and planning on the list, but I'm not prepared to go to a review-then-commit strategy. Are you? Short of that, yes, let's talk on the list as we have been, but we also need to be prepared to make adjustments to code that's committed as issues are identified. No, I don't think we're near review-then-commit at this time as I don't see the necessity to slow things down like that. That said, Jeremy has a point - in general if something will affect all users, we should get into the habit of bringing up for discussion first. Yeah, we're still early and yeah, things are changing, but there's a good balance we can find. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Integration of Geronimo modules (Tx / JCA) in Spring
On Jul 4, 2005, at 5:11 AM, James Strachan wrote: It'd be good to commit the code to some place (maybe Geronimo SVN?) so we can all share help maintain an easy-to-embed Spring enabled JCA container. I'll gladly help all I can too - though David is da man when it comes to JCA. (I've long wanted us to rename Geronimo's JCA container 'Jencks' in honour of our JCA genius :) What do you think the J in JCA stands for ? geir On 2 Jul 2005, at 16:52, Thierry Templier wrote: David, No problem to send you the code ;-) I will package it and send it to you at the beginning of the next week. Thanks a lot for your help and your proposal of reviewing our code! Thierry This is great news! I think I will have a bit of time now to help out or at least review what you have done. Can you point me to your code? How can I help? Many thanks, david jencks Take a look at my blog: http://templth.blogspot.com/ _ __ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com James --- http://radio.weblogs.com/0112098/ ___Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: GBeanInstance should already be stopped before die() is called ERRORs during build
Jacek, I still get the error, now only shown twice in build output in svn ver 209054 . I don't get the classnotfoundexception that GERONIMO-673 had. 20:39:37,703 INFO [TSSBean] org/openejb/POA - Unlinked container openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=n ull,J2EEServer=openejb,j2eeType=StatelessSessionBean,name=BasicStatelessBean 20:39:37,703 INFO [GenericEJBContainer] GenericEJBContainer 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null, J2EEServer=openejb,j2eeType=StatelessSessionBean,name=BasicStatelessBean' stopped 20:39:37,703 INFO [GenericEJBContainer] GenericEJBContainer 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null, J2EEServer=openejb,j2eeType=EntityBean,name=BasicCmp2Bean' stopped 20:39:37,703 INFO [GenericEJBContainer] GenericEJBContainer 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null, J2EEServer=openejb,j2eeType=EntityBean,name=BasicCmpBean' stopped 20:39:37,703 INFO [GenericEJBContainer] GenericEJBContainer 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null, J2EEServer=openejb,j2eeType=StatefulSessionBean,name=BasicStatefulBean' stopped 20:39:37,703 INFO [Configuration] Stopping configuration org/openejb/scenario001 20:39:38,156 ERROR [GBeanInstance] GBeanInstance should already be stopped before die() is called: objectName=geronimo.server:role=C MPPKGenerator,name=SecurityEntity state=starting 20:39:38,156 ERROR [GBeanInstance] GBeanInstance should already be stopped before die() is called: objectName=geronimo.server:role=C MPPKGenerator,name=SecurityEntity,isWrapper=true state=starting Completed John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. Jacek Laskowski [EMAIL PROTECTED] wrote on 03/07/2005 04:33:45 AM: [EMAIL PROTECTED] wrote: I don't remember seeing this error before. It's http://issues.apache.org/jira/browse/GERONIMO-673. See one of the last log line in the issue. John Jacek
Re: Donation of a CORBA Orb
On Jul 4, 2005, at 5:07 AM, Joern Larsen wrote: Dear Devlist Trifork has been a J2EE Licensee since 2000 and we have a clean room implementation of the J2EE v 1.4 spec. and the product is called Trifork T4. This includes a full CORBA 2.3 implementation with CSIv2, transaction integration, etc. We would like to donate our CORBA ORB implementation as foundation for a new CORBA effort as part of the Geronimo project. We would like to get in touch with the people relevant to this. Joern, Thanks for the note. This is the right place to discuss. There are two separate threads of discussion that I can think of : 1) Technical - if the donation fits technically into what we are doing (I'm sure it does...) 2) Administrative - how, where and when As for #2 my questions to you are : a) What is the timing for this donation? How soon? b) Do you see this as coming straight to Geronimo to be part of Geronimo initially, or to the Apache Incubator where we could work on it with you and then make the decision of coming to the Geronimo project or being something else, like a stand-alone top-level project. c) I assume that you'd be offering committers to help us with the codebase and to continue working and expanding. Do you have an idea of how many? Thanks for doing this, and we look forward to discussion on both subjects above. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Unified Tomcat/Jetty Plans
done. For the future, the usual approach is to send a message to [EMAIL PROTECTED] thanks geir On Jul 4, 2005, at 8:30 AM, Jain, Rahul wrote: Hi, Can you please take me off from the mailing list. Thanks, Rahul Jain -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: 04 July 2005 17:59 To: dev@geronimo.apache.org Subject: Re: Unified Tomcat/Jetty Plans On Jul 4, 2005, at 1:34 AM, Aaron Mulder wrote: As far as design work goes, we've historically not had the position of review-then-commit. I think we're trying to increase the amount of discussion and planning on the list, but I'm not prepared to go to a review-then-commit strategy. Are you? Short of that, yes, let's talk on the list as we have been, but we also need to be prepared to make adjustments to code that's committed as issues are identified. No, I don't think we're near review-then-commit at this time as I don't see the necessity to slow things down like that. That said, Jeremy has a point - in general if something will affect all users, we should get into the habit of bringing up for discussion first. Yeah, we're still early and yeah, things are changing, but there's a good balance we can find. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: CMP Field Mapping Required?
Regarding the DDL I think we should probably generate the DDL and pop it in the ejb module that it was generated for (perhaps in the META-INF directory). I prefer this approach as many DBAs do not like the idea of the infrastructure creating tables and prefer to do this themselves. At least having our initial view of the DDL would help the DBAs out. I'm +1 on the dynamic creation as for the developer it makes their lives a lot easier. - Matt - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: dev@geronimo.apache.org Sent: Saturday, July 02, 2005 1:50 PM Subject: Re: CMP Field Mapping Required? +1 to Gianny's idea Maybe we can had a guessed flag on all the implicit settings in the DConfigBeans. Then if someone sets it by hand we clear the flag. I'm guessing this might not be practical, but it would be cool if it could be done. -dain On Jul 1, 2005, at 10:00 PM, Gianny Damour wrote: +1 Also, I think that we need to clearly display a warning message when an implicit mapping is infered. I also think that the underlying database schema should be automatically created upon deployment, if explicitely requested. And a standalone tool should be provided to generate a DML script. Thanks, Gianny On 2/07/2005 4:39 AM, Aaron Mulder wrote: It looks like our intention is that cmp-field-mappings are required in openejb-jar.xml. That is, a single schema sequence contains the table name and one or more cmp-field-mappings, which kind of implies that you can't leave out the cmp-field-mappings, though of course there's no way for us to force you (via the schema) to include one for each CMP field in ejb-jar.xml. Also, we do currently throw a deployment error if you forget a field. But I wonder whether this is all necessary. We could just default the column name to the CMP field name, so you would only need to provide the mapping if they were different. Likewise, we could default the table name to the ejb-name and make that optional too. What does everyone think about allowing defaults like that? I think it would be handy for trivial demos/examples, and unlikely to be used for real apps. All else being equal, I'm happy to support easy examples. But I'm not sure if people feel like explicit deployment errors would be better than using defaults if you try to map everything but forget one. Aaron
Re: Integration of Geronimo modules (Tx / JCA) in Spring
+1 for giving this stuff a home... James Strachan wrote: It'd be good to commit the code to some place (maybe Geronimo SVN?) so we can all share help maintain an easy-to-embed Spring enabled JCA container. I'll gladly help all I can too - though David is da man when it comes to JCA. (I've long wanted us to rename Geronimo's JCA container 'Jencks' in honour of our JCA genius :) On 2 Jul 2005, at 16:52, Thierry Templier wrote: David, No problem to send you the code ;-) I will package it and send it to you at the beginning of the next week. Thanks a lot for your help and your proposal of reviewing our code! Thierry This is great news! I think I will have a bit of time now to help out or at least review what you have done. Can you point me to your code? How can I help? Many thanks, david jencks Take a look at my blog: http://templth.blogspot.com/ __ _ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com James --- http://radio.weblogs.com/0112098/ ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: Publishing unstable builds (i.e. unofficial releases)
On Mon, 4 Jul 2005, Geir Magnusson Jr. wrote: Can we just shift the ports via some kind of cmd line or config? That way we can run periodically on minotaur and drop out nightlies automatically... ROFL!! Maybe it's time to consider making it easier to change ports for an existing Geronimo configuration. :) FWIW, the assembly module uses substitution tokens for all the ports, but right now the values are just coded into maven.xml. If someone wants to pull those values out into a property file, it would be easy enough to build for different ports by swapping property files. I think this may be necessary because I believe Geronimo binds to 8080 during the processing of the assembly module. Still, it would be really nice to have easier editing for things like ports for an existing server. I guess this belongs in a different thread. Aaron
Re: Startup Scripts discussion ( GERONIMO-693 )
On Mon, Jul 04, 2005 at 11:22:59PM +1100, [EMAIL PROTECTED] wrote: what do people think about basing the startup scripts (as much as possible) on tomcat's catalina.bat catalina.sh http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/bin/ (since they have been used for years and many users would be familiar with their style of configuration)? I like the idea of using a well-known baseline for the Geronimo scripts, but could we call the shell script geronimo instead of geronimo.sh? I prefer to not expose the implementation (shell script) in the interface. Thanks, Toby
Re: Startup Scripts discussion ( GERONIMO-693 )
+1 on the switch idea. It would be nice to have this sort of control. Aaron Mulder wrote: I guess one of the important questions -- and maybe this is what you meant by a service -- is should Geronimo be launched in the background or left running for Ctrl-C. The Tomcat builds I've used semi-recently seem to kick it off in the background. I kind of prefer the foreground during development, and background for servers. It would be extra nice just to support a -daemon switch or something (so the default was foreground but it's easy to force into the background). Aaron On Mon, 4 Jul 2005 [EMAIL PROTECTED] wrote: To get the ball rolling on startup scripts http://issues.apache.org/jira/browse/GERONIMO-693 , what do people think about basing the startup scripts (as much as possible) on tomcat's catalina.bat catalina.sh http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/bin/ (since they have been used for years and many users would be familiar with their style of configuration)? Here is my initial list of requirements for startup scripts for discussion. If anyone else has some requirements to add (please indicate priority.. e.g. mandatory or nice to have)? I will consolidate comments into a proposal (e.g. documenting command syntax). Server Startup: * script must specify -Djava.endorsed.dirs=lib/endorsed to ensure Tomcat works * allow plan names to be specified for advanced users. * start under JPDA debugger if 1st argument is jpda instead of start (optional JPDA_TRANSPORT JPDA_ADDRESS environment variables) * start under security manager (causes -Djava.security.manager and -Djava.security.policy==xx to be passed to the JVM) How should a policy file be specified? * specify directory for temporary files (e.g. GERONIMO_TMPDIR environment variable) * allow jvm options to be passed (e.g. JAVA_OPTS environment variable) * (for discussion) should the one server startup script also be used for starting Geronimo as a service? I don't plan to implement this initially, but would like to plan how we would do it. Currently Tomcat can be started as a service, but they don't use a script to start it as a service. See http://jakarta.apache.org/tomcat/tomcat-5.5-doc/setup.html . Does anyone know if there is a JIRA issue for starting Geronimo as a service? I can't find one. * (for discussion) Can we introduce some type of startup mode parameter that removes the need for people to remember to start the org/apache/geronimo/RuntimeDeployer configId). Could having such a parameter make manuals/books easier to write? I see a few possible modes of startup (please comment if you can think of others): - start with previous configuration (no configIds specified as arguments on Java command). This would be the default mode. - start with a specific list of configIds. Only these configIds will be started. - start with a minimal configuration for J2EE (this includes the org/apache/geronimo/RuntimeDeployer configuration). - (future) start with a minimal configuration for non-J2EE use. There was a discussion on the dev list - (future) start with a rolled back configuration? Server Shutdown == More thought needed here. Any comments? Deploy Tool Startup: = * starting under JPDA debugger * allow jvm options to be passed Currently the deploy tool accepts some parameters with two leading minus characters (e.g. --user system). The Tomcat startup scripts currently have parameters that have a single leading minus character (e.g. -security). Should the startup script parameters be using the same prefix (two leading minus characters) as the Java code or should it be using a different prefix? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
Re: Integration of Geronimo modules (Tx / JCA) in Spring
+1 too! Thierry +1 for giving this stuff a home... James Strachan wrote: It'd be good to commit the code to some place (maybe Geronimo SVN?) so we can all share help maintain an easy-to-embed Spring enabled JCA container. I'll gladly help all I can too - though David is da man when it comes to JCA. (I've long wanted us to rename Geronimo's JCA container 'Jencks' in honour of our JCA genius :) Take a look at my blog: http://templth.blogspot.com/ ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com
Re: Unified Tomcat/Jetty Plans
I went ahead and added a separate helper class that detects the bad namespace and switches it to the new one. Unfortunately there's a bit of code in the builder just to detect the plan with a different name, but it should be easy enough to back out later. Aaron On Sun, 3 Jul 2005, David Jencks wrote: Rather than adding code to the builders to accept obsolete schema versions, I would rather provide a standalone tool to update old plans. I don't want to get into the business of supporting non-formally-released obsolete formats forever. Thoughts? thanks david jencks On Jul 3, 2005, at 11:14 PM, David Jencks wrote: On Jul 3, 2005, at 8:17 PM, Aaron Mulder wrote: Jeremy, No need to exaggerate. You can take a friendly tone and still make your point. No one's saying that altering configuration formats is a good thing, just that it will steadily get worse the more stable the server gets. And note that an unstable release is exactly that -- we need a well-documented Milestone 4 release to direct new users to. In the mean time, I'm trying to set up a weekly build environment here, so hopefully I'll put up a fresh unstable release from that tomorrow. Finally, as for the extra mile, I have no idea how to get XMLBeans to accept an XML file that could contain one of two namespaces, but is otherwise identical in content (to handle old Jetty files). Any constructive tips? I think this is fairly easy to do using an xmlcursor. I do a lot of it in SchemaConversionUtils to convert the namespace of the embedded naming and security elements to their actual namespaces. If we add this I think we should print a loud warning that the behavior will not be supported forever. I suppose for Tomcat we could implement a schema converter that would turn the Tomcat-specific elements into container-config elements, but this seems like a lot of work. If we get a lot of feedbcak from confused Tomcat users I'll be happy to look into if further. I would think that the tomcat integration is new enough so we don't have to worry about this. thanks david jencks Aaron P.S. To address Dain's comment, I think he'd agree we need to call a moratorium on config changes once we reach a certain level of pre-1.0 stability -- perhaps RC builds or whatever. On Sun, 3 Jul 2005, Jeremy Boynes wrote: So let me get this right ... * announce to the world we pass the CTS tests and put out an unstable release * just when people are looking at the project, change the deployment plans in an incompatible way * don't provide any upgrade tool, just tell users they need to edit all their existing plans * tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out And this is somehow supposed to encourage people to use this software? Aaron, I appreciate what you are trying to do. Please go the extra mile and make sure existing plans continue to work - it is not hard to do and will avoid putting off a lot of potential users. -- Jeremy Dain Sundstrom wrote: +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Donation of a CORBA Orb
Geir, Thanks for your questions, as I was trying to answer the response ended up becoming rather lengthy... First off, I don't think that it makes too much sense to just toss a bunch of code over the fence; that would be a dead-end. We need to set it up such that it becomes part of the community, and to do this I am thinking that it would be good to engage the community in rewriting some parts of the ORB that we were thinking to refactor anyway. If we piecemeal the contribution in smaller chunks I am thinking there is a better chance to make it everybody's property. As for schedule of this, we're thinking that it would come in pieces over the next 4 months or so. We need to do some clean-up and partitioning from the rest of our code base and as I said before, we would like to introduce this whole thing gently both to us and the community. I think of this as a sing-along or karaoke project: somewhere in between writing from scratch and donation. We will take the individual parts of the Trifork ORB, clean them up with coding standards, javadoc, etc.; and have the community be part of reworking and improving the pieces along the way. For some parts, such as the core io, I would like it to be redone entirely; whereas much of the higher-level logic such as RMI/IIOP and POA handling can go almost straight through. When we're all the way though the entire code base will be appropriately apachified. As for where it should be placed ASF-wise, I am thinking that it would be best to place it as part of Geronimo initially, because it is a good thing to have a concrete project [the appserver] to drive the requirements. Also, the featureset required to do Java EE is somewhat less than the full CORBA spec (for instance, we have no interface/implementation repository, and no IDL compiler). Our CORBA subsystem is written almost entirely by two people (of which one is me), and so we would initially have two people on this. Depending on how this thing takes off we can add more people over time. I have started working on a road map for how the donation could progress over time, and I will share this with you once it's a bit further along.However, just to tease everyone, below is an example of where I am thinking we could start. As for matching the technology, I don't really know where to begin; but an ORB is a relatively standard piece of technology. I can come with some random highlights: - The ORB is quite clean in the sense that it has literally no statics; since it is designed to be able to run multiple concurrent instances. - In our RMI/IIOP (and thus our EJB container) we generate all stubs directly in memory; so there is no need to have javac in the loop. However, since CORBA stubs (and thus RMI/IIOP stubs) needs to extend a class [javax.rmi.CORBA.Stub] the JDK Proxies won't do it, so we have our own implementation of java.lang.reflect.Proxy based on BCEL that allows a proxy to be subclass of a given class. - Many EJB containers have a shortcut to effectively implement LocalEJB semantics for local calls to make applications run faster; even though this is really a break of semantics. Our RMI/IIOP has a middle-ground option which is a very efficient in-memory deep copy with very-close-to-full java.io.Serializable semantics. It avoids writing everything to a byte array; passing immutable objects such as Strings, java.lang.Integer, etc. straight through; but copies all other objects properly. - All wire-level security and transaction processing is done cleanly in interceptors; so for these parts we can probably use most of what you already have. The non-portable part is essentially in how you tell CORBA to use SSL; as you have surely experienced yourselves. Please let me know if you have any questions. Kresten Krab Thorup CTO, Trifork A final side note: internally we call this CORBA project Navajo, as the IIOP protocol is appropriately backwards and obscure to be named after the indians that were employed to relay secret messages in the pacific during WWII :-), see http://www.history.navy.mil/faqs/ faq61-2.htm Anyway, here is the first project I am thinking of... == first project == Right now the Trifork ORB is using NIO for the server-side of IIOP, but classic IO for the client side. The NIO part is great because it lets us run all corba handling in a single selector thread backed by the appserver's thread pool. However, With the experience from working with this for the last 5 years, I would like to redo the core I/O subsystem, and so I have started to do the first steps towards this rework. The benefits of this, apart from cleaning up code that has grown over time, would be: - Reduce copying data through the stack. - Reduce thread usage further to support even more clients. - Off-load readingwriting - e.g. response writing to the framework so as
Re: [jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
That should be added automatically by the main class. -dain On Jul 3, 2005, at 9:36 PM, Jeff Genender (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-693? page=comments#action_12314982 ] Jeff Genender commented on GERONIMO-693: Do not forget the -Djava.endorsed.dirs=lib/endorsed to the java command line in these scripts or Tomcat will not run. Need startup scripts in bin directory - Key: GERONIMO-693 URL: http://issues.apache.org/jira/browse/GERONIMO-693 Project: Geronimo Type: New Feature Environment: Windows, Linux, Mac OS X Reporter: Erin Mulder Assignee: John Sisson Priority: Minor It would be nice to have obvious startup.sh and startup.bat scripts in the bin directory so that the user doesn't need to look at the README file to figure out how to start the server. (java - jar bin/server.jar isn't hard -- it's just not quite as brainless as a script called startup). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
Dain, This won't work...the JVM seems to need this at startup. We tried having the classes set this property themselves, but there is something in pre-startup of the JVM that requires this setting in order for the endorsed dirs to take effect. Setting it once the JVM has started results in the endorsed.dir property being ignored. Jeff Dain Sundstrom wrote: That should be added automatically by the main class. -dain On Jul 3, 2005, at 9:36 PM, Jeff Genender (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-693? page=comments#action_12314982 ] Jeff Genender commented on GERONIMO-693: Do not forget the -Djava.endorsed.dirs=lib/endorsed to the java command line in these scripts or Tomcat will not run. Need startup scripts in bin directory - Key: GERONIMO-693 URL: http://issues.apache.org/jira/browse/GERONIMO-693 Project: Geronimo Type: New Feature Environment: Windows, Linux, Mac OS X Reporter: Erin Mulder Assignee: John Sisson Priority: Minor It would be nice to have obvious startup.sh and startup.bat scripts in the bin directory so that the user doesn't need to look at the README file to figure out how to start the server. (java - jar bin/server.jar isn't hard -- it's just not quite as brainless as a script called startup). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Questions about CORBA
On Jul 3, 2005, at 11:31 PM, Viacheslav N tararin wrote: Dain Sundstrom пишет: If it comes down to fixing OpenORB or writing our own ORB, I think writing our own will be faster. OpenORB is quite difficult to understand and was written before many modern concepts like IoC were introduced. The biggest problem this the current OpenORB codebase is that it doesn't properly implement IIOP so it cant talk to any other ORBs (and it is difficult to find the code to fix). Can you provide an example? We using OpenORB for our products about 5 years, it properly work with OmniORB at less. We were using the head version and it could not pass an array of primitive values to another orb. IIRC, character types were not being marshaled as a wchar marshaled, but it has been a while. Also, the iiop operation name manger is broken. If you have an overloaded method with an array type it will generate the wrong operation name. For example: void blah(); void blah(String[] foo); -dain
Re: Donation of a CORBA Orb
Kresten Krab Thorup wrote: As for where it should be placed ASF-wise, I am thinking that it would be best to place it as part of Geronimo initially, because it is a good thing to have a concrete project [the appserver] to drive the requirements. Also, the featureset required to do Java EE is somewhat less than the full CORBA spec (for instance, we have no interface/implementation repository, and no IDL compiler). Let me start by thanking you for wanting to contribute code to the project. This is awesome. Relative to the statement above, is there a reason you want the ORB directly in the Geronimo project? I can see this orb being an important project in its own right and can have many uses beyond Geronimo. If not as its own ASF project, dare I say the possibility of a sub-project flame suit on ;-)? I really think an orb is big enough, and important enough to be its own living/breathing project. Perhaps this is something to bring up now... Is there a thought on a Geronimo holding project? We will likely encounter more chunks of code that can and should live on thier own. Since webservices has ws and database has db, what about an as for application server and components? I think this is something we really need to consider since we will be growing components fairly regularly. I think this is great for the community as well. Thoughts? -- Jeff Genender http://geronimo.apache.org
Re: Integration of Geronimo modules (Tx / JCA) in Spring
On Jul 4, 2005, at 2:11 AM, James Strachan wrote: It'd be good to commit the code to some place (maybe Geronimo SVN?) so we can all share help maintain an easy-to-embed Spring enabled JCA container. I'll gladly help all I can too - though David is da man when it comes to JCA. (I've long wanted us to rename Geronimo's JCA container 'Jencks' in honour of our JCA genius :) +1 to Jencks -dain
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: Which leads me back to the web plans. Some of your comments aren't clear to me. For example: How about defining a common interface for the runtime bits that both Jetty and Tomcat runtimes can implement? Jetty and Tomcat are operating off the same XMLBeans right now. If there's further unification that can be done -- by merging runtime bits, let's work on it. But that doesn't have anything to do with the XML format. They are using the same XML but the underlying implementations are very different; if you deploy an application using the Jetty builder it will not run on a Tomcat server. If you define a common interface for the runtime there you are decoupling the builder from the runtime implementation: the builder generates code just to the standard interface. That would result in one builder and two runtimes. It would also mean the builder would not need to change as additional runtimes were added (e.g. the Jetty 6 one), provided each container only needed LCD features. Ultimately I think this is a simpler and more flexible architecture. It not only supports the LCD schema defined by the generic builder, it is also capable of supporting specialized builders for each implementation. Each specialized builder will require its own XML - experience has shown there is just so far you can go with generic properties before it becomes unusable. Eventually we will get back to where we are now with different schemas for different containers (which is another reason for not breaking all the applications). This need not be really complex as the specialized builders can extend the generic one and the specialized XML can extend the generic XML. Most of the heavy lifting is done in the generic builder (to the common inrerface) and the only code in the specialized ones is the container specific stuff. -- Jeremy
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: Dude, need you use the f-bomb? Is this -- Non-technical tip: think about the f***ing users -- honestly your idea of a professional interaction with your peers? Dude, do you think ignoring the needs of users is professional software development? That breaking everyone's application because you couldn't be bothered to think of an upgradable solution is professional behaviour? Before throwing the p-word around look in the mirror. By the way, I think you were exaggerating when you said tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out. Do you feel that's an accurate representation of the other side of this conversation? +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. I read that as saying there will continue to be drastic changes until the 1.0 release - is that interpretation inaccurate? If you were a user, in light of that statement would you look at this software now or would you wait until after 1.0? As far as stability goes, I hate to say it, but we're not there yet. I'm going to have to make massive change to my book for the next milestone. The entire security system looks nothing like it did in M3, web services were not present in M3, MDBs did not work in M3, CMP was incomplete in M3, there was no Tomcat option at all in M3, and the list goes on. Add all that up, and removing 6 characters from a namespace is a trivial change. I don't think anyone *should* be contemplating Geronimo for anything serious. We haven't even released a beta yet! You might want to re-read what you said here. M3 was incomplete, which is different from incompatible. You make a good point with respect to security though - immediately after M3 was cut, all the security definitions incompatibly changed showing that, indeed, this project really does place little value on compatibility. It's not that the change itself isn't trivial, but that it is unnecessary and impacts EVERYONE. I would have hoped someone with your extensive professional experience would have understood that. And on the topic of coordination for builds, it's true we could do better. But you know what? Flaming me (or David, not sure who you were targeting, really) doesn't help. If you'd like to propose a build, such as M4, and ask for a feature freeze while we prepare and test it, I think that would be a great idea. It would have been nice to have done that before we announced that we pass the test, but let's go from where we are. I wasn't flaming anyone in particular but everyone in general. Where is the co-ordination? There was an M4 proposal about a month ago - who is co-ordinating it? When will it be there, what will it contain? Why *isn't* there a feature freeze, or even a branch? As far as design work goes, we've historically not had the position of review-then-commit. I think we're trying to increase the amount of discussion and planning on the list, but I'm not prepared to go to a review-then-commit strategy. Are you? Short of that, yes, let's talk on the list as we have been, but we also need to be prepared to make adjustments to code that's committed as issues are identified. Now who's exaggerating? You asked for constructive tips, one of those is when you're about to break everyone's application, bring it up on the list first as other people may be able to help you find a way to avoid doing so. That avoids firedrills after and keeps users happier. -- Jeremy
Re: Unified Tomcat/Jetty Plans
On Mon, 4 Jul 2005, Jeremy Boynes wrote: I wasn't flaming anyone in particular but everyone in general. Where is the co-ordination? There was an M4 proposal about a month ago - who is co-ordinating it? When will it be there, what will it contain? Why *isn't* there a feature freeze, or even a branch? So does this mean you're volunteering to be the release coordinator? Aaron
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: On Mon, 4 Jul 2005, Jeremy Boynes wrote: I wasn't flaming anyone in particular but everyone in general. Where is the co-ordination? There was an M4 proposal about a month ago - who is co-ordinating it? When will it be there, what will it contain? Why *isn't* there a feature freeze, or even a branch? So does this mean you're volunteering to be the release coordinator? I have already been told I would be unwelcome in that role. It is time for the PMC to get its act together. -- Jeremy
Re: Unified Tomcat/Jetty Plans
On Mon, 4 Jul 2005, Jeremy Boynes wrote: I wasn't flaming anyone in particular but everyone in general. Where is the co-ordination? There was an M4 proposal about a month ago - who is co-ordinating it? When will it be there, what will it contain? Why *isn't* there a feature freeze, or even a branch? So does this mean you're volunteering to be the release coordinator? I have already been told I would be unwelcome in that role. It is time for the PMC to get its act together. Well, if you're not going to be the release manager, perhaps instead of flaming everyone in general, you could find a qualified volunteer to be the release manager? Perhaps you could start a page on the Wiki outlining what kind of steps could go into the release procedure? Perhaps you could recommend a date for the next release that we can start working toward? Perhaps you can begin sorting through the JIRA issues and adding them to the M4 release notes document? I can think of all kinds of ways for one of us to get involved if they want to help us produce a more organized release. Aaron
Re: [jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
That is weird. The endorsed dir in the main class seems to work for the TCK tests. -dain On Jul 4, 2005, at 9:57 AM, Jeff Genender wrote: Dain, This won't work...the JVM seems to need this at startup. We tried having the classes set this property themselves, but there is something in pre-startup of the JVM that requires this setting in order for the endorsed dirs to take effect. Setting it once the JVM has started results in the endorsed.dir property being ignored. Jeff Dain Sundstrom wrote: That should be added automatically by the main class. -dain On Jul 3, 2005, at 9:36 PM, Jeff Genender (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-693? page=comments#action_12314982 ] Jeff Genender commented on GERONIMO-693: Do not forget the -Djava.endorsed.dirs=lib/endorsed to the java command line in these scripts or Tomcat will not run. Need startup scripts in bin directory - Key: GERONIMO-693 URL: http://issues.apache.org/jira/browse/GERONIMO-693 Project: Geronimo Type: New Feature Environment: Windows, Linux, Mac OS X Reporter: Erin Mulder Assignee: John Sisson Priority: Minor It would be nice to have obvious startup.sh and startup.bat scripts in the bin directory so that the user doesn't need to look at the README file to figure out how to start the server. (java - jar bin/server.jar isn't hard -- it's just not quite as brainless as a script called startup). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
Well if thats working for TCK...I'll be the first to admit I am wrong. Early on in the Tomcat integration development, we attempted to set the endorsed.dir in the TomcatContainer GBean through an attribute, but it never stuck. We could never get the Tomcat container to launch without the dreaded XML/Doc error. Perhaps it needs to be done in the main class as opposed to the TomcatContainer (could this have to do with when the classes are loaded?). I am willing to try this out. Could you point me in the direction to where this gets set in the main class? I would be happy to verify this indeed works (or doesn't work) with Tomcat. Jeff Dain Sundstrom wrote: That is weird. The endorsed dir in the main class seems to work for the TCK tests. -dain On Jul 4, 2005, at 9:57 AM, Jeff Genender wrote: Dain, This won't work...the JVM seems to need this at startup. We tried having the classes set this property themselves, but there is something in pre-startup of the JVM that requires this setting in order for the endorsed dirs to take effect. Setting it once the JVM has started results in the endorsed.dir property being ignored. Jeff Dain Sundstrom wrote: That should be added automatically by the main class. -dain On Jul 3, 2005, at 9:36 PM, Jeff Genender (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-693? page=comments#action_12314982 ] Jeff Genender commented on GERONIMO-693: Do not forget the -Djava.endorsed.dirs=lib/endorsed to the java command line in these scripts or Tomcat will not run. Need startup scripts in bin directory - Key: GERONIMO-693 URL: http://issues.apache.org/jira/browse/GERONIMO-693 Project: Geronimo Type: New Feature Environment: Windows, Linux, Mac OS X Reporter: Erin Mulder Assignee: John Sisson Priority: Minor It would be nice to have obvious startup.sh and startup.bat scripts in the bin directory so that the user doesn't need to look at the README file to figure out how to start the server. (java - jar bin/server.jar isn't hard -- it's just not quite as brainless as a script called startup). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: On Mon, 4 Jul 2005, Jeremy Boynes wrote: I wasn't flaming anyone in particular but everyone in general. Where is the co-ordination? There was an M4 proposal about a month ago - who is co-ordinating it? When will it be there, what will it contain? Why *isn't* there a feature freeze, or even a branch? So does this mean you're volunteering to be the release coordinator? I have already been told I would be unwelcome in that role. It is time for the PMC to get its act together. Well, if you're not going to be the release manager, perhaps instead of flaming everyone in general, you could find a qualified volunteer to be the release manager? Perhaps you could start a page on the Wiki outlining what kind of steps could go into the release procedure? Perhaps you could recommend a date for the next release that we can start working toward? Perhaps you can begin sorting through the JIRA issues and adding them to the M4 release notes document? I can think of all kinds of ways for one of us to get involved if they want to help us produce a more organized release. As I said, I have been told that I would not be welcome in that role - don't flame me for not doing what I was told would not be welcome if I did. All the things you list need to be done as part of the release, plus a lot more. The biggest things is finding someone to do it. That will need buy-in from the PMC so it needs to get its act together. -- Jeremy
Re: [jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
I think the trick is you must set the value before the vm attempt to load any classes from the endorsed packages (xml, corba and a few others). -dain On Jul 4, 2005, at 11:40 AM, Jeff Genender wrote: Well if thats working for TCK...I'll be the first to admit I am wrong. Early on in the Tomcat integration development, we attempted to set the endorsed.dir in the TomcatContainer GBean through an attribute, but it never stuck. We could never get the Tomcat container to launch without the dreaded XML/Doc error. Perhaps it needs to be done in the main class as opposed to the TomcatContainer (could this have to do with when the classes are loaded?). I am willing to try this out. Could you point me in the direction to where this gets set in the main class? I would be happy to verify this indeed works (or doesn't work) with Tomcat. Jeff Dain Sundstrom wrote: That is weird. The endorsed dir in the main class seems to work for the TCK tests. -dain On Jul 4, 2005, at 9:57 AM, Jeff Genender wrote: Dain, This won't work...the JVM seems to need this at startup. We tried having the classes set this property themselves, but there is something in pre-startup of the JVM that requires this setting in order for the endorsed dirs to take effect. Setting it once the JVM has started results in the endorsed.dir property being ignored. Jeff Dain Sundstrom wrote: That should be added automatically by the main class. -dain On Jul 3, 2005, at 9:36 PM, Jeff Genender (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-693? page=comments#action_12314982 ] Jeff Genender commented on GERONIMO-693: Do not forget the -Djava.endorsed.dirs=lib/endorsed to the java command line in these scripts or Tomcat will not run. Need startup scripts in bin directory - Key: GERONIMO-693 URL: http://issues.apache.org/jira/browse/GERONIMO-693 Project: Geronimo Type: New Feature Environment: Windows, Linux, Mac OS X Reporter: Erin Mulder Assignee: John Sisson Priority: Minor It would be nice to have obvious startup.sh and startup.bat scripts in the bin directory so that the user doesn't need to look at the README file to figure out how to start the server. (java - jar bin/server.jar isn't hard -- it's just not quite as brainless as a script called startup). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
It seems that there is a handful of things that are very difficult to set programatically because their values are processed very early in JVM initialization, and so we have simply added these to startup scripts in our appserver. From the top of my head, these include -Djava.ext.dirs= -Djava.endorsed.dirs= -Djava.security.policy= [unless you implement your own PolicyProvider] -Djava.security.auth.policy=[JAAS thing, only needed for 1.3 JVMs] It's always such a hassle that these have to be added manually... Kresten On Jul 4, 2005, at 9:42 PM, Dain Sundstrom wrote: I think the trick is you must set the value before the vm attempt to load any classes from the endorsed packages (xml, corba and a few others). -dain On Jul 4, 2005, at 11:40 AM, Jeff Genender wrote: Well if thats working for TCK...I'll be the first to admit I am wrong. Early on in the Tomcat integration development, we attempted to set the endorsed.dir in the TomcatContainer GBean through an attribute, but it never stuck. We could never get the Tomcat container to launch without the dreaded XML/Doc error. Perhaps it needs to be done in the main class as opposed to the TomcatContainer (could this have to do with when the classes are loaded?). I am willing to try this out. Could you point me in the direction to where this gets set in the main class? I would be happy to verify this indeed works (or doesn't work) with Tomcat. Jeff Dain Sundstrom wrote: That is weird. The endorsed dir in the main class seems to work for the TCK tests. -dain On Jul 4, 2005, at 9:57 AM, Jeff Genender wrote: Dain, This won't work...the JVM seems to need this at startup. We tried having the classes set this property themselves, but there is something in pre-startup of the JVM that requires this setting in order for the endorsed dirs to take effect. Setting it once the JVM has started results in the endorsed.dir property being ignored. Jeff Dain Sundstrom wrote: That should be added automatically by the main class. -dain On Jul 3, 2005, at 9:36 PM, Jeff Genender (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-693? page=comments#action_12314982 ] Jeff Genender commented on GERONIMO-693: Do not forget the -Djava.endorsed.dirs=lib/endorsed to the java command line in these scripts or Tomcat will not run. Need startup scripts in bin directory - Key: GERONIMO-693 URL: http://issues.apache.org/jira/browse/GERONIMO-693 Project: Geronimo Type: New Feature Environment: Windows, Linux, Mac OS X Reporter: Erin Mulder Assignee: John Sisson Priority: Minor It would be nice to have obvious startup.sh and startup.bat scripts in the bin directory so that the user doesn't need to look at the README file to figure out how to start the server. (java - jar bin/server.jar isn't hard -- it's just not quite as brainless as a script called startup). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira smime.p7s Description: S/MIME cryptographic signature
Preparation for M4
So, JavaOne is over, the 4th of July holiday is almost over. Let's start the release talk. Minimally, to get M4 out the door, we need to: - Create something for general testing - Cleaned up README (is it out of date?) - Scrub JIRA and prepare our copious changelog - Create human readable release notes - Draft a release announcement - Create/publish the final product Not mandatory, but nice: - A 15 min servlet example with related descriptors - A 15 min ejb example with related descriptors Maybe we could clean up the Magic G Ball for this? I volunteer to put together some binaries of a potential M4. We have a number of people interested in testing. I'll ping them when I have something ready. Any volunteers for the other stuff? Anything I missed? -David
Re: Unified Tomcat/Jetty Plans -- topic drift
I'd like to gently point out that thread is no longer about Jetty/Tomcat deployment descriptors. Releasing is important. I think enough people have spare cycles now. Keep in mind, JavaOne just ended, people just got back with their families, and today is a major US national holiday It's a little too early to get critical about the project getting it's act together. ;-) I've started a new thread on releasing M4. All constructive feedback can go there. Best regards, David Blevins
[jira] Created: (GERONIMO-701) Can't set listen host/IP for Jetty Connectors
Can't set listen host/IP for Jetty Connectors - Key: GERONIMO-701 URL: http://issues.apache.org/jira/browse/GERONIMO-701 Project: Geronimo Type: Bug Components: web Versions: 1.0-M3 Reporter: Aaron Mulder The Jetty network Connector GBeans allow you to set the port but not the listen address (IP or host). Both should be configurable. The class that has the port and (read-only) host property is: geronimo/modules/jetty/org/apache/geronimo/jetty/connector/JettyConnector However it looks like the actual listener is initialized in one of the subclasses - HTTPConnector - HTTPSConnector - AJP13Connector -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-702) Can't set listen host/IP for Tomcat Connectors
Can't set listen host/IP for Tomcat Connectors -- Key: GERONIMO-702 URL: http://issues.apache.org/jira/browse/GERONIMO-702 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M3 Reporter: Aaron Mulder Currently the Tomcat network connector GBean lets you specify the port to listen on, but not the host/IP. Both should be allowed. The class in question is: geronimo/modules/tomcat/org/apache/geronimo/tomcat/ConnectorGBean When this is done, the getAddress method on that class should be changed to return the correct listen address instead of being hardcoded to return 0.0.0.0 and the relevant port. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-703) Tomcat assumes Geronimo start directory
Tomcat assumes Geronimo start directory --- Key: GERONIMO-703 URL: http://issues.apache.org/jira/browse/GERONIMO-703 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M3 Reporter: Aaron Mulder If you start Geronimo from a location other than the main assembly or distribution directory, Tomcat fails to start. It appears to look for var/catalina under the current working directory instead of under GERONIMO_HOME. I believe the ServerInfo can provide the GERONIMO_HOME directory if it's not otherwise available. To replicate: - build the assembly module - go to geronimo/modules/assembly - edit target/geronimo-1.0-SNAPSHOT/var/config/config.list and add org/apache/geronimo/Tomcat as the last line - run java -jar target/geronimo-1.0-SNAPSHOT/bin/startup.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: GBeanInstance should already be stopped before die() is called ERRORs during build
[EMAIL PROTECTED] wrote: Jacek, I still get the error, now only shown twice in build output in svn ver 209054 . I don't get the classnotfoundexception that GERONIMO-673 had. So, it's time to report another issue. Don't you mind if I ask you to do so? If you don't, I will ;) John Jacek
[jira] Assigned: (GERONIMO-701) Can't set listen host/IP for Jetty Connectors
[ http://issues.apache.org/jira/browse/GERONIMO-701?page=all ] Jeremy Boynes reassigned GERONIMO-701: -- Assign To: Jeremy Boynes Can't set listen host/IP for Jetty Connectors - Key: GERONIMO-701 URL: http://issues.apache.org/jira/browse/GERONIMO-701 Project: Geronimo Type: Bug Components: web Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Jeremy Boynes The Jetty network Connector GBeans allow you to set the port but not the listen address (IP or host). Both should be configurable. The class that has the port and (read-only) host property is: geronimo/modules/jetty/org/apache/geronimo/jetty/connector/JettyConnector However it looks like the actual listener is initialized in one of the subclasses - HTTPConnector - HTTPSConnector - AJP13Connector -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Preparation for M4
David Blevins wrote: Not mandatory, but nice: - A 15 min servlet example with related descriptors - A 15 min ejb example with related descriptors I volunteer to do it once I finish the work on PetStore. It should give me enough knowledge about configuration stuff so these 15-minutes examples should not be that hard. If we decide to go this path, I''' report an enhancement in JIRA with the M4 as its target release. Maybe we could clean up the Magic G Ball for this? I know nothing about it, but surely if it makes out the two above I'm up for working on it instead. Once again, I'm in PetStore right now ;) Anything I missed? Yeah...the magic sentence like 'let's the game begin' or something alike so that will finish on time and without any troubles in between ;) -David Jacek
Re: Preparation for M4
I do think it would good to pick a date to aim for. Then we can pick a date in advance of that to make a branch for M4. How long do you think it will take to get the demo apps ready? In any case, I'll volunteer to work on the README and release notes. Aaron On Mon, 4 Jul 2005, David Blevins wrote: So, JavaOne is over, the 4th of July holiday is almost over. Let's start the release talk. Minimally, to get M4 out the door, we need to: - Create something for general testing - Cleaned up README (is it out of date?) - Scrub JIRA and prepare our copious changelog - Create human readable release notes - Draft a release announcement - Create/publish the final product Not mandatory, but nice: - A 15 min servlet example with related descriptors - A 15 min ejb example with related descriptors Maybe we could clean up the Magic G Ball for this? I volunteer to put together some binaries of a potential M4. We have a number of people interested in testing. I'll ping them when I have something ready. Any volunteers for the other stuff? Anything I missed? -David
[jira] Assigned: (GERONIMO-702) Can't set listen host/IP for Tomcat Connectors
[ http://issues.apache.org/jira/browse/GERONIMO-702?page=all ] Jeff Genender reassigned GERONIMO-702: -- Assign To: Jeff Genender Can't set listen host/IP for Tomcat Connectors -- Key: GERONIMO-702 URL: http://issues.apache.org/jira/browse/GERONIMO-702 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Jeff Genender Currently the Tomcat network connector GBean lets you specify the port to listen on, but not the host/IP. Both should be allowed. The class in question is: geronimo/modules/tomcat/org/apache/geronimo/tomcat/ConnectorGBean When this is done, the getAddress method on that class should be changed to return the correct listen address instead of being hardcoded to return 0.0.0.0 and the relevant port. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (GERONIMO-702) Can't set listen host/IP for Tomcat Connectors
Aaron,
I am confident we handle this. The ConnectorGBean is a simply a GBean
proxy for the Tomcat Connector object. You can declaritively change the
ip address to listen on with an initParam called address in the GBean
configuration. See here for an example of how this would be done in our
j2ee-server-tomcat-plan.xml using 192.168.0.1:
gbean name=TomcatWebConnector
class=org.apache.geronimo.tomcat.ConnectorGBean
attribute name=initParams
address=192.168.0.1
port=${PlanTomcatHTTPPort}
maxHttpHeaderSize=8192
maxThreads=150
minSpareThreads=25
maxSpareThreads=75
enableLookups=false
redirectPort=${PlanTomcatHTTPSPort}
acceptCount=100
connectionTimeout=2
disableUploadTimeout=true
/attribute
reference name=TomcatContainer
nameTomcatWebContainer/name
/reference
/gbean
Since we are proxying the call to the Connector object, we support and
pass on all Tomcat configurations to the Tomcat engine as listed here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/http.html. So,
IMHO, I believe we support this for Tomcat.
Does this handle the concern?
Thanks,
Jeff
Aaron Mulder (JIRA) wrote:
Can't set listen host/IP for Tomcat Connectors
--
Key: GERONIMO-702
URL: http://issues.apache.org/jira/browse/GERONIMO-702
Project: Geronimo
Type: Bug
Components: Tomcat
Versions: 1.0-M3
Reporter: Aaron Mulder
Currently the Tomcat network connector GBean lets you specify the port to
listen on, but not the host/IP. Both should be allowed. The class in question
is:
geronimo/modules/tomcat/org/apache/geronimo/tomcat/ConnectorGBean
When this is done, the getAddress method on that class should be changed to return the
correct listen address instead of being hardcoded to return 0.0.0.0 and the
relevant port.
[jira] Assigned: (GERONIMO-703) Tomcat assumes Geronimo start directory
[ http://issues.apache.org/jira/browse/GERONIMO-703?page=all ] Jeff Genender reassigned GERONIMO-703: -- Assign To: Jeff Genender Tomcat assumes Geronimo start directory --- Key: GERONIMO-703 URL: http://issues.apache.org/jira/browse/GERONIMO-703 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Jeff Genender If you start Geronimo from a location other than the main assembly or distribution directory, Tomcat fails to start. It appears to look for var/catalina under the current working directory instead of under GERONIMO_HOME. I believe the ServerInfo can provide the GERONIMO_HOME directory if it's not otherwise available. To replicate: - build the assembly module - go to geronimo/modules/assembly - edit target/geronimo-1.0-SNAPSHOT/var/config/config.list and add org/apache/geronimo/Tomcat as the last line - run java -jar target/geronimo-1.0-SNAPSHOT/bin/startup.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-704) Can't set listen host/IP for RMI Registry
Can't set listen host/IP for RMI Registry - Key: GERONIMO-704 URL: http://issues.apache.org/jira/browse/GERONIMO-704 Project: Geronimo Type: Bug Components: core Versions: 1.0-M3 Reporter: Aaron Mulder The RMI Registry GBean has a configuration attribute for a port, but not for a listen hostname/IP. It should have attributes for both. The class in question is: geronimo/modules/system/src/java/org/apache/geronimo/system/rmi/RMIRegistryService.java When this change is made, the getAddress method should be changed to return the correct listen host/IP instead of 0.0.0.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
If at all possible I'd like to handle these in Java code, since shell scripts aren't very portable or IDE friendly. I believe that the endorsed dir is settable in java code. I don't think we need the ext dirs as we handle class loaders directly, and as for the security stuff, I just don't know what we are using Alan? Jeff? -dain On Jul 4, 2005, at 1:31 PM, Kresten Krab Thorup wrote: It seems that there is a handful of things that are very difficult to set programatically because their values are processed very early in JVM initialization, and so we have simply added these to startup scripts in our appserver. From the top of my head, these include -Djava.ext.dirs= -Djava.endorsed.dirs= -Djava.security.policy= [unless you implement your own PolicyProvider] -Djava.security.auth.policy=[JAAS thing, only needed for 1.3 JVMs] It's always such a hassle that these have to be added manually... Kresten On Jul 4, 2005, at 9:42 PM, Dain Sundstrom wrote: I think the trick is you must set the value before the vm attempt to load any classes from the endorsed packages (xml, corba and a few others). -dain On Jul 4, 2005, at 11:40 AM, Jeff Genender wrote: Well if thats working for TCK...I'll be the first to admit I am wrong. Early on in the Tomcat integration development, we attempted to set the endorsed.dir in the TomcatContainer GBean through an attribute, but it never stuck. We could never get the Tomcat container to launch without the dreaded XML/Doc error. Perhaps it needs to be done in the main class as opposed to the TomcatContainer (could this have to do with when the classes are loaded?). I am willing to try this out. Could you point me in the direction to where this gets set in the main class? I would be happy to verify this indeed works (or doesn't work) with Tomcat. Jeff Dain Sundstrom wrote: That is weird. The endorsed dir in the main class seems to work for the TCK tests. -dain On Jul 4, 2005, at 9:57 AM, Jeff Genender wrote: Dain, This won't work...the JVM seems to need this at startup. We tried having the classes set this property themselves, but there is something in pre-startup of the JVM that requires this setting in order for the endorsed dirs to take effect. Setting it once the JVM has started results in the endorsed.dir property being ignored. Jeff Dain Sundstrom wrote: That should be added automatically by the main class. -dain On Jul 3, 2005, at 9:36 PM, Jeff Genender (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-693? page=comments#action_12314982 ] Jeff Genender commented on GERONIMO-693: Do not forget the -Djava.endorsed.dirs=lib/endorsed to the java command line in these scripts or Tomcat will not run. Need startup scripts in bin directory - Key: GERONIMO-693 URL: http://issues.apache.org/jira/browse/GERONIMO-693 Project: Geronimo Type: New Feature Environment: Windows, Linux, Mac OS X Reporter: Erin Mulder Assignee: John Sisson Priority: Minor It would be nice to have obvious startup.sh and startup.bat scripts in the bin directory so that the user doesn't need to look at the README file to figure out how to start the server. (java - jar bin/server.jar isn't hard -- it's just not quite as brainless as a script called startup). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (GERONIMO-702) Can't set listen host/IP for Tomcat Connectors
Jeff,
I'd like to remove the host and port fron the initParams block and
make separate GBean attributes for them. Then in the GBean constructor,
we can put the appropriate name/value pairs into the initParams before
applying them. I think it would be best to work toward as many GBean
attributes as we can at the expense of blocks of XML or Properties or
whatever. Is that OK with you?
In fact, maybe we should just go ahead and make GBean attributes
for all the values you can list in the initParams section. But right now,
it's the host and port I care about most.
Also, I haven't checked in the getAddress method yet, so that bit
of the JIRA report may not make too much sense. :)
Thanks,
Aaron
On Mon, 4 Jul 2005, Jeff Genender wrote:
Aaron,
I am confident we handle this. The ConnectorGBean is a simply a GBean
proxy for the Tomcat Connector object. You can declaritively change the
ip address to listen on with an initParam called address in the GBean
configuration. See here for an example of how this would be done in our
j2ee-server-tomcat-plan.xml using 192.168.0.1:
gbean name=TomcatWebConnector
class=org.apache.geronimo.tomcat.ConnectorGBean
attribute name=initParams
address=192.168.0.1
port=${PlanTomcatHTTPPort}
maxHttpHeaderSize=8192
maxThreads=150
minSpareThreads=25
maxSpareThreads=75
enableLookups=false
redirectPort=${PlanTomcatHTTPSPort}
acceptCount=100
connectionTimeout=2
disableUploadTimeout=true
/attribute
reference name=TomcatContainer
nameTomcatWebContainer/name
/reference
/gbean
Since we are proxying the call to the Connector object, we support and
pass on all Tomcat configurations to the Tomcat engine as listed here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/http.html. So,
IMHO, I believe we support this for Tomcat.
Does this handle the concern?
Thanks,
Jeff
Aaron Mulder (JIRA) wrote:
Can't set listen host/IP for Tomcat Connectors
--
Key: GERONIMO-702
URL: http://issues.apache.org/jira/browse/GERONIMO-702
Project: Geronimo
Type: Bug
Components: Tomcat
Versions: 1.0-M3
Reporter: Aaron Mulder
Currently the Tomcat network connector GBean lets you specify the port to
listen on, but not the host/IP. Both should be allowed. The class in
question is:
geronimo/modules/tomcat/org/apache/geronimo/tomcat/ConnectorGBean
When this is done, the getAddress method on that class should be changed to
return the correct listen address instead of being hardcoded to return
0.0.0.0 and the relevant port.
[jira] Created: (GERONIMO-705) Can't set listen host/IP for Sun CORBA Name Service GBean
Can't set listen host/IP for Sun CORBA Name Service GBean - Key: GERONIMO-705 URL: http://issues.apache.org/jira/browse/GERONIMO-705 Project: Geronimo Type: Bug Components: CORBA Versions: 1.0-M3 Reporter: Aaron Mulder The Sun CORBA Name Service wrapper GBean lets you specify the port, but not the listen hostname/IP. It should let you specify both. The class in question is: geronimo/openejb/modules/core/src/java/org/openejb/corba/SunNameService.java When this is done, the getAddress() method should be updated to return the proper listen address instead of 0.0.0.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
Dain, If you can handle this in code, I am all for it...as I have said I have been unsuccessful with this with Tomcat. Lets give it a shot and see if it works...if so...this is great. As for security...I coded in some GBean attributes that allow you to declare the following via GBean attributes: javax.security.jacc.PolicyConfigurationFactory.provider javax.security.jacc.policy.provider javax.net.ssl.keyStore javax.net.ssl.keyStorePassword javax.net.ssl.trustStore javax.net.ssl.trustStorePassword However, if they are declared on the command line, then those rule and it will ignore the GBean attributes. We could easily add additional attributes for the security service. But again...we need to be careful when the JVM needs these or it may be too late. Jeff Dain Sundstrom wrote: If at all possible I'd like to handle these in Java code, since shell scripts aren't very portable or IDE friendly. I believe that the endorsed dir is settable in java code. I don't think we need the ext dirs as we handle class loaders directly, and as for the security stuff, I just don't know what we are using Alan? Jeff? -dain On Jul 4, 2005, at 1:31 PM, Kresten Krab Thorup wrote: It seems that there is a handful of things that are very difficult to set programatically because their values are processed very early in JVM initialization, and so we have simply added these to startup scripts in our appserver. From the top of my head, these include -Djava.ext.dirs= -Djava.endorsed.dirs= -Djava.security.policy= [unless you implement your own PolicyProvider] -Djava.security.auth.policy=[JAAS thing, only needed for 1.3 JVMs] It's always such a hassle that these have to be added manually... Kresten On Jul 4, 2005, at 9:42 PM, Dain Sundstrom wrote: I think the trick is you must set the value before the vm attempt to load any classes from the endorsed packages (xml, corba and a few others). -dain On Jul 4, 2005, at 11:40 AM, Jeff Genender wrote: Well if thats working for TCK...I'll be the first to admit I am wrong. Early on in the Tomcat integration development, we attempted to set the endorsed.dir in the TomcatContainer GBean through an attribute, but it never stuck. We could never get the Tomcat container to launch without the dreaded XML/Doc error. Perhaps it needs to be done in the main class as opposed to the TomcatContainer (could this have to do with when the classes are loaded?). I am willing to try this out. Could you point me in the direction to where this gets set in the main class? I would be happy to verify this indeed works (or doesn't work) with Tomcat. Jeff Dain Sundstrom wrote: That is weird. The endorsed dir in the main class seems to work for the TCK tests. -dain On Jul 4, 2005, at 9:57 AM, Jeff Genender wrote: Dain, This won't work...the JVM seems to need this at startup. We tried having the classes set this property themselves, but there is something in pre-startup of the JVM that requires this setting in order for the endorsed dirs to take effect. Setting it once the JVM has started results in the endorsed.dir property being ignored. Jeff Dain Sundstrom wrote: That should be added automatically by the main class. -dain On Jul 3, 2005, at 9:36 PM, Jeff Genender (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-693? page=comments#action_12314982 ] Jeff Genender commented on GERONIMO-693: Do not forget the -Djava.endorsed.dirs=lib/endorsed to the java command line in these scripts or Tomcat will not run. Need startup scripts in bin directory - Key: GERONIMO-693 URL: http://issues.apache.org/jira/browse/GERONIMO-693 Project: Geronimo Type: New Feature Environment: Windows, Linux, Mac OS X Reporter: Erin Mulder Assignee: John Sisson Priority: Minor It would be nice to have obvious startup.sh and startup.bat scripts in the bin directory so that the user doesn't need to look at the README file to figure out how to start the server. (java - jar bin/server.jar isn't hard -- it's just not quite as brainless as a script called startup). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-702) Can't set listen host/IP for Tomcat Connectors
[ http://issues.apache.org/jira/browse/GERONIMO-702?page=all ] Jeff Genender closed GERONIMO-702: -- Fix Version: 1.0-M4 Resolution: Invalid The ConnectorGBean is a simply a GBean proxy for the Tomcat Connector object. You can declaritively change the ip address to listen on with an initParam called address in the GBean configuration. Can't set listen host/IP for Tomcat Connectors -- Key: GERONIMO-702 URL: http://issues.apache.org/jira/browse/GERONIMO-702 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Jeff Genender Fix For: 1.0-M4 Currently the Tomcat network connector GBean lets you specify the port to listen on, but not the host/IP. Both should be allowed. The class in question is: geronimo/modules/tomcat/org/apache/geronimo/tomcat/ConnectorGBean When this is done, the getAddress method on that class should be changed to return the correct listen address instead of being hardcoded to return 0.0.0.0 and the relevant port. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Preparation for M4
I have two examples, tested up to the most recent build, that may require only minor mods for this. 1. Web app - JSP, JSTL, with servlet 2. EJB - stateless session (local), entity Jacek - please let me know if they may be of interest, and I'll email them to you. I also have examples for client (standalone, client container), and JMS (J2EE, ActiveMQ native) if you can use them. - Sing --- Jacek Laskowski [EMAIL PROTECTED] wrote: David Blevins wrote: Not mandatory, but nice: - A 15 min servlet example with related descriptors - A 15 min ejb example with related descriptors I volunteer to do it once I finish the work on PetStore. It should give me enough knowledge about configuration stuff so these 15-minutes examples should not be that hard. If we decide to go this path, I''' report an enhancement in JIRA with the M4 as its target release. Maybe we could clean up the Magic G Ball for this? I know nothing about it, but surely if it makes out the two above I'm up for working on it instead. Once again, I'm in PetStore right now ;) Anything I missed? Yeah...the magic sentence like 'let's the game begin' or something alike so that will finish on time and without any troubles in between ;) -David Jacek
Re: Preparation for M4
David Blevins wrote: Anything I missed? SNAPSHOT elimination so the build is reproducible. Documentation update. Branch so that M4 can stabilize whilst other changes are being made. Acceptance test process - how do we know what works (need to avoid a broken release like M3). -- Jeremy
[jira] Closed: (GERONIMO-701) Can't set listen host/IP for Jetty Connectors
[ http://issues.apache.org/jira/browse/GERONIMO-701?page=all ] Jeremy Boynes closed GERONIMO-701: -- Fix Version: 1.0-M4 Resolution: Fixed Sending modules\jetty\src\java\org\apache\geronimo\jetty\connector\JettyConnector.java Adding modules\jetty\src\test\org\apache\geronimo\jetty\connector Adding modules\jetty\src\test\org\apache\geronimo\jetty\connector\HTTPConnectorTest.java Transmitting file data .. Committed revision 209163. Also added an address attribute for returning the host/port combination Can't set listen host/IP for Jetty Connectors - Key: GERONIMO-701 URL: http://issues.apache.org/jira/browse/GERONIMO-701 Project: Geronimo Type: Bug Components: web Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Jeremy Boynes Fix For: 1.0-M4 The Jetty network Connector GBeans allow you to set the port but not the listen address (IP or host). Both should be configurable. The class that has the port and (read-only) host property is: geronimo/modules/jetty/org/apache/geronimo/jetty/connector/JettyConnector However it looks like the actual listener is initialized in one of the subclasses - HTTPConnector - HTTPSConnector - AJP13Connector -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Preparation for M4
On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote: David Blevins wrote: Anything I missed? SNAPSHOT elimination so the build is reproducible. Right. Missed that one for M3 IIRC. Branch so that M4 can stabilize whilst other changes are being made. We do for every milestone. Don't expect this to be different. Acceptance test process - how do we know what works (need to avoid a broken release like M3). That's what I meant by: DB We have a number of people interested in testing. I'll ping DB them when I have something ready. Was thinking to branch when I dish out the binaries for testing. Rather than the surprise, here is a binary approach we've done in the past. Sounds pretty much like what you are proposing as well. -David
Re: Startup Scripts discussion ( GERONIMO-693 )
toby cabot [EMAIL PROTECTED] wrote on 05/07/2005 12:59:14 AM: On Mon, Jul 04, 2005 at 11:22:59PM +1100, [EMAIL PROTECTED] wrote: what do people think about basing the startup scripts (as much as possible) on tomcat's catalina.bat catalina.sh http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/bin/ (since they have been used for years and many users would be familiar with their style of configuration)? I like the idea of using a well-known baseline for the Geronimo scripts, but could we call the shell script geronimo instead of geronimo.sh? I prefer to not expose the implementation (shell script) in the interface. Are you concerned that we may change shells in the future? The startup script should have the following on the first line to instruct the system which shell interpreter we are using. #! /bin/sh It seems that a lot of applications use the .sh extension (except Apache HTTPD's apachectl): Tomcat - catalina.sh Apache HTTPD - apachectl WebSphere - startServer.sh WebLogic - startWebLogic.sh JBoss - run.sh A number of benefits of using an extension are: a) easy to find shell script files, just search for files ending in .sh b) makes it easier to chmod all script files due to previous point. c) easier for FTP clients to automatically determine whether to use ascii or binary transfers. d) could make it easier for svn property defaults, e.g. *.sh = svn:eol-style=native I would be interested in the opinions of others on this topic. Thanks for the feedback. John Thanks, Toby
Re: Preparation for M4
On Mon, Jul 04, 2005 at 04:27:41PM -0700, Sing Li wrote: I have two examples, tested up to the most recent build, that may require only minor mods for this. 1. Web app - JSP, JSTL, with servlet 2. EJB - stateless session (local), entity Jacek - please let me know if they may be of interest, and I'll email them to you. I also have examples for client (standalone, client container), and JMS (J2EE, ActiveMQ native) if you can use them. - Sing Wow! If you could donate those, that would be a dream come true! It would certainly be a big help for testing we've put the releases together correctly and give users simple examples of working apps. Double win! -David
Re: Preparation for M4
Jeremy Boynes [EMAIL PROTECTED] wrote on 05/07/2005 10:22:36 AM: David Blevins wrote: Anything I missed? SNAPSHOT elimination so the build is reproducible. +1 on SNAPSHOT elimination if possible. John
Re: Startup Scripts discussion ( GERONIMO-693 )
[EMAIL PROTECTED] wrote: Are you concerned that we may change shells in the future? The startup script should have the following on the first line to instruct the system which shell interpreter we are using. #! /bin/sh It seems that a lot of applications use the .sh extension (except Apache HTTPD's apachectl): Tomcat - catalina.sh Apache HTTPD - apachectl WebSphere - startServer.sh WebLogic - startWebLogic.sh JBoss - run.sh A number of benefits of using an extension are: a) easy to find shell script files, just search for files ending in .sh b) makes it easier to chmod all script files due to previous point. c) easier for FTP clients to automatically determine whether to use ascii or binary transfers. d) could make it easier for svn property defaults, e.g. *.sh = svn:eol-style=native I would be interested in the opinions of others on this topic. I would supply the token .sh and .bat files. Jeff
Re: Startup Scripts discussion ( GERONIMO-693 )
[EMAIL PROTECTED] wrote: toby cabot [EMAIL PROTECTED] wrote on 05/07/2005 12:59:14 AM: I like the idea of using a well-known baseline for the Geronimo scripts, but could we call the shell script geronimo instead of geronimo.sh? I prefer to not expose the implementation (shell script) in the interface. Are you concerned that we may change shells in the future? The startup script should have the following on the first line to instruct the system which shell interpreter we are using. #! /bin/sh Not every version of Unix places the shell in the same place which can make this problematic. #!/bin/sh should work for most, /provided to stick to sh/ and don't use ksh or bash extensions (just in case you happen to get a genuine sh implementation). -- Jeremy
Re: Startup Scripts discussion ( GERONIMO-693 )
I'm in favor of the .sh extension for shell scripts Aaron On Mon, 4 Jul 2005, Jeff Genender wrote: [EMAIL PROTECTED] wrote: Are you concerned that we may change shells in the future? The startup script should have the following on the first line to instruct the system which shell interpreter we are using. #! /bin/sh It seems that a lot of applications use the .sh extension (except Apache HTTPD's apachectl): Tomcat - catalina.sh Apache HTTPD - apachectl WebSphere - startServer.sh WebLogic - startWebLogic.sh JBoss - run.sh A number of benefits of using an extension are: a) easy to find shell script files, just search for files ending in .sh b) makes it easier to chmod all script files due to previous point. c) easier for FTP clients to automatically determine whether to use ascii or binary transfers. d) could make it easier for svn property defaults, e.g. *.sh = svn:eol-style=native I would be interested in the opinions of others on this topic. I would supply the token .sh and .bat files. Jeff
[jira] Closed: (GERONIMO-703) Tomcat assumes Geronimo start directory
[ http://issues.apache.org/jira/browse/GERONIMO-703?page=all ] Jeff Genender closed GERONIMO-703: -- Fix Version: 1.0-M4 Resolution: Fixed Now uses ServerInfo to resolve the path. Sendingtomcat/src/java/org/apache/geronimo/tomcat/TomcatContainer.java Transmitting file data . Committed revision 209179. Tomcat assumes Geronimo start directory --- Key: GERONIMO-703 URL: http://issues.apache.org/jira/browse/GERONIMO-703 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Jeff Genender Fix For: 1.0-M4 If you start Geronimo from a location other than the main assembly or distribution directory, Tomcat fails to start. It appears to look for var/catalina under the current working directory instead of under GERONIMO_HOME. I believe the ServerInfo can provide the GERONIMO_HOME directory if it's not otherwise available. To replicate: - build the assembly module - go to geronimo/modules/assembly - edit target/geronimo-1.0-SNAPSHOT/var/config/config.list and add org/apache/geronimo/Tomcat as the last line - run java -jar target/geronimo-1.0-SNAPSHOT/bin/startup.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
Well..upon further review...the endorsed dirs that are set in the main class appears to take hold on Tomcat. This is good ;-) Jeff Dain Sundstrom wrote: If at all possible I'd like to handle these in Java code, since shell scripts aren't very portable or IDE friendly. I believe that the endorsed dir is settable in java code. I don't think we need the ext dirs as we handle class loaders directly, and as for the security stuff, I just don't know what we are using Alan? Jeff? -dain On Jul 4, 2005, at 1:31 PM, Kresten Krab Thorup wrote: It seems that there is a handful of things that are very difficult to set programatically because their values are processed very early in JVM initialization, and so we have simply added these to startup scripts in our appserver. From the top of my head, these include -Djava.ext.dirs= -Djava.endorsed.dirs= -Djava.security.policy= [unless you implement your own PolicyProvider] -Djava.security.auth.policy=[JAAS thing, only needed for 1.3 JVMs] It's always such a hassle that these have to be added manually... Kresten On Jul 4, 2005, at 9:42 PM, Dain Sundstrom wrote: I think the trick is you must set the value before the vm attempt to load any classes from the endorsed packages (xml, corba and a few others). -dain On Jul 4, 2005, at 11:40 AM, Jeff Genender wrote: Well if thats working for TCK...I'll be the first to admit I am wrong. Early on in the Tomcat integration development, we attempted to set the endorsed.dir in the TomcatContainer GBean through an attribute, but it never stuck. We could never get the Tomcat container to launch without the dreaded XML/Doc error. Perhaps it needs to be done in the main class as opposed to the TomcatContainer (could this have to do with when the classes are loaded?). I am willing to try this out. Could you point me in the direction to where this gets set in the main class? I would be happy to verify this indeed works (or doesn't work) with Tomcat. Jeff Dain Sundstrom wrote: That is weird. The endorsed dir in the main class seems to work for the TCK tests. -dain On Jul 4, 2005, at 9:57 AM, Jeff Genender wrote: Dain, This won't work...the JVM seems to need this at startup. We tried having the classes set this property themselves, but there is something in pre-startup of the JVM that requires this setting in order for the endorsed dirs to take effect. Setting it once the JVM has started results in the endorsed.dir property being ignored. Jeff Dain Sundstrom wrote: That should be added automatically by the main class. -dain On Jul 3, 2005, at 9:36 PM, Jeff Genender (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-693? page=comments#action_12314982 ] Jeff Genender commented on GERONIMO-693: Do not forget the -Djava.endorsed.dirs=lib/endorsed to the java command line in these scripts or Tomcat will not run. Need startup scripts in bin directory - Key: GERONIMO-693 URL: http://issues.apache.org/jira/browse/GERONIMO-693 Project: Geronimo Type: New Feature Environment: Windows, Linux, Mac OS X Reporter: Erin Mulder Assignee: John Sisson Priority: Minor It would be nice to have obvious startup.sh and startup.bat scripts in the bin directory so that the user doesn't need to look at the README file to figure out how to start the server. (java - jar bin/server.jar isn't hard -- it's just not quite as brainless as a script called startup). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
New Startup Output
I just put in a change with nicer startup console output. It gives some progress and status information during the server start process and lists the apps deployed and ports used at the end of the startup. Since it uses \r characters to make it work, the output looks lousy if you view it in a log file, so there's a -noprogress argument you can add to the server command line to suppress it (which the Maven deploy tool does, for example). In any case, I'd appreciate any thoughts or feedback on the new look. * Jeremy's already suggested adding a middle ground between -noprogress and what's in there, where it would print more or less the same information but one message per line so it looks nicer in a log. There's just an interface to implement to get the startup sequence calls, so it should be easy enough to support that. * David J recommended the current combination of a short progress bar and status messages instead of my initial attempt, which just had a long (but not very fine-grained) progress bar. I like the way it came out. Now that I've done this, I think we can use the same technique to hide the password on the deployer command line. Thanks, Aaron Log message --- New server startup output - shows a progress bar, timer, and operation status during start - shows a list of started application modules (other than o/a/g/System*) - shows a list of network ports that GBeans tried to bind to The port list is voluntary on behalf of the GBeans. They must declare an attribute of type java.net.InetSocketAddress in order to be included in the list (though it can be a read-only attribute). We should review the current GBeans and make sure they do. There is also some logic around calculating the name of a service. For example, if the same GBean has more than one InetSocketAddress attribute, it tries to add the name of each attribute in the port list, and if the GBean has a name attribute (for GBeans tht may be deployed more than once with different names) it includes that too. The new progress bar does not render particularly well in log files, and can be disabled by passing -noprogress on the server command line. The maven deployment plugin does that.
Re: Preparation for M4
On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote: David Blevins wrote: On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote: David Blevins wrote: Anything I missed? SNAPSHOT elimination so the build is reproducible. Right. Missed that one for M3 IIRC. Branch so that M4 can stabilize whilst other changes are being made. We do for every milestone. Don't expect this to be different. Acceptance test process - how do we know what works (need to avoid a broken release like M3). That's what I meant by: DB We have a number of people interested in testing. I'll ping DB them when I have something ready. Was thinking to branch when I dish out the binaries for testing. Rather than the surprise, here is a binary approach we've done in the past. Sounds pretty much like what you are proposing as well. Yes - in the past we've just tagged and moved on. This time I think we should create the branch at the start of the process rather than at the end as there seem to be a lot of pent up changes planned. Yes, we may need to merge some critical changes back to this branch but hopefully this can be kept to a minimum. So basically, * create a branch now, say 1.0-M4-prep * do the stuff we talking about now on that branch * cut the final M4 distro * drop the 1.0-M4-prep branch Other work can continue on the trunk without destablizing the M4 release. +1 That's pretty much what I had in mind. -David
Re: Preparation for M4
I guess we should also decide whether to make Jetty or Tomcat the default container, and whether to provide separate builds for each. Also, we need to decide whether we're planning to run the entire TCK on the candidate configuration(s). Aaron On Mon, 4 Jul 2005, David Blevins wrote: On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote: David Blevins wrote: On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote: David Blevins wrote: Anything I missed? SNAPSHOT elimination so the build is reproducible. Right. Missed that one for M3 IIRC. Branch so that M4 can stabilize whilst other changes are being made. We do for every milestone. Don't expect this to be different. Acceptance test process - how do we know what works (need to avoid a broken release like M3). That's what I meant by: DB We have a number of people interested in testing. I'll ping DB them when I have something ready. Was thinking to branch when I dish out the binaries for testing. Rather than the surprise, here is a binary approach we've done in the past. Sounds pretty much like what you are proposing as well. Yes - in the past we've just tagged and moved on. This time I think we should create the branch at the start of the process rather than at the end as there seem to be a lot of pent up changes planned. Yes, we may need to merge some critical changes back to this branch but hopefully this can be kept to a minimum. So basically, * create a branch now, say 1.0-M4-prep * do the stuff we talking about now on that branch * cut the final M4 distro * drop the 1.0-M4-prep branch Other work can continue on the trunk without destablizing the M4 release. +1 That's pretty much what I had in mind. -David
Re: Preparation for M4
+1 for Jetty as default (at least until Tomcat does a TCK dance)...but I think we should have a seperate build for each. Aaron Mulder wrote: I guess we should also decide whether to make Jetty or Tomcat the default container, and whether to provide separate builds for each. Also, we need to decide whether we're planning to run the entire TCK on the candidate configuration(s). Aaron On Mon, 4 Jul 2005, David Blevins wrote: On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote: David Blevins wrote: On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote: David Blevins wrote: Anything I missed? SNAPSHOT elimination so the build is reproducible. Right. Missed that one for M3 IIRC. Branch so that M4 can stabilize whilst other changes are being made. We do for every milestone. Don't expect this to be different. Acceptance test process - how do we know what works (need to avoid a broken release like M3). That's what I meant by: DB We have a number of people interested in testing. I'll ping DB them when I have something ready. Was thinking to branch when I dish out the binaries for testing. Rather than the surprise, here is a binary approach we've done in the past. Sounds pretty much like what you are proposing as well. Yes - in the past we've just tagged and moved on. This time I think we should create the branch at the start of the process rather than at the end as there seem to be a lot of pent up changes planned. Yes, we may need to merge some critical changes back to this branch but hopefully this can be kept to a minimum. So basically, * create a branch now, say 1.0-M4-prep * do the stuff we talking about now on that branch * cut the final M4 distro * drop the 1.0-M4-prep branch Other work can continue on the trunk without destablizing the M4 release. +1 That's pretty much what I had in mind. -David
Re: Preparation for M4
On Mon, Jul 04, 2005 at 08:28:56PM -0600, Jeff Genender wrote: +1 for Jetty as default (at least until Tomcat does a TCK dance)...but I think we should have a seperate build for each. Agreed on both points. Aaron Mulder wrote: I guess we should also decide whether to make Jetty or Tomcat the default container, and whether to provide separate builds for each. Also, we need to decide whether we're planning to run the entire TCK on the candidate configuration(s). Aaron On Mon, 4 Jul 2005, David Blevins wrote: On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote: David Blevins wrote: On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote: David Blevins wrote: Anything I missed? SNAPSHOT elimination so the build is reproducible. Right. Missed that one for M3 IIRC. Branch so that M4 can stabilize whilst other changes are being made. We do for every milestone. Don't expect this to be different. Acceptance test process - how do we know what works (need to avoid a broken release like M3). That's what I meant by: DB We have a number of people interested in testing. I'll ping DB them when I have something ready. Was thinking to branch when I dish out the binaries for testing. Rather than the surprise, here is a binary approach we've done in the past. Sounds pretty much like what you are proposing as well. Yes - in the past we've just tagged and moved on. This time I think we should create the branch at the start of the process rather than at the end as there seem to be a lot of pent up changes planned. Yes, we may need to merge some critical changes back to this branch but hopefully this can be kept to a minimum. So basically, * create a branch now, say 1.0-M4-prep * do the stuff we talking about now on that branch * cut the final M4 distro * drop the 1.0-M4-prep branch Other work can continue on the trunk without destablizing the M4 release. +1 That's pretty much what I had in mind. -David
Re: Preparation for M4 -- TCK testsing
On Mon, Jul 04, 2005 at 10:26:40PM -0400, Aaron Mulder wrote: Also, we need to decide whether we're planning to run the entire TCK on the candidate configuration(s). I'm certainly willing to take a chunck of the TCK do that. If others are also willing, we can divide up the sections on the TCK list. -David
[CONSENSUS?] Preparation for M4 -- branch early
Do we have a consensus that we should branch at the beginning of the release cycle instead of at the end as we have done in the past? If so, going to put out an email titled M4 - 24 hour notice of branch, which I think would be a good release practice. -David On Mon, Jul 04, 2005 at 07:15:34PM -0700, David Blevins wrote: On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote: David Blevins wrote: On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote: David Blevins wrote: Anything I missed? SNAPSHOT elimination so the build is reproducible. Right. Missed that one for M3 IIRC. Branch so that M4 can stabilize whilst other changes are being made. We do for every milestone. Don't expect this to be different. Acceptance test process - how do we know what works (need to avoid a broken release like M3). That's what I meant by: DB We have a number of people interested in testing. I'll ping DB them when I have something ready. Was thinking to branch when I dish out the binaries for testing. Rather than the surprise, here is a binary approach we've done in the past. Sounds pretty much like what you are proposing as well. Yes - in the past we've just tagged and moved on. This time I think we should create the branch at the start of the process rather than at the end as there seem to be a lot of pent up changes planned. Yes, we may need to merge some critical changes back to this branch but hopefully this can be kept to a minimum. So basically, * create a branch now, say 1.0-M4-prep * do the stuff we talking about now on that branch * cut the final M4 distro * drop the 1.0-M4-prep branch Other work can continue on the trunk without destablizing the M4 release. +1 That's pretty much what I had in mind. -David
Re: Startup Scripts discussion ( GERONIMO-693 )
Doesn't matter to me, going to symlink that puppy into /usr/local/bin on my machine anyway -- without the extention :) -David On Mon, Jul 04, 2005 at 09:50:09PM -0400, Aaron Mulder wrote: I'm in favor of the .sh extension for shell scripts Aaron On Mon, 4 Jul 2005, Jeff Genender wrote: [EMAIL PROTECTED] wrote: Are you concerned that we may change shells in the future? The startup script should have the following on the first line to instruct the system which shell interpreter we are using. #! /bin/sh It seems that a lot of applications use the .sh extension (except Apache HTTPD's apachectl): Tomcat - catalina.sh Apache HTTPD - apachectl WebSphere - startServer.sh WebLogic - startWebLogic.sh JBoss - run.sh A number of benefits of using an extension are: a) easy to find shell script files, just search for files ending in .sh b) makes it easier to chmod all script files due to previous point. c) easier for FTP clients to automatically determine whether to use ascii or binary transfers. d) could make it easier for svn property defaults, e.g. *.sh = svn:eol-style=native I would be interested in the opinions of others on this topic. I would supply the token .sh and .bat files. Jeff
Re: Startup Scripts discussion ( GERONIMO-693 )
On Mon, Jul 04, 2005 at 06:48:21PM -0700, Jeremy Boynes wrote: [EMAIL PROTECTED] wrote: toby cabot [EMAIL PROTECTED] wrote on 05/07/2005 12:59:14 AM: I like the idea of using a well-known baseline for the Geronimo scripts, but could we call the shell script geronimo instead of geronimo.sh? I prefer to not expose the implementation (shell script) in the interface. Are you concerned that we may change shells in the future? The startup script should have the following on the first line to instruct the system which shell interpreter we are using. #! /bin/sh Not every version of Unix places the shell in the same place which can make this problematic. #!/bin/sh should work for most, /provided to stick to sh/ and don't use ksh or bash extensions (just in case you happen to get a genuine sh implementation). Right. And just an reminder, Linux and OSX don't actually have sh on the machine, it's just bash symlinked (linux) or copied (osx). Something to remember when testing the script. -David
Re: Preparation for M4 -- jetty vs tomcat or jetty and tomcat (two builds)
On Mon, Jul 04, 2005 at 10:26:40PM -0400, Aaron Mulder wrote: I guess we should also decide whether to make Jetty or Tomcat the default container, and whether to provide separate builds for each. So what does the group want? 1) Separate builds 2) Jetty as the default -David
Re: [CONSENSUS?] Preparation for M4 -- branch early
I want to get the key generator changes in for M4. However, I'm currently blocked because I can't add the new module to TranQL. So I'd like to resolve that before the branch. Other than that, I'm fine to go ahead with the 24 hour notice. Oh, I think we also have a problem where the currently running module list never gets saved. So you always get the default services when you start the server. I think I remember a conversation about how it was caused by some bad logic around our shutdown hooks. That needs to be resolved too. Aaron On Mon, 4 Jul 2005, David Blevins wrote: Do we have a consensus that we should branch at the beginning of the release cycle instead of at the end as we have done in the past? If so, going to put out an email titled M4 - 24 hour notice of branch, which I think would be a good release practice. -David On Mon, Jul 04, 2005 at 07:15:34PM -0700, David Blevins wrote: On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote: David Blevins wrote: On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote: David Blevins wrote: Anything I missed? SNAPSHOT elimination so the build is reproducible. Right. Missed that one for M3 IIRC. Branch so that M4 can stabilize whilst other changes are being made. We do for every milestone. Don't expect this to be different. Acceptance test process - how do we know what works (need to avoid a broken release like M3). That's what I meant by: DB We have a number of people interested in testing. I'll ping DB them when I have something ready. Was thinking to branch when I dish out the binaries for testing. Rather than the surprise, here is a binary approach we've done in the past. Sounds pretty much like what you are proposing as well. Yes - in the past we've just tagged and moved on. This time I think we should create the branch at the start of the process rather than at the end as there seem to be a lot of pent up changes planned. Yes, we may need to merge some critical changes back to this branch but hopefully this can be kept to a minimum. So basically, * create a branch now, say 1.0-M4-prep * do the stuff we talking about now on that branch * cut the final M4 distro * drop the 1.0-M4-prep branch Other work can continue on the trunk without destablizing the M4 release. +1 That's pretty much what I had in mind. -David
Re: New Startup Output
I think it would be a great custom to throw up an unstable build containing the feature you want people to try out when asking for feedback. Could you do that and also post an app we can try out (maybe to your space on people.apache.org)? -David On Mon, Jul 04, 2005 at 10:05:29PM -0400, Aaron Mulder wrote: I just put in a change with nicer startup console output. It gives some progress and status information during the server start process and lists the apps deployed and ports used at the end of the startup. Since it uses \r characters to make it work, the output looks lousy if you view it in a log file, so there's a -noprogress argument you can add to the server command line to suppress it (which the Maven deploy tool does, for example). In any case, I'd appreciate any thoughts or feedback on the new look. * Jeremy's already suggested adding a middle ground between -noprogress and what's in there, where it would print more or less the same information but one message per line so it looks nicer in a log. There's just an interface to implement to get the startup sequence calls, so it should be easy enough to support that. * David J recommended the current combination of a short progress bar and status messages instead of my initial attempt, which just had a long (but not very fine-grained) progress bar. I like the way it came out. Now that I've done this, I think we can use the same technique to hide the password on the deployer command line. Thanks, Aaron Log message --- New server startup output - shows a progress bar, timer, and operation status during start - shows a list of started application modules (other than o/a/g/System*) - shows a list of network ports that GBeans tried to bind to The port list is voluntary on behalf of the GBeans. They must declare an attribute of type java.net.InetSocketAddress in order to be included in the list (though it can be a read-only attribute). We should review the current GBeans and make sure they do. There is also some logic around calculating the name of a service. For example, if the same GBean has more than one InetSocketAddress attribute, it tries to add the name of each attribute in the port list, and if the GBean has a name attribute (for GBeans tht may be deployed more than once with different names) it includes that too. The new progress bar does not render particularly well in log files, and can be disabled by passing -noprogress on the server command line. The maven deployment plugin does that.
[jira] Resolved: (GERONIMO-698) Print port map at server startup
[ http://issues.apache.org/jira/browse/GERONIMO-698?page=all ] Aaron Mulder resolved GERONIMO-698: --- Fix Version: 1.0-M4 Resolution: Fixed The solution is voluntary on behalf of each GBean -- they must declare an attribute of type InetSocketAddress. We still need this in ActiveMQ, at least. Print port map at server startup Key: GERONIMO-698 URL: http://issues.apache.org/jira/browse/GERONIMO-698 Project: Geronimo Type: New Feature Reporter: Erin Mulder Assignee: Aaron Mulder Priority: Minor Fix For: 1.0-M4 Would be nice (especially for new users) to have the server print out a list of port assignments upon successful startup. For example: bin/startup.sh Environment information: JDK_HOME: /usr/lib/java GERONIMO_BUILD: 1.0-169186 VERBOSE_LEVEL: quiet (use -verbose to change) SERVER STARTING.. Now listening on: Port 1234: JMS Port 8080: HTTP Port 8081: HTTPS Port 9876: Foo SERVER STARTED SUCCESSFULLY! Browse to http://localhost:8080/ for web console -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-696) Too much info-level output during startup
[ http://issues.apache.org/jira/browse/GERONIMO-696?page=all ] Aaron Mulder resolved GERONIMO-696: --- Fix Version: 1.0-M4 Resolution: Fixed Might be nice to have a startup flag to alter the log level, but for now the feedback opposes tighter coupling between server startup class (Daemon) and logging configuration. Console log level is WARN and can be set lower be interested developers. An alternative would be to lower the Console log level and raise the server component package log levels. Another alternative would be to eliminate all DEBUG and INFO output from the server code we're not actively working on. Too much info-level output during startup - Key: GERONIMO-696 URL: http://issues.apache.org/jira/browse/GERONIMO-696 Project: Geronimo Type: Improvement Reporter: Erin Mulder Assignee: Aaron Mulder Fix For: 1.0-M4 During startup, too much unnecessary information is written to the console. Ideally, it should display a Server starting... message, followed by some sort of small progress indicator, followed by a Server started successfully! message. Only errors, severe warnings, or truly useful environment information should go in between. (A verbose switch could be added to allow developers to load the server with the current chatty log4j config.) For example: - bin/startup.sh Environment information: JDK_HOME: /usr/lib/java GERONIMO_BUILD: 1.0-169186 VERBOSE_LEVEL: quiet (use -verbose to change) SERVER STARTING.. Now listening on: Port 1234: JMS Port 8080: HTTP Port 8081: HTTPS Port 9876: Foo SERVER STARTED SUCCESSFULLY! Browse to http://localhost:8080/ for web console - -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-695) Need better progress feedback during startup sequence
[ http://issues.apache.org/jira/browse/GERONIMO-695?page=all ] Aaron Mulder resolved GERONIMO-695: --- Fix Version: 1.0-M4 Resolution: Fixed Now includes progress bar and status text by default. Can start the server with -noprogress to disable it. Need better progress feedback during startup sequence - Key: GERONIMO-695 URL: http://issues.apache.org/jira/browse/GERONIMO-695 Project: Geronimo Type: Improvement Reporter: Erin Mulder Assignee: Aaron Mulder Priority: Minor Fix For: 1.0-M4 When first launching the server, it's hard to tell when startup is complete. There are lots of pauses, and it's not clear whether there will eventually be a successful startup message. This adds a bit of uncertainty/confusion as you sit there and wonder whether it's done, still going or broken. (It would actually be quite cool/unique to add some sort of ascii progress bar like sftp and scp use.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [CONSENSUS?] Preparation for M4 -- branch early
On Mon, Jul 04, 2005 at 10:57:45PM -0400, Aaron Mulder wrote: I want to get the key generator changes in for M4. However, I'm currently blocked because I can't add the new module to TranQL. So I'd like to resolve that before the branch. Other than that, I'm fine to go ahead with the 24 hour notice. If we can nail that one quick that would be good. I remember you testing out your stuff quite heavily at JavaOne. I just noticed I have tranql commit, but would prefer Jeremy, Dain or Gianny look at your changes. Oh, I think we also have a problem where the currently running module list never gets saved. So you always get the default services when you start the server. I think I remember a conversation about how it was caused by some bad logic around our shutdown hooks. That needs to be resolved too. My gut says this seems like standard stabilization stuff that can happen in the branch. I'm sure other things will pop up as people test. Just my $0.02 -David
[jira] Commented: (GERONIMO-697) Need guidance for new users upon successful server startup
[ http://issues.apache.org/jira/browse/GERONIMO-697?page=comments#action_12315041 ] Aaron Mulder commented on GERONIMO-697: --- This will be particularly useful once we have a proper web console, or at least a default web app. Seems like it ought to wait for one of those. Need guidance for new users upon successful server startup -- Key: GERONIMO-697 URL: http://issues.apache.org/jira/browse/GERONIMO-697 Project: Geronimo Type: Improvement Reporter: Erin Mulder Priority: Minor There's no sense of what to do next when first launching the server. It would be nice to see something like Server started successfully! Visit the web console at http://localhost:8080/;. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: New Startup Output
OK, it's at: http://people.apache.org/~ammulder/new-startup-example.zip Unzip it, go to the geronimo-1.0-SNAPSHOT directory it creates, and run java -jar bin/server.jar. You have to run it from that dir because it starts Tomcat and I didn't have Jeff's latest fix in my tree. There are no changes for deployment, so having an app won't help (though the debug tool WAR is deployed by default). If you want to suppress the progress output, add -noprogress to the command line. Thanks, Aaron On Mon, 4 Jul 2005, David Blevins wrote: I think it would be a great custom to throw up an unstable build containing the feature you want people to try out when asking for feedback. Could you do that and also post an app we can try out (maybe to your space on people.apache.org)? -David On Mon, Jul 04, 2005 at 10:05:29PM -0400, Aaron Mulder wrote: I just put in a change with nicer startup console output. It gives some progress and status information during the server start process and lists the apps deployed and ports used at the end of the startup. Since it uses \r characters to make it work, the output looks lousy if you view it in a log file, so there's a -noprogress argument you can add to the server command line to suppress it (which the Maven deploy tool does, for example). In any case, I'd appreciate any thoughts or feedback on the new look. * Jeremy's already suggested adding a middle ground between -noprogress and what's in there, where it would print more or less the same information but one message per line so it looks nicer in a log. There's just an interface to implement to get the startup sequence calls, so it should be easy enough to support that. * David J recommended the current combination of a short progress bar and status messages instead of my initial attempt, which just had a long (but not very fine-grained) progress bar. I like the way it came out. Now that I've done this, I think we can use the same technique to hide the password on the deployer command line. Thanks, Aaron Log message --- New server startup output - shows a progress bar, timer, and operation status during start - shows a list of started application modules (other than o/a/g/System*) - shows a list of network ports that GBeans tried to bind to The port list is voluntary on behalf of the GBeans. They must declare an attribute of type java.net.InetSocketAddress in order to be included in the list (though it can be a read-only attribute). We should review the current GBeans and make sure they do. There is also some logic around calculating the name of a service. For example, if the same GBean has more than one InetSocketAddress attribute, it tries to add the name of each attribute in the port list, and if the GBean has a name attribute (for GBeans tht may be deployed more than once with different names) it includes that too. The new progress bar does not render particularly well in log files, and can be disabled by passing -noprogress on the server command line. The maven deployment plugin does that.
want to contribute with web or EJB please assign me !!!!!
Dear geronimoer I am new to geronimo so i would like to help either with web, webservices or EJB I would be grateful with senior developer that is leading this module to assign me inside their modules many thanks Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com
Re: Clustering (long)
Dain Sundstrom wrote: This is cool stuff and an excellent intro to your code (you should put this summary on your website :) I suggest you start chatting with OpenEJB and ActiveMQ about a shared session key sooner rather then later as it could take a wile to get it into their code bases. I'm just hammering out the portlet specs requirements with David, Jeff, Greg and Jan, then I will get back to the other teams. Jules I can't wait to see this stuff integrated, -dain On Jun 30, 2005, at 2:31 PM, Jules Gosnell wrote: Guys, I thought that it was high time that I brought you up to date with my efforts in building a clustering layer for Geronimo. The project, wadi.codehaus.org, started as an effort to build a scalable clustered HttpSession implementation, but in doing this, I have built components that should be useful in clustering the state held in any tier of Geronimo e.g. OpenEJB SFSBs etc. WADI (Web Application Distribution Infrastructure) has two main elements - the vertical and the horizontal. Vertically, WADI comprises a stack of pluggable stores. Each store has a pluggable Evicter responsible for demoting aging Sessions downwards. Requests arriving at the container are fed into the top of the stack and progress downwards, until their corresponding Session is found and promoted to the top, where the request is correctly rendered in its presence. Typically the top-level store is in Memory. Aging Sessions are demoted downwards onto exclusively owned LocalDisc. The bottom-most store is a database shared between all nodes in the Cluster. The first node joining the Cluster promotes all Sessions from the database into exclusively-owned store - e.g. LocalDisc. The last node to leave the Cluster demotes all Sessions down back into the database. Horizontally, all nodes in a WADI Cluster are connected (p2p) via a Clustered Store component within this stack. This typically sits at the boundary between exclusive and shared Stores. As requests fall through the stack, looking for their corresponding Session they arrive at the Clustered store, where, if the Session is present anywhere in the Cluster, its location may be learnt. At this point, the Session may be migrated in, underneath the incoming request, or, if its current location is considered advantageous, the request may be proxied or redirected to its remote location. As a node leaves the Cluster, all its Sessions are evacuated to other nodes via this store, so that they may continue to be actively maintained. The space in which Session ids are allocated is divided into a fixed number of Buckets. This number should be large enough such that management of the Buckets may be divided between all nodes in the Cluster roughly evenly. As nodes leave and join the Cluster, a single node, the Coordinator, is responsible for re-Bucketing the Cluster - i.e. reorganising who manages which Buckets and ensuring the safe transfer of the minimum number of Buckets to implement the new layout. The Coordinator is elected via a Pluggable policy. If the Coordinator leaves or fails, a new one is elected. If a node leaves or joins, buckets emigrate from it or immigrate into it, under the control of the Coordinator, to/from the rest of the Cluster. A Session may be efficiently mapped to a Bucket by simply %-ing its ID's hashcode() by the number of Buckets in the Cluster. A Bucket is a map of SessionID:Location, kept up to date with the Location of every Session in the Cluster, of which the id falls into its space. i.e. as Sessions are created, destroyed or moved around the Cluster notifications are sent to the node managing the relevant Bucket, informing it of the change. In this way, if a node receives a request for a Session which it does not own locally, it may pass a message to it, in a maximum of typically two hops, by sending the message to the Bucket owner, who then does a local lookup of the Sessions actual location and forwards the message to it. If Session and Bucket can be colocated, this can reduced to a single hop. Thus, WADI provides a fixed and scalable substrate over the more fluid arrangement that Cluster membership comprises, on top of which further Clustered services may be built. The above functionality exists in WADI CVS and I am currently working on hardening it to the point that I would consider it production strength. I will then consider the addition of some form of state replication, so that, even with the catastrophic failure of a member node, no state is lost from the Cluster. I plan to begin integrating WADI with Geronimo as soon as a certified 1.0-based release starts to settle down. Certification is the most immediate goal and clustering is not really part of the spec, so I think it best to satisfy the first before starting on subsequent goals. Further down the road we need to consider the unification of session id spaces used by e.g. the web and ejb tiers and introduction of an ApplicationSession abstraction - an
Re: [CONSENSUS?] Preparation for M4 -- branch early
I'm not a big fan of performing development on a branch that, IMO, should be frozen for QA. I'm not sure if that's what people are proposing but, I just wanted to say that. Regards, Alan On 7/4/2005 7:46 PM, David Blevins wrote: Do we have a consensus that we should branch at the beginning of the release cycle instead of at the end as we have done in the past? If so, going to put out an email titled M4 - 24 hour notice of branch, which I think would be a good release practice. -David On Mon, Jul 04, 2005 at 07:15:34PM -0700, David Blevins wrote: On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote: David Blevins wrote: On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote: David Blevins wrote: Anything I missed? SNAPSHOT elimination so the build is reproducible. Right. Missed that one for M3 IIRC. Branch so that M4 can stabilize whilst other changes are being made. We do for every milestone. Don't expect this to be different. Acceptance test process - how do we know what works (need to avoid a broken release like M3). That's what I meant by: DB We have a number of people interested in testing. I'll ping DB them when I have something ready. Was thinking to branch when I dish out the binaries for testing. Rather than the surprise, here is a binary approach we've done in the past. Sounds pretty much like what you are proposing as well. Yes - in the past we've just tagged and moved on. This time I think we should create the branch at the start of the process rather than at the end as there seem to be a lot of pent up changes planned. Yes, we may need to merge some critical changes back to this branch but hopefully this can be kept to a minimum. So basically, * create a branch now, say 1.0-M4-prep * do the stuff we talking about now on that branch * cut the final M4 distro * drop the 1.0-M4-prep branch Other work can continue on the trunk without destablizing the M4 release. +1 That's pretty much what I had in mind. -David
Re: Startup Scripts discussion ( GERONIMO-693 )
On Tue, Jul 05, 2005 at 12:27:58PM +1100, [EMAIL PROTECTED] wrote: The startup script should have the following on the first line to instruct the system which shell interpreter we are using. #! /bin/sh Some systems allow whitespace between bang and slash, some don't, so you'll be more portable if you use #!/bin/sh. OTOH the ones that don't probably don't have JRE's ;)
Re: Startup Scripts discussion ( GERONIMO-693 )
David Blevins [EMAIL PROTECTED] wrote on 05/07/2005 12:54:29 PM: On Mon, Jul 04, 2005 at 06:48:21PM -0700, Jeremy Boynes wrote: [EMAIL PROTECTED] wrote: toby cabot [EMAIL PROTECTED] wrote on 05/07/2005 12:59:14 AM: I like the idea of using a well-known baseline for the Geronimo scripts, but could we call the shell script geronimo instead of geronimo.sh? I prefer to not expose the implementation (shell script) in the interface. Are you concerned that we may change shells in the future? The startup script should have the following on the first line toinstruct the system which shell interpreter we are using. #! /bin/sh Not every version of Unix places the shell in the same place which can make this problematic. #!/bin/sh should work for most, /provided to stick to sh/ and don't use ksh or bash extensions (just in case you happen to get a genuine sh implementation). So is anyone not ok with specifying #!/bin/sh ? If someone is on an obscure platform where this doesn't work, then they can set up a link or edit the script. AFAIK if we ensure that the scripts only use original Bourne shell (sh) functionality then they should be compatible with other shells that may be linked to bin/sh such as ksh and bash, as they implement the Bourne shell environment. Does that sound right? If so, I will include some comments in the script so that people who edit it in the future are less likely to break it. John Right. And just an reminder, Linux and OSX don't actually have sh on the machine, it's just bash symlinked (linux) or copied (osx). Something to remember when testing the script. -David This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
