Pending Fixes
I have changes ready for the following JIRA's. However, I just got off the plane and I'm super-tired, so I'll check them in tomorrow. 1128 -- FIXED Derby log viewer 1207 -- FIXED Start to be recursive 1225 -- PATCH APPLIED console paths 1272 -- PATCH APPLIED show name of connector 1274 -- FIXED 886 -- CANNOT REPRODUCE Thanks, Aaron
[jira] Commented: (GERONIMO-1207) Dependency / Lifecycle Woes
[ http://issues.apache.org/jira/browse/GERONIMO-1207?page=comments#action_12359716 ] David Jencks commented on GERONIMO-1207: I don't entirely understand what is going on here, but I'm OK with the console, when you ask it to start a configuration, starting all the parent configurations recursively. This is what the Daemon does on startup. I am -10 on this recursive start behavior of configurations moving into the configuration manager or anything in the kernel. This would irretrevably break proper deployment. Dependency / Lifecycle Woes --- Key: GERONIMO-1207 URL: http://issues.apache.org/jira/browse/GERONIMO-1207 Project: Geronimo Type: Bug Components: kernel, console Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: 1.0 1) Create a database pool 2) Create a SQL security realm with the database pool as a parent 3) Verify that both are in the running state 4) Stop the database pool 5) Verify that both are in the stopped state 6) Using the console System Modules, start the security realm -- produces all kinds of exceptions 7) Now security realm is in the starting state, database pool is stopped 8) Starting the database pool does not get the security realm out of the starting state, though if you're bold with URL hacking you can start it again and it will start. I think that step 6 should either start both modules or leave both in the stopped state. Being stuck in the starting state is terrible -- at least if it won't automatically recover to the running state when the missing dependencies come online. Here's the stack traces from step 6. javax.portlet.PortletException: Configuration not found at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.processAction(ConfigManagerPortlet.java:131) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at
Re: Pending Fixes
On Dec 8, 2005, at 12:29 AM, Aaron Mulder wrote: I have changes ready for the following JIRA's. However, I just got off the plane and I'm super-tired, so I'll check them in tomorrow. 1128 -- FIXED Derby log viewer 1207 -- FIXED Start to be recursive As I commented in the jira, I'm fine with the console starting things recursively but cannot emphasize strongly enough how much I don't want the kernel/configuration manager behavior to change. thanks david jencks 1225 -- PATCH APPLIED console paths 1272 -- PATCH APPLIED show name of connector 1274 -- FIXED 886 -- CANNOT REPRODUCE Thanks, Aaron
[jira] Created: (GERONIMO-1312) app client builder uses config-store in a way inconsistent with the packaging plugin
app client builder uses config-store in a way inconsistent with the packaging plugin Key: GERONIMO-1312 URL: http://issues.apache.org/jira/browse/GERONIMO-1312 Project: Geronimo Type: Bug Components: deployment Versions: 1.0 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.0 the app client builder calls install on the config-store it knows about. However, the config store the packaging plugin uses is read-only. Thus it is currently impossible to deploy an app client using the packagin plugin. This is a problem for e.g. daytrader. -- 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
Branch for 1.0 Created - T-minus 2 days till ApacheCon begins
All, Tonight we created the 1.0 branch for Geronimo. At this point its time to focus on the fit and finish pieces. It s a bit late so I'll write up a better status and remaining items note tomorrow. The activities to start removing the dead links in the console can be done at this point. Please limit activity to fixing the release. I expect we'll be adding a few samples and other minor function (like the reworked debug console). However, new function like the inter-galactic data replicator and transformation engine might want to wait till 1.1. Thanks for all the help so far and only a few short days to ApacheCon. Here are some of the fit and finish that needs to be completed: Review of Documentation Test Console Checkout Test Samples Test I'll be back online tomorrow sometime. Matt
[jira] Closed: (GBUILD-1) Log the exit code and build output on failed results coming from agents
[ http://issues.apache.org/jira/browse/GBUILD-1?page=all ] David Blevins closed GBUILD-1: -- Resolution: Fixed Assign To: David Blevins Log the exit code and build output on failed results coming from agents --- Key: GBUILD-1 URL: http://issues.apache.org/jira/browse/GBUILD-1 Project: GBuild Type: Improvement Components: agent Reporter: David Blevins Assignee: David Blevins If a build fails for an agent, at the very least the results agent should note that in the logs. The build output should also be written somewhere so it is not lost. -- 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: Java Adventure Builder Reference 1.0.3 webapp deployed
Hi Jacek The status for my endeavour on the adventure builder: I have (only locally) plans that enable all the ear files to deploy. [*Q1] Would you like me to send you the plans I have developed - I guess the repository would be better off with these than with the ones currently there. I have had to replace a few parentId's from e.g. org/apache/geronimo/SystemDatabase to geronimo/system-database/1.0-SNAPSHOT/car. It seems to be the case that for the 1.0-SNAPSHOT builds I am able to produce, all internal configurations follow the car naming style rather than the org/apache/geronimo-naming style. The 1.0-M5 build I downloaded follow the org/apache/geronimo-naming style. I guess we will have to get the application running on a build resembling M5. [*Q2] Is there an easy way to make the maven script in sandbox/adventurebuilder use the M5-build. I tried changing geronimo_version in src/etc/project.properties to 1.0-M5, but that doesn't seem to do the trick. The server starts and afterwards and a superficial poke around the consumer web site seems to have it working all right. All the configurations corresponding to ear's in the application are in state running. Nevertheless, when starting the server, none of the web service endpoint beans are able to start. As an example, for the CreditCardEndpointBean the following appears in the log: 13:06:11,032 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null because no targets are running for reference WebServiceContainer matching the patterns geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Jetty,J2EEServer=geronimo,j2eeType=GBean,name=JettyWebContainer and then at the end of the startup: 13:06:26,725 WARN [SilentStartupMonitor] Unable to start geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null (starting) I guess this means that the bean didn't start ;-) It doesn't answer on the address (http://localhost:8080/webservice/CreditCardService) specified in the deployment descriptor. [*Q3] Have you got any ideas on how to make the beans start? I notice the J2EEModule=org/apache/geronimo/Jetty in the reference matching string in the first log entry. The jetty configuration reported by deployer.jar's list-modules is named geronimo/jetty/1.0-SNAPSHOT/car. Could this be related to Q2 on how to get to run on a server with org/apache/geronimo-naming style for configurations? Kindly, Jakob
Re: Contributors permission in JIRA
Dain, Please add the Jira users jeppe and ahj to the geronimo- contributor list. They are both working with me here at Trifork on the ORB contribution. Kresten Krab Thorup [EMAIL PROTECTED] On Oct 28, 2005, at 8:11 PM, Dain Sundstrom wrote: I'd like to create a geronimo-contributors group in jira. We would give contributors permission to assign, move, and resolve issues but not close them. This will let the committers know what everyone is working on, and will hopefully help those working on earning commit get used to JIRA. What do you think? -dain smime.p7s Description: S/MIME cryptographic signature
RE: Java Adventure Builder Reference 1.0.3 webapp deployed
Hi, I have successfully deployed Java Adventure Builder Reference 1.0.1 application on Geronimo and purchase order order tracking is working. But I have made few changes to the EJB classes due to automatic-key generation for unknown primary key field issue that I have faced. Instead of automatically generating the key I have generated the key in the Bean class itself using the random key generator and the issue has been fixed time being. The EJB's that I have modified are (1) ActivityDetailsBean (2) AddressBean (3) ContactInfoBean (4) LodgingBean (5) CreditCardBean (6) TransportationBean (7) ActivityBean Herewith I have attached the latest plans without using automatic primary key generation. EAR Plans: (1) ActivitySupplier Plan ?xml version=1.0 encoding=UTF-8? openejb-jar configId= xmlns=http://www.openejb.org/xml/ns/openejb-jar; xmlns:naming=http://geronimo.apache.org/xml/ns/naming; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment; cmp-connection-factory resource-linkMysqlDataSource/resource-link /cmp-connection-factory enterprise-beans entity ejb-nameActivityPurchaseOrderBean/ejb-name jndi-namecom.sun.j2ee.blueprints.activitysupplier.purchaseorder.ejb.ActivityPurchaseOrderLocalHome/jndi-name table-nameActivityPurchaseOrder/table-name cmp-field-mapping cmp-field-namepoId/cmp-field-name table-columnpoId/table-column /cmp-field-mapping ejb-local-ref ref-nameejb/local/activitysupplier/ActivityDetails/ref-name nameActivityDetailsBean/name /ejb-local-ref resource-ref ref-namejdbc/adventure/AdventureDB/ref-name resource-linkMysqlDataSource/resource-link /resource-ref /entity entity ejb-nameActivityDetailsBean/ejb-name jndi-namecom.sun.j2ee.blueprints.activitysupplier.purchaseorder.ejb.ActivityDetailsLocalHome/jndi-name table-nameActivityDetails/table-name cmp-field-mapping cmp-field-nameactivityId/cmp-field-name table-columnactivityId/table-column /cmp-field-mapping cmp-field-mapping cmp-field-namestartDate/cmp-field-name table-columnstartDate/table-column /cmp-field-mapping cmp-field-mapping cmp-field-nameendDate/cmp-field-name table-columnendDate/table-column /cmp-field-mapping cmp-field-mapping cmp-field-nameheadCount/cmp-field-name table-columnheadCount/table-column /cmp-field-mapping cmp-field-mapping cmp-field-nameactivityDetailsBean_upk/cmp-field-name table-columnActivityDetailsBean_upk/table-column /cmp-field-mapping resource-ref ref-namejdbc/adventure/AdventureDB/ref-name resource-linkMysqlDataSource/resource-link /resource-ref /entity session ejb-nameActivityPOEndpointBean/ejb-name jndi-nameActivityPOEndpointBean/jndi-name resource-ref ref-namejms/activity/QueueConnectionFactory/ref-name resource-linkJmsXA/resource-link /resource-ref web-service-addresshttp://localhost:8080/webservice/ActivityPOService/web-service-address /session message-driven ejb-nameActivityMessageEJB/ejb-name resource-adapter resource-linkActiveMQ AdventureBuilder/resource-link /resource-adapter /message-driven /enterprise-beans relationships ejb-relation ejb-relation-nameActivityRelations/ejb-relation-name ejb-relationship-role ejb-relationship-role-nameActivityPurchaseOrderBean/ejb-relationship-role-name relationship-role-source ejb-nameActivityPurchaseOrderBean/ejb-name /relationship-role-source cmr-field cmr-field-nameactivities/cmr-field-name /cmr-field role-mapping cmr-field-mapping key-columnpoId/key-column foreign-key-columnActivityPurchaseOrderBean_activities/foreign-key-column /cmr-field-mapping /role-mapping /ejb-relationship-role /ejb-relation /relationships /openejb-jar (2) AirlineSupplier Plan ?xml version=1.0 encoding=UTF-8? openejb-jar configId= xmlns=http://www.openejb.org/xml/ns/openejb-jar; xmlns:naming=http://geronimo.apache.org/xml/ns/naming; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment; cmp-connection-factory resource-linkMysqlDataSource/resource-link /cmp-connection-factory
Re: Geronimo Web Design - New Versions Updated From Feedback
terriffic work! +1 for v1. /Bharath
Re: [M1] Plugin hell, help desperately needed - JIRA 1308 created
David Blevins wrote: Just as an fyi, this is a nice addition but doesn't really deal with the Plugin hell issue David is talking about. It seems to be hit and miss trying to get the new plugins installed and used during any particular maven run. From my experience it seems as if you delete your ~/.maven/cache and ~/.maven/plugins, then the cache gets rebuilt and the latest verision of the plugin from your ~/.maven/repository is used. But as the plugin is updated in the future, it will never reach the ~/.maven/ cache and builds will eventually start failing because of it. There is more too it than that, David highlighted the frustrations around the problem a bit better in his email. Indeed, there's a lot of indeterministic behaviour in the build process. It's interesting that some are able to successfully build the server w/o the two patches submitted by Donald. That's exceedingly odd and perhaps related to plugin hell? Bill
Re: Java Adventure Builder Reference 1.0.3 webapp deployed
Jakob Færch (Trifork) wrote: Nevertheless, when starting the server, none of the web service endpoint beans are able to start. As an example, for the CreditCardEndpointBean the following appears in the log: 13:06:11,032 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null because no targets are running for reference WebServiceContainer matching the patterns geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Jetty,J2EEServer=geronimo,j2eeType=GBean,name=JettyWebContainer and then at the end of the startup: 13:06:26,725 WARN [SilentStartupMonitor] Unable to start geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null (starting) I guess this means that the bean didn't start ;-) It doesn't answer on the address (http://localhost:8080/webservice/CreditCardService) specified in the deployment descriptor. [*Q3] Have you got any ideas on how to make the beans start? I notice the J2EEModule=org/apache/geronimo/Jetty in the reference matching string in the first log entry. The jetty configuration reported by deployer.jar's list-modules is named geronimo/jetty/1.0-SNAPSHOT/car. Could this be related to Q2 on how to get to run on a server with org/apache/geronimo-naming style for configurations? The issue seems very similar to the problem Jacek faced in http://www.nabble.com/WARN-SilentStartupMonitor-Unable-to-start-...-%28starting%29-t515844.html#a1395857 But I am not able to figure out the connection; the reference for WebServiceContainer must be defined in some GBean - there's no such reference in the ear plan I'm trying to deploy (unless it's some default reference from any ear that includes a web service exposed EJB). I've been trying to get the deployer scripts to use my M5 build, but am running into all sorts of maven problems. I will continue to try later today. Kindly, Jakob
Re: VOTE: release our specs at version 1.0 now
+1 go for it On Dec 5, 2005, at 1:31 PM, David Jencks wrote: Lets build version 1.0 of our specs right now, get them in an accessible repo, use them for the tck, and when it passes push them to m1 and m2 non-snapshot repos. We will make a best-effort attempt to have m1 groupIds of org.apache.geronimo.specs but if this causes too many build/tck problems will resort to geronimo- specs. m2 groupId will be o.a.g.specs in any case. [ ] go for it [ ] don't care [ ] no, because. thanks david jencks -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [VOTE] Sponsor OpenEJB to become sub-project of Geronimo
with whom? Sun? On Dec 5, 2005, at 2:09 PM, David Blevins wrote: We'd still like to have them, obviously. I'm optimistic something could be worked out. -David On Dec 4, 2005, at 8:21 PM, Geir Magnusson Jr. wrote: I'm for this, but quick question - what would you do with the standalone server distros? IIRC, you can't distribute anything called EJB outside of the full tested container stack as per the spec license... geir On Dec 3, 2005, at 2:00 AM, David Blevins wrote: The OpenEJB committers have discussed it and voted to be become a Geronimo sub-project. The incubator proposl is here: http://wiki.apache.org/incubator/OpenEjbProposal Please vote if you'd like Geronimo to be the sponsor of OpenEJB during incubation [ ] +1 = I support the move to sponsor OpenEJB during incubation as a sub-project of Geronimo [ ] +0 = I don't mind either way [ ] -1 = I don't support this move because: ___ +1 from me -- David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo Web Site Design
nice! On Dec 6, 2005, at 6:01 PM, Epiq Geronimo Team wrote: We have been working on possible web site designs and would like to obtain the feedback of the community. Here are five different design types: http://www.epiqtech.com/corp/products/technology/opensource/ apachegeronimoweb.htm Each of these designs contains distinct elements (bar or tab primary navigation, header design, left nav bar type, secondary navigation type). Based on the feedback from the community, we can use colors, design options, or items that are good from one design in order to create a more refined design based on community feedback. Best regards, Epiq Team -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [Vote] 1.0 Branch for Geronimo at Noon EST on 12/7
man, that's short notice... I'm happy to see the branch, but in general, that's way too short.. On Dec 6, 2005, at 11:41 PM, Matt Hogstrom wrote: I'd like to get a concensus on branching an official V1.0 branch on Wednesday at noon. It looks like most features are done and we need to actively fix (remove) things to get 1.0 out the door. [ ] +1 Branch at noon [ ] -1 Don't branch (must provide proposed alternative) -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [Vote] Alternate Proposal for Branch V1.0 for Geronimo at 23:59 PST 12/7
isn't that still less than 24 hours? :) On Dec 7, 2005, at 1:04 AM, Matt Hogstrom wrote: One more time. Based on wildly popular feedback. Here is an alternate branching proposal. [ ] +1 Branch V1.0 at 23:59 PST 12/7 [ ] -1 Defer branching provide proposed alternative Matt -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Geronimo BOF at ApacheCon : Tuesday, Dec 13, 2005 - 8:30pm
We have a BOF slot at ApacheCon 2005. We have 60 minutes, so I'd like to see if we can pre-plan what we do and structure it a bit. Aaron was interested in presenting something, and I'm sure others are as well. So maybe we do something like 2-3 10 minute slots for formal presentations. I'd really like to try doing Geronimo Lightning Talks. It would work like this : 1) Anyone interested in speaking for 5 (five) minutes on any topic related to Geronimo, serious or funny, technical or not, will put their name on a slip of paper into a hat. I'll bring a hat. 2) We choose names at random from the hat, and when your name is called, you have 5 minutes to talk, including the time to get to the front. 3) At the 5 minute mark, you will leave the front or be manhandled off stage by our documentation goons. You can do this in pairs. Humor is appreciated. Any topic is welcome, but please have some [tenuous] relationship to Geronimo. If you aren't used to talking in public, this is a great chance to try it. It's only for 5 minutes, it gets people a chance to know you and what you are doing, and it really is an informal, fun setting... Thoughts? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Updated: (GERONIMO-1164) Java Adventure Builder Reference application deployment
[ http://issues.apache.org/jira/browse/GERONIMO-1164?page=all ] Jacek Laskowski updated GERONIMO-1164: -- Component: sample apps Java Adventure Builder Reference application deployment --- Key: GERONIMO-1164 URL: http://issues.apache.org/jira/browse/GERONIMO-1164 Project: Geronimo Type: Task Components: sample apps Reporter: Jacek Laskowski Assignee: Jacek Laskowski Fix For: 1.0 It's finally the time to see Java Adventure Builder Reference application running in Geronimo. This task is to track the progress. Instruction available at http://wiki.apache.org/geronimo/AdventureBuilder This is a sample application brought to you by the Java BluePrints program at Sun Microsystems, Inc. This sample application demonstrates how to use the capabilities of the J2EE 1.4 platform to develop robust, scalable, portable, and maintainable e-business applications and Webservices. It comes with full source code and documentation, so you can experiment with the J2EE technologies and learn how to use them effectively to build your own enterprise solutions. This application also showcases how to use the Webservices technologies in the J2EE 1.4 platform. This version of Adventure Builder Reference application is certified by Application Verification Kit(AVK) for the portablity across J2EE compatible application servers. -- 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: Java Adventure Builder Reference 1.0.3 webapp deployed
Jakob Færch (Trifork) wrote: Hi Jacek Hi Jakob, The status for my endeavour on the adventure builder: I have (only locally) plans that enable all the ear files to deploy. Awesome! You're making an excellent progress with it! [*Q1] Would you like me to send you the plans I have developed - I guess the repository would be better off with these than with the ones currently there. Send them to the list or better yet attach to the JIRA issue - http://issues.apache.org/jira/browse/GERONIMO-1164. Both will work fine. I have had to replace a few parentId's from e.g. org/apache/geronimo/SystemDatabase to geronimo/system-database/1.0-SNAPSHOT/car. Yes, the changes are already in the repo ;) It seems to be the case that for the 1.0-SNAPSHOT builds I am able to produce, all internal configurations follow the car naming style rather than the org/apache/geronimo-naming style. The 1.0-M5 build I downloaded follow the org/apache/geronimo-naming style. I guess we will have to get the application running on a build resembling M5. Nope. The work is being done on the recent development builds. Of course you might work on the past releases, but since the application is still in the sandbox I wouldn't bother to support too much versions and keep it up-to-date. It makes it easier to promote the sample apps to the main build rather than keep it in the sandbox. [*Q2] Is there an easy way to make the maven script in sandbox/adventurebuilder use the M5-build. I tried changing geronimo_version in src/etc/project.properties to 1.0-M5, but that doesn't seem to do the trick. I haven't tried it and don't think I will. Sorry. Why do you stick with the M5 version? If you don't want to build Geronimo from the sources, please check out sandbox only (and etc) and work with it. Maven will download the necessary components. The server starts and afterwards and a superficial poke around the consumer web site seems to have it working all right. All the configurations corresponding to ear's in the application are in state running. No comments ;) Nevertheless, when starting the server, none of the web service endpoint beans are able to start. As an example, for the CreditCardEndpointBean the following appears in the log: 13:06:11,032 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null because no targets are running for reference WebServiceContainer matching the patterns geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Jetty,J2EEServer=geronimo,j2eeType=GBean,name=JettyWebContainer and then at the end of the startup: 13:06:26,725 WARN [SilentStartupMonitor] Unable to start geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null (starting) I guess this means that the bean didn't start ;-) It doesn't answer on the address (http://localhost:8080/webservice/CreditCardService) specified in the deployment descriptor. [*Q3] Have you got any ideas on how to make the beans start? I notice the J2EEModule=org/apache/geronimo/Jetty in the reference matching string in the first log entry. The jetty configuration reported by deployer.jar's list-modules is named geronimo/jetty/1.0-SNAPSHOT/car. Could this be related to Q2 on how to get to run on a server with org/apache/geronimo-naming style for configurations? I couldn't work on it yesterday, but will certainly tonight. I hope others on IRC will help me to understand and fix it once and for all. Keep the good work going! I'm really impressed with your progress. Jakob Jacek
Re: Branch for 1.0 Created - T-minus 2 days till ApacheCon begins
Matt Hogstrom wrote: Samples What are the Samples? Matt Jacek
Re: Java Adventure Builder Reference 1.0.3 webapp deployed
Selvaraj, Saraswathi (Cognizant) wrote: Hi, I have successfully deployed Java Adventure Builder Reference 1.0.1 application on Geronimo and purchase order order tracking is working. You're the man! I'm going to review the changes and apply them to the repo. Is there anything that's left before we announce that AB works on Apache Geronimo? Thanks! S.Saraswathi Jacek
Re: Geronimo BOF at ApacheCon : Tuesday, Dec 13, 2005 - 8:30pm
Just as an FYI, I believe Bruce and/or Jeff are doing a tutorial on Geronimo over the weekend, and I'm doing a talk on J2EE Development with Apache Geronimo on Wedensday morning. So it would be nice to focus the BOF on things other than basic installation and J2EE development. I could do a lightning talk on our experience with Portlets, or the Management API, or something like that. We could also spend some time brainstorming on features for the next release, perhaps. Aaron On 12/8/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: We have a BOF slot at ApacheCon 2005. We have 60 minutes, so I'd like to see if we can pre-plan what we do and structure it a bit. Aaron was interested in presenting something, and I'm sure others are as well. So maybe we do something like 2-3 10 minute slots for formal presentations. I'd really like to try doing Geronimo Lightning Talks. It would work like this : 1) Anyone interested in speaking for 5 (five) minutes on any topic related to Geronimo, serious or funny, technical or not, will put their name on a slip of paper into a hat. I'll bring a hat. 2) We choose names at random from the hat, and when your name is called, you have 5 minutes to talk, including the time to get to the front. 3) At the 5 minute mark, you will leave the front or be manhandled off stage by our documentation goons. You can do this in pairs. Humor is appreciated. Any topic is welcome, but please have some [tenuous] relationship to Geronimo. If you aren't used to talking in public, this is a great chance to try it. It's only for 5 minutes, it gets people a chance to know you and what you are doing, and it really is an informal, fun setting... Thoughts? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Created: (GERONIMO-1313) openejb builder listener attribute has bad object name
openejb builder listener attribute has bad object name
--
Key: GERONIMO-1313
URL: http://issues.apache.org/jira/browse/GERONIMO-1313
Project: Geronimo
Type: Bug
Versions: 1.0
Reporter: David Jencks
Assigned to: David Jencks
Fix For: 1.0, 1.1
currently has org/apache/geronimo/Jetty. Needs
geronimo/jettyortomcat/${pom.currentVersion}/car. Found by Jakob Færch
--
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] Commented: (GERONIMO-1207) Dependency / Lifecycle Woes
[ http://issues.apache.org/jira/browse/GERONIMO-1207?page=comments#action_12359740 ] David Jencks commented on GERONIMO-1207: Let me clarify/take that back. I want the methods currently in ConfigurationManager to work the way they do now unless there is a bug. Adding a new method to start a configuration+gbeans recursively would be ok. Sorry for getting overly excited. Dependency / Lifecycle Woes --- Key: GERONIMO-1207 URL: http://issues.apache.org/jira/browse/GERONIMO-1207 Project: Geronimo Type: Bug Components: kernel, console Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: 1.0 1) Create a database pool 2) Create a SQL security realm with the database pool as a parent 3) Verify that both are in the running state 4) Stop the database pool 5) Verify that both are in the stopped state 6) Using the console System Modules, start the security realm -- produces all kinds of exceptions 7) Now security realm is in the starting state, database pool is stopped 8) Starting the database pool does not get the security realm out of the starting state, though if you're bold with URL hacking you can start it again and it will start. I think that step 6 should either start both modules or leave both in the stopped state. Being stuck in the starting state is terrible -- at least if it won't automatically recover to the running state when the missing dependencies come online. Here's the stack traces from step 6. javax.portlet.PortletException: Configuration not found at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.processAction(ConfigManagerPortlet.java:131) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at
[jira] Commented: (GERONIMO-1313) openejb builder listener attribute has bad object name
[
http://issues.apache.org/jira/browse/GERONIMO-1313?page=comments#action_12359743
]
David Jencks commented on GERONIMO-1313:
fixed in head:
Sendingassemblies/j2ee-installer/src/var/config/config.xml
Sendingassemblies/j2ee-jetty-server/src/var/config/config.xml
Sendingassemblies/j2ee-tomcat-server/src/var/config/config.xml
Transmitting file data ...
Committed revision 355135.
openejb builder listener attribute has bad object name
--
Key: GERONIMO-1313
URL: http://issues.apache.org/jira/browse/GERONIMO-1313
Project: Geronimo
Type: Bug
Versions: 1.0
Reporter: David Jencks
Assignee: David Jencks
Fix For: 1.0, 1.1
currently has org/apache/geronimo/Jetty. Needs
geronimo/jettyortomcat/${pom.currentVersion}/car. Found by Jakob Færch
--
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: Java Adventure Builder Reference 1.0.3 webapp deployed
On Dec 8, 2005, at 6:45 AM, Jakob Færch (Trifork) wrote: Jakob Færch (Trifork) wrote: Nevertheless, when starting the server, none of the web service endpoint beans are able to start. As an example, for the CreditCardEndpointBean the following appears in the log: 13:06:11,032 DEBUG [GBeanSingleReference] Waiting to start geronimo.server: name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/ apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null because no targets are running for reference WebServiceContainer matching the patterns geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/ Jetty,J2EEServer=geronimo,j2eeType=GBean,name=JettyWebContainer and then at the end of the startup: 13:06:26,725 WARN [SilentStartupMonitor] Unable to start geronimo.server: name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/ apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null (starting) I guess this means that the bean didn't start ;-) It doesn't answer on the address (http://localhost:8080/webservice/CreditCardService) specified in the deployment descriptor. [*Q3] Have you got any ideas on how to make the beans start? I notice the J2EEModule=org/apache/geronimo/Jetty in the reference matching string in the first log entry. The jetty configuration reported by deployer.jar's list-modules is named geronimo/jetty/1.0-SNAPSHOT/car. This is a bug, I've opened GERONIMO-1313 to track it. I've fixed it in head, and will fix 1.0 shortly after I get it checked out. Could this be related to Q2 on how to get to run on a server with org/apache/geronimo-naming style for configurations? The issue seems very similar to the problem Jacek faced in http://www.nabble.com/WARN-SilentStartupMonitor-Unable-to-start-...- %28starting%29-t515844.html#a1395857 But I am not able to figure out the connection; the reference for WebServiceContainer must be defined in some GBean - there's no such reference in the ear plan I'm trying to deploy (unless it's some default reference from any ear that includes a web service exposed EJB). the reference is in listener in the openejb builder. This tells the openejb builder how to hook up ejb web services to a web container. thanks david jencks I've been trying to get the deployer scripts to use my M5 build, but am running into all sorts of maven problems. I will continue to try later today. Kindly, Jakob
[jira] Closed: (GERONIMO-1313) openejb builder listener attribute has bad object name
[ http://issues.apache.org/jira/browse/GERONIMO-1313?page=all ]
David Jencks closed GERONIMO-1313:
--
Resolution: Fixed
fixed in 1.0 branch
Sending1.0/assemblies/j2ee-installer/src/var/config/config.xml
Sending1.0/assemblies/j2ee-jetty-server/src/var/config/config.xml
Sending1.0/assemblies/j2ee-tomcat-server/src/var/config/config.xml
Transmitting file data ...
Committed revision 355162.
openejb builder listener attribute has bad object name
--
Key: GERONIMO-1313
URL: http://issues.apache.org/jira/browse/GERONIMO-1313
Project: Geronimo
Type: Bug
Versions: 1.0
Reporter: David Jencks
Assignee: David Jencks
Fix For: 1.0, 1.1
currently has org/apache/geronimo/Jetty. Needs
geronimo/jettyortomcat/${pom.currentVersion}/car. Found by Jakob Færch
--
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
[Vote] Installer: Default Web Container Selection
The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though. -- Regards, Erik
Re: [Vote] Installer: Default Web Container Selection
As much as I Looovvve Jetty...I have to vote for the work I did ;-) [ x ] Make Tomcat the default web container install selection Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
Re: [Vote] Installer: Default Web Container Selection
Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ X] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
Re: [Vote] Installer: Default Web Container Selection
Opps, click the wrong button. +1 for Jetty, it would be consistent with the previous default package. Cheers! Hernan Hernan Cunico wrote: Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ X] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
Re: Branch for 1.0 Created - T-minus 2 days till ApacheCon begins
Here are the current samples that I am aware of... - servlets-examples predeployed in geronimo - jsp-examples predeployed in geronimo Additional samples at: http://wiki.apache.org/geronimo/Samples http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Samples+for+Apache+Geronimo The second link also identifies additional samples that need some work. Jacek Laskowski wrote: Matt Hogstrom wrote: Samples What are the Samples? Matt Jacek
WADI integration
I see that WADI has recently been integrated into Geronimo. Great Job!!! Can someone please provide a quick high level description of what is/isn't available from WADI in Geronimo v1? Tomcat clustering Jetty clustering Load Balancing HttpSession failover -file based -database -mem to mem (one to all) -mem to mem (one to one/several) -distributed cache Sticky Session Cluster membership (manual, auto-discovery) Centralized/independent mgmt Deployment (independent, centralized, farming) Anything above Web Tier clustering? Thanks -Dave-
Re: [Vote] Installer: Default Web Container Selection
[ X ] Make Tomcat the default web container install selection On Thu, 2005-12-08 at 13:08 -0500, Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
Re: [Vote] Installer: Default Web Container Selection
[ x ] Make Jetty the default Web Container install selection cheers all Jan Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
Re: [Vote] Installer: Default Web Container Selection
Been waiting for this one... ;-) +1 for Tomcat. I think the decision should be based on what our users want and I've heard more interest expressed for Tomcat. --kevanOn 12/8/05, Erik Daughtrey [EMAIL PROTECTED] wrote: The installershould make either Tomcat or Jetty the default selection.Theoperator can always override and select the other.Vote:[] Make Jetty the default Web Container install selection[] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'mmaking the default Jetty unless someone can provide a good reason why itshouldn't be.FYI - it's been decided that installation of both web containers via the installer will not be allowed.Manual configuration of both is possiblethough.--Regards,Erik
Re: Java Adventure Builder Reference 1.0.3 webapp deployed
Jacek Laskowski wrote: [*Q1] Would you like me to send you the plans I have developed - I guess the repository would be better off with these than with the ones currently there. Send them to the list or better yet attach to the JIRA issue - http://issues.apache.org/jira/browse/GERONIMO-1164. Both will work fine. I've attached a zip to the JIRA issue. It seems to be the case that for the 1.0-SNAPSHOT builds I am able to produce, all internal configurations follow the car naming style rather than the org/apache/geronimo-naming style. The 1.0-M5 build I downloaded follow the org/apache/geronimo-naming style. I guess we will have to get the application running on a build resembling M5. Nope. The work is being done on the recent development builds. Of course you might work on the past releases, but since the application is still in the sandbox I wouldn't bother to support too much versions and keep it up-to-date. It makes it easier to promote the sample apps to the main build rather than keep it in the sandbox. [*Q2] Is there an easy way to make the maven script in sandbox/adventurebuilder use the M5-build. I tried changing geronimo_version in src/etc/project.properties to 1.0-M5, but that doesn't seem to do the trick. I haven't tried it and don't think I will. Sorry. Why do you stick with the M5 version? If you don't want to build Geronimo from the sources, please check out sandbox only (and etc) and work with it. Maven will download the necessary components. I guess I thought the org/apache/geronimo were the official names - if the snapshot builds are like the build we're going to support in the end, of course the right thing is to stick with those. Nevertheless, when starting the server, none of the web service endpoint beans are able to start. As an example, for the CreditCardEndpointBean the following appears in the log: 13:06:11,032 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null because no targets are running for reference WebServiceContainer matching the patterns geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Jetty,J2EEServer=geronimo,j2eeType=GBean,name=JettyWebContainer and then at the end of the startup: 13:06:26,725 WARN [SilentStartupMonitor] Unable to start geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null (starting) I guess this means that the bean didn't start ;-) It doesn't answer on the address (http://localhost:8080/webservice/CreditCardService) specified in the deployment descriptor. [*Q3] Have you got any ideas on how to make the beans start? I notice the J2EEModule=org/apache/geronimo/Jetty in the reference matching string in the first log entry. The jetty configuration reported by deployer.jar's list-modules is named geronimo/jetty/1.0-SNAPSHOT/car. Could this be related to Q2 on how to get to run on a server with org/apache/geronimo-naming style for configurations? I couldn't work on it yesterday, but will certainly tonight. I hope others on IRC will help me to understand and fix it once and for all. It seems wonderful that David Jencks already fixed the bug. I wasn't able to either build or get maven to download a fresh snapshot. On the build I'm using (an older homebrew version as far as I can tell), I'm getting an ArrayIndexOutOfBoundsException during deployment of OPC, it seems related to some repository lookup. The entire stacktrace in my JIRA comment. Maybe you would be able to get my files from the JIRA and give it at try? I'm afraid I won't be able to work on anything Geronimo until monday morning - but I'm looking forward to logging on and getting the status here. Kindly, Jakob
[jira] Updated: (GERONIMO-1164) Java Adventure Builder Reference application deployment
[ http://issues.apache.org/jira/browse/GERONIMO-1164?page=all ] Jakob Færch updated GERONIMO-1164: -- Attachment: adventurebuilder1.0.3-geronimo-deployment-plans.zip --- [echo] Distributing Adventure Builder OPC Application [java] 22:11:03,101 ERROR [Deployer] Deployment failed due to [java] java.lang.ArrayIndexOutOfBoundsException: 2 [java] at org.apache.geronimo.system.repository.ReadOnlyRepository.resolve(ReadOnlyRepository.java:81) [java] at org.apache.geronimo.system.repository.ReadOnlyRepository.hasURI(ReadOnlyRepository.java:59) [java] at org.apache.geronimo.system.repository.ReadOnlyRepository$$FastClassByCGLIB$$55049eb1.invoke(generate d) [java] at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) [java] at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) [java] at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) [java] at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) [java] at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) [java] at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) [java] at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) [java] at org.apache.geronimo.kernel.repository.Repository$$EnhancerByCGLIB$$43b06fc1.hasURI(generated) [java] at org.apache.geronimo.deployment.service.ServiceConfigBuilder.getDependencyURI(ServiceConfigBuilder.jav a:405) [java] at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies(ServiceConfigBuilder.java :280) [java] at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:323) [java] at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) [java] at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) [java] at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) [java] at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) [java] at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) [java] at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) [java] at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) [java] at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) [java] at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$4664809a.buildConfiguration(ge nerated) [java] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:178) [java] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:85) [java] at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) [java] at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) [java] at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) [java] at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) [java] at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) [java] at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) [java] at org.apache.geronimo.deployment.cli.ServerConnection$KernelWrapper.invoke(ServerConnection.java:363) [java] at org.apache.geronimo.deployment.cli.ServerConnection.invokeOfflineDeployer(ServerConnection.java:346) [java] at org.apache.geronimo.deployment.cli.CommandDistribute.executeOffline(CommandDistribute.java:123) [java] at org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:118) [java] at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:157) [java] at org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:311) [java] Error: Unable to connect to local deployer service [java] [java] org.apache.geronimo.common.DeploymentException: java.lang.ArrayIndexOutOfBoundsException: 2 [java] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:215) [java] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:85) [java] at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) [java] at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) [java] at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) [java] at
Re: [Vote] Installer: Default Web Container Selection
Erik Daughtrey wrote: [ X] Make Tomcat the default web container install selection As much as I love Jetty I love* Jeff, too, so how I could vote differently ;) [*] Don't get carried away, though, Jeff ;) Jacek
Re: [Vote] Installer: Default Web Container Selection
This is a good point... Its encouraged that the community vote here too. Although not binding, it should be taken into account. Jeff Kevan Miller wrote: Been waiting for this one... ;-) +1 for Tomcat. I think the decision should be based on what our users want and I've heard more interest expressed for Tomcat. --kevan On 12/8/05, Erik Daughtrey [EMAIL PROTECTED] wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though. -- Regards, Erik
RE: [Vote] Installer: Default Web Container Selection
[ ] Make Jetty the default Web Container install selection [ X ] Make Tomcat the default web container install selection My vote may not count, but I like Tomcat :) Regards, Rajith Attapattu. -Original Message- From: Jeff Genender [mailto:[EMAIL PROTECTED] Sent: Thursday, December 08, 2005 4:48 PM To: dev@geronimo.apache.org Subject: Re: [Vote] Installer: Default Web Container Selection This is a good point... Its encouraged that the community vote here too. Although not binding, it should be taken into account. Jeff Kevan Miller wrote: Been waiting for this one... ;-) +1 for Tomcat. I think the decision should be based on what our users want and I've heard more interest expressed for Tomcat. --kevan On 12/8/05, Erik Daughtrey [EMAIL PROTECTED] wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though. -- Regards, Erik
Re: Build errors
Sachin, Try regenerating the plugins. cd plugins/geronimo-assembly-plugin maven -o cd ../geronimo-izpack-plugin maven -o On Thursday 08 December 2005 15:54, Sachin Patel wrote: I'm constantly failing during this goal. Any ideas? izpack:izpack-installer-build: [echo] IZPack installer build is running. [echo] IZPack Version is 3.8.0 [java] [java] .:: IzPack - Version 3.8.0 ::. [java] [java] compiler specifications version : 1.0 [java] [java] - Copyright (C) 2001-2005 Julien Ponge [java] - Visit http://www.izforge.com/ for the latests releases [java] - Released under the terms of the Apache Software License version 2.0. [java] [java] - Processing : /Users/sppatel/geronimo/geronimo/assemblies/j2ee-installer/target/geronimo- 1 .0-SNAPSHOT/geronimo-izpac k.xml [java] - Output : /Users/sppatel/geronimo/geronimo/assemblies/j2ee-installer/target/geronimo- i nstaller-1.0-SNAPSHOT.jar [java] - Base path : . [java] - Kind: standard [java] - Compression : default [java] - Compr. level: -1 [java] [java] Adding resource: IzPack.uninstaller [java] Setting the installer information [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/l i b/liquidlnf.jar [java] Setting the GUI preferences [java] Adding langpack: eng [java] Adding resource: flag.eng [java] Adding resource: Installer.image [java] Adding resource: LicencePanel.licence [java] Adding resource: InfoPanel.info [java] Adding resource: userInputSpec.xml [java] Adding resource: ImgPacksPanel.img.0 [java] Adding resource: ImgPacksPanel.img.1 [java] Adding resource: ImgPacksPanel.img.2 [java] Adding resource: ImgPacksPanel.img.3 [java] Adding resource: ImgPacksPanel.img.4 [java] Adding resource: ImgPacksPanel.img.5 [java] Adding resource: ImgPacksPanel.img.6 [java] Adding resource: ImgPacksPanel.img.7 [java] Adding resource: ImgPacksPanel.img.8 [java] Adding resource: ImgPacksPanel.img.9 [java] Adding resource: ImgPacksPanel.img.10 [java] Adding resource: ImgPacksPanel.img.11 [java] Adding resource: ImgPacksPanel.img.12 [java] Adding resource: ImgPacksPanel.img.13 [java] Adding resource: ImgPacksPanel.img.14 [java] Adding resource: ImgPacksPanel.img.15 [java] Adding resource: ImgPacksPanel.img.16 [java] Adding resource: ImgPacksPanel.img.17 [java] Adding resource: ImgPacksPanel.img.18 [java] Adding resource: ImgPacksPanel.img.19 [java] Adding resource: ImgPacksPanel.img.20 [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/HelloPanel. jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/LicencePane l.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/TargetPanel .jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/ImgPacksPan el.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/InstallPane l.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/InfoPanel.j ar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/FinishPanel .jar [java] - Fatal error :
Re: [Vote] Installer: Default Web Container Selection
Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [X] Make Tomcat the default web container install selection Regards, Stefan Schmidt We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
Re: Build errors
That did it. thx. On 12/8/05 4:55 PM, Erik Daughtrey [EMAIL PROTECTED] wrote: Sachin, Try regenerating the plugins. cd plugins/geronimo-assembly-plugin maven -o cd ../geronimo-izpack-plugin maven -o On Thursday 08 December 2005 15:54, Sachin Patel wrote: I'm constantly failing during this goal. Any ideas? izpack:izpack-installer-build: [echo] IZPack installer build is running. [echo] IZPack Version is 3.8.0 [java] [java] .:: IzPack - Version 3.8.0 ::. [java] [java] compiler specifications version : 1.0 [java] [java] - Copyright (C) 2001-2005 Julien Ponge [java] - Visit http://www.izforge.com/ for the latests releases [java] - Released under the terms of the Apache Software License version 2.0. [java] [java] - Processing : /Users/sppatel/geronimo/geronimo/assemblies/j2ee-installer/target/geronimo- 1 .0-SNAPSHOT/geronimo-izpac k.xml [java] - Output : /Users/sppatel/geronimo/geronimo/assemblies/j2ee-installer/target/geronimo- i nstaller-1.0-SNAPSHOT.jar [java] - Base path : . [java] - Kind: standard [java] - Compression : default [java] - Compr. level: -1 [java] [java] Adding resource: IzPack.uninstaller [java] Setting the installer information [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/l i b/liquidlnf.jar [java] Setting the GUI preferences [java] Adding langpack: eng [java] Adding resource: flag.eng [java] Adding resource: Installer.image [java] Adding resource: LicencePanel.licence [java] Adding resource: InfoPanel.info [java] Adding resource: userInputSpec.xml [java] Adding resource: ImgPacksPanel.img.0 [java] Adding resource: ImgPacksPanel.img.1 [java] Adding resource: ImgPacksPanel.img.2 [java] Adding resource: ImgPacksPanel.img.3 [java] Adding resource: ImgPacksPanel.img.4 [java] Adding resource: ImgPacksPanel.img.5 [java] Adding resource: ImgPacksPanel.img.6 [java] Adding resource: ImgPacksPanel.img.7 [java] Adding resource: ImgPacksPanel.img.8 [java] Adding resource: ImgPacksPanel.img.9 [java] Adding resource: ImgPacksPanel.img.10 [java] Adding resource: ImgPacksPanel.img.11 [java] Adding resource: ImgPacksPanel.img.12 [java] Adding resource: ImgPacksPanel.img.13 [java] Adding resource: ImgPacksPanel.img.14 [java] Adding resource: ImgPacksPanel.img.15 [java] Adding resource: ImgPacksPanel.img.16 [java] Adding resource: ImgPacksPanel.img.17 [java] Adding resource: ImgPacksPanel.img.18 [java] Adding resource: ImgPacksPanel.img.19 [java] Adding resource: ImgPacksPanel.img.20 [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/HelloPanel. jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/LicencePane l.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/TargetPanel .jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/ImgPacksPan el.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/UserInputPa nel.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/InstallPane l.jar [java] Adding content of jar: file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/InfoPanel.j ar [java] Adding content of jar:
RE: [Vote] Installer: Default Web Container Selection
From a user's point of view, as long as I have a choice, I'm happy - but if my vote does count for anything, here is my vote. [X] Make Tomcat the default web container install selection - Chris -Original Message- From: Erik Daughtrey [mailto:[EMAIL PROTECTED] Sent: Thursday, December 08, 2005 10:08 AM To: dev@geronimo.apache.org Subject: [Vote] Installer: Default Web Container Selection The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though. -- Regards, Erik
Re: [Vote] Installer: Default Web Container Selection
[ ] Make Jetty the default Web Container install selection [X] Make Tomcat the default web container install selection Thanks Srinath Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [X] Make Tomcat the default web container install selection Regards, Stefan Schmidt We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
Re: [Vote] Installer: Default Web Container Selection
[ X ] Make Tomcat the default web container install selection ( Tomcat is the container that users in my environment prefer, probably not for technical reasons though ). Would be nice if in the future we could provide some feature and performance comparisons between the two to help users make an informed choice. John Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
Re: [Vote] Installer: Default Web Container Selection
[ x ] Make Jetty the default Web Container install selection Simon -- http://bordet.blogspot.com
Re: [Vote] Installer: Default Web Container Selection
Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ X ] Make Tomcat the default web container install selection (this is a user vote -- but this will fit well with tomcat clustering) Best regards, -- Cordialement, Ludo - http://www.ubik-products.com --- L'amour pour principe et l'ordre pour base; le progres pour but (A.Comte)
Re: [Vote] Installer: Default Web Container Selection
[x] Make Jetty the default Web Container install selection Jetty's been with us for two years. If it was my project, I'd be pretty disappointed to get dumped the day before the first supported release. Being an optional component is not exactly the thanks I would expect. -David On Dec 8, 2005, at 10:08 AM, Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though. -- Regards, Erik
Re: [Vote] Installer: Default Web Container Selection
[ x ] Make Jetty the default Web Container install selection Non binding, but I like Jetty. Besides, given how close to a release it is, it seems sensible to stick with it. - Brett
Re: [Vote] Installer: Default Web Container Selection
For 1.0, I'd like to see Jetty, reflecting the initial participation and work that the Jetty community did when we got started over two years ago. geir On Dec 8, 2005, at 1:08 PM, Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though. -- Regards, Erik -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Adding new dependencies to console in config/
The current console builds in config/ don't include enough ActiveMQ libraries on their class path. I can add the 2 ActiveMQ libraries as dependency elements in the console EAR deployment plans for console-tomcat and console-jetty, but that doesn't seem to be the way it's handled right now. Somehow now I think activemq-gbean-management is on the classpath, but activemq-core and activemq-gbean are not. So my question is, how is that being done? I didn't see the dependency plugin being used for the console, and when I grepped the config/ directories for activemq I didn't get any hits except in the CARs... so I'm just a little confused. Thanks, Aaron
Re: [Vote] Installer: Default Web Container Selection
On Thu, Dec 08, 2005 at 02:47:34PM -0700, Jeff Genender wrote: Its encouraged that the community vote here too. Although not binding, it should be taken into account. Thanks! [X] Make Jetty the default Web Container install selection Jetty's worked out well, let's keep going.
Build/test failure in Timer
Does anyone have any ideas? Thanks in advanced At revision 355260 in the geronimo 1.0 branch ... test:test: [junit] Running org.apache.geronimo.timer.jdbc.DerbyJDBCWorkerPersistenceTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 6.123 sec [junit] Running org.apache.geronimo.timer.TransactionalThreadPooledTimerTest[junit] Tests run: 10, Failures: 1, Errors: 0, Time elapsed: 25.556 sec [junit] [ERROR] TEST org.apache.geronimo.timer.TransactionalThreadPooledTimerTest FAILED [junit] Running org.apache.geronimo.timer.NontransactionalThreadPooledTimerTest [junit] Tests run: 10, Failures: 1, Errors: 0, Time elapsed: 25.313 sec [junit] [ERROR] TEST org.apache.geronimo.timer.NontransactionalThreadPooledTimerTest FAILED BUILD FAILED File.. /home/cchan/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jellyElement... maven:reactor Line.. 217 Column 9 Unable to obtain goal [default] -- /home/cchan/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly:181:54: fail There were test failures. Total time: 9 minutes 19 seconds 14:53:14,706 INFO [App] Total time: 9 minutes 19 seconds 14:53:14,706 INFO [App] Total time: 9 minutes 19 seconds Finished at: Thu Dec 08 14:53:14 PST 2005
[jira] Created: (GERONIMO-1314) Provide documentation that helps users make an informed decision as whether to use Tomcat or Jetty Web Container
Provide documentation that helps users make an informed decision as whether to use Tomcat or Jetty Web Container Key: GERONIMO-1314 URL: http://issues.apache.org/jira/browse/GERONIMO-1314 Project: Geronimo Type: Improvement Components: installer, Tomcat, web Versions: 1.0 Reporter: John Sisson Fix For: 1.1 Currently a lot of users probably choose to use Tomcat because it has had more visibility and there isn't much Geronimo documentation about Jetty and why they might want to use it. Ideas: A link to this page could possibly be presented in the installer where the users choose between Tomcat or Jetty. Provide information on the features of the containers and anything that differentiates one from the other. Provide links to GBean configuration documentation for each container. Provide information mapping Tomcat and Jetty concepts for users who are already famiiar with one of the containers - make it easy for them to migrate existing apps. -- 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-1314) Provide documentation that helps users make an informed decision as whether to use Tomcat or Jetty Web Container
[ http://issues.apache.org/jira/browse/GERONIMO-1314?page=all ] John Sisson updated GERONIMO-1314: -- Description: Currently a lot of users probably choose to use Tomcat because it has had more visibility and there isn't much Geronimo documentation about Jetty and why they might want to use it. Ideas: A link to a documentation page could possibly be presented in the installer where the users choose between Tomcat or Jetty. Can we provide help in the installer? Provide information on the features of the containers and anything that differentiates one from the other. Provide links to GBean configuration documentation for each container. Provide information mapping Tomcat and Jetty concepts for users who are already famiiar with one of the containers - make it easy for them to migrate existing apps. was: Currently a lot of users probably choose to use Tomcat because it has had more visibility and there isn't much Geronimo documentation about Jetty and why they might want to use it. Ideas: A link to this page could possibly be presented in the installer where the users choose between Tomcat or Jetty. Provide information on the features of the containers and anything that differentiates one from the other. Provide links to GBean configuration documentation for each container. Provide information mapping Tomcat and Jetty concepts for users who are already famiiar with one of the containers - make it easy for them to migrate existing apps. Provide documentation that helps users make an informed decision as whether to use Tomcat or Jetty Web Container Key: GERONIMO-1314 URL: http://issues.apache.org/jira/browse/GERONIMO-1314 Project: Geronimo Type: Improvement Components: installer, Tomcat, web Versions: 1.0 Reporter: John Sisson Fix For: 1.1 Currently a lot of users probably choose to use Tomcat because it has had more visibility and there isn't much Geronimo documentation about Jetty and why they might want to use it. Ideas: A link to a documentation page could possibly be presented in the installer where the users choose between Tomcat or Jetty. Can we provide help in the installer? Provide information on the features of the containers and anything that differentiates one from the other. Provide links to GBean configuration documentation for each container. Provide information mapping Tomcat and Jetty concepts for users who are already famiiar with one of the containers - make it easy for them to migrate existing apps. -- 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: Does there need to be a default web container?
+1 - I don't think we should make the decision for the user. It would be even better if the installer in a Choose Your Web Container page, provided a URL or link to a page on the Wiki that provided information that would help them make an informed decision. See related ideas in http://issues.apache.org/jira/browse/GERONIMO-1314 John Jeff Genender wrote: This is obviously a hot topic and I hope that as a Geronimo PMC and user community we are not forced to have to show preference of one over the other. There is obviously some personal preferences on both sides and we are a great open source project because we do not have to get behind one *or* the other. We can get behind them both. May I ask why the installer/wizard cannot have a page called Choose Your Web Container and have an option for Jetty and Tomcat, but neither selected? Does there need to be a default? Can we just let the end user choose? IMHO, I don't think we should provide a preference for one over the other. I really like both. I think we should give the user the choice without hinting a preference. Thoughts and comments? Jeff
Re: [Vote] Installer: Default Web Container Selection
+1 Tomcat On Dec 8, 2005, at 3:47 PM, Geir Magnusson Jr. wrote: For 1.0, I'd like to see Jetty, reflecting the initial participation and work that the Jetty community did when we got started over two years ago. geir On Dec 8, 2005, at 1:08 PM, Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though. -- Regards, Erik -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Does there need to be a default web container?
Also if one container is in some way better than another today, that may not be the case in the future. Once we have a default, it will be hard to change in the future. Not having a default also provides a fair playing field for those who are contributing to the project and encourages competition. Let the user decide. John Jeff Genender wrote: This is obviously a hot topic and I hope that as a Geronimo PMC and user community we are not forced to have to show preference of one over the other. There is obviously some personal preferences on both sides and we are a great open source project because we do not have to get behind one *or* the other. We can get behind them both. May I ask why the installer/wizard cannot have a page called Choose Your Web Container and have an option for Jetty and Tomcat, but neither selected? Does there need to be a default? Can we just let the end user choose? IMHO, I don't think we should provide a preference for one over the other. I really like both. I think we should give the user the choice without hinting a preference. Thoughts and comments? Jeff
Re: Does there need to be a default web container?
I hate to say it, but from a usability perspective, I think we need to have a default. Otherwise, when installing Geronimo, the first thing the user has to do is make a decision that most users really have no basis for making. Granted a Wiki link would help, but I think we need to provide a 0-decision install path where you can essentially just click through and something good will happen. At the end of the day, I wish we could avoid the politics, and I definitely don't think we need to present this as an official Geronimo preference. Any documentation referenced can start out by saying either one will work fine and we fully support both (and the TAR/ZIP download page should say the same). Still, I would really prefer to have a pre-selected default on the install screen when it comes up. Thanks, Aaron On 12/8/05, John Sisson [EMAIL PROTECTED] wrote: +1 - I don't think we should make the decision for the user. It would be even better if the installer in a Choose Your Web Container page, provided a URL or link to a page on the Wiki that provided information that would help them make an informed decision. See related ideas in http://issues.apache.org/jira/browse/GERONIMO-1314 John Jeff Genender wrote: This is obviously a hot topic and I hope that as a Geronimo PMC and user community we are not forced to have to show preference of one over the other. There is obviously some personal preferences on both sides and we are a great open source project because we do not have to get behind one *or* the other. We can get behind them both. May I ask why the installer/wizard cannot have a page called Choose Your Web Container and have an option for Jetty and Tomcat, but neither selected? Does there need to be a default? Can we just let the end user choose? IMHO, I don't think we should provide a preference for one over the other. I really like both. I think we should give the user the choice without hinting a preference. Thoughts and comments? Jeff
Re: Does there need to be a default web container?
I'd also prefer the choice too be left to the user +1 -bd- On Dec 8, 2005, at 4:30 PM, Jeff Genender wrote: This is obviously a hot topic and I hope that as a Geronimo PMC and user community we are not forced to have to show preference of one over the other. There is obviously some personal preferences on both sides and we are a great open source project because we do not have to get behind one *or* the other. We can get behind them both. May I ask why the installer/wizard cannot have a page called Choose Your Web Container and have an option for Jetty and Tomcat, but neither selected? Does there need to be a default? Can we just let the end user choose? IMHO, I don't think we should provide a preference for one over the other. I really like both. I think we should give the user the choice without hinting a preference. Thoughts and comments? Jeff
[jira] Updated: (GERONIMO-1128) Derby Log Viewer performance problem
[ http://issues.apache.org/jira/browse/GERONIMO-1128?page=all ] Aaron Mulder updated GERONIMO-1128: --- Fix Version: 1.0 (was: 1.1) Version: 1.0-M5 (was: 1.0) Assign To: Aaron Mulder (was: Donald Woods) Derby Log Viewer performance problem Key: GERONIMO-1128 URL: http://issues.apache.org/jira/browse/GERONIMO-1128 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Environment: Win32 w/ latest 1.4.2 JDK Reporter: Donald Woods Assignee: Aaron Mulder Fix For: 1.0 When the Derby Log Viewer is rendered on the Servers Log page, the DerbyLogHelper.java copying ALL lines from derby.log and sending it back as a request attribute. As the Derby logfile grows, this will consume more server cycles and eventually impact other user apps and response time. Also, the BufferedReader/FileReader is never closed, so this will leak a file handle everytime the page is rendered. This portlet needs to be replaced with the logmanager/LogViewerPortet implementation, so users can choose how many lines to display -- 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-1128) Derby Log Viewer performance problem
[ http://issues.apache.org/jira/browse/GERONIMO-1128?page=all ] Aaron Mulder resolved GERONIMO-1128: Resolution: Fixed Fixed in revision 355267 Derby Log Viewer performance problem Key: GERONIMO-1128 URL: http://issues.apache.org/jira/browse/GERONIMO-1128 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Environment: Win32 w/ latest 1.4.2 JDK Reporter: Donald Woods Assignee: Aaron Mulder Fix For: 1.0 When the Derby Log Viewer is rendered on the Servers Log page, the DerbyLogHelper.java copying ALL lines from derby.log and sending it back as a request attribute. As the Derby logfile grows, this will consume more server cycles and eventually impact other user apps and response time. Also, the BufferedReader/FileReader is never closed, so this will leak a file handle everytime the page is rendered. This portlet needs to be replaced with the logmanager/LogViewerPortet implementation, so users can choose how many lines to display -- 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-1207) Dependency / Lifecycle Woes
[ http://issues.apache.org/jira/browse/GERONIMO-1207?page=all ] Aaron Mulder resolved GERONIMO-1207: Resolution: Fixed Assign To: Aaron Mulder Fixed in revision 355267. The change is pretty much: Previously, calling a stop function (deploy tool, console, etc.) on a configuration meant it was stopped and unloaded. However, the kernel was still aware of it (it was listed in the configuration list view, deployer list-modules, etc.). The loadRecursive function automatically bailed on any configuration that the kernel was aware of (it did a name query to list loaded configurations). The problem is that if you stop and unload a configuration, the kernel is still aware of it, and therefore loadRecursive would never load it again, and it caused this bug. I changed loadRecursive to only ignore configurations that were actually running. The basis for ignoring something is essentially if it is running, we know it and all its dependencies must be loaded and running therefore we don't need to consider it further. So now, if a configuraiton is present and not loaded, or present and loaded but not running, loadRecursive will still process it (but not actually load it again if it's already loaded, just check its parents and stuff). Now we can stop and unload a module and then later call loadRecursive on it or a child of it and everything works properly. Dependency / Lifecycle Woes --- Key: GERONIMO-1207 URL: http://issues.apache.org/jira/browse/GERONIMO-1207 Project: Geronimo Type: Bug Components: kernel, console Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.0 1) Create a database pool 2) Create a SQL security realm with the database pool as a parent 3) Verify that both are in the running state 4) Stop the database pool 5) Verify that both are in the stopped state 6) Using the console System Modules, start the security realm -- produces all kinds of exceptions 7) Now security realm is in the starting state, database pool is stopped 8) Starting the database pool does not get the security realm out of the starting state, though if you're bold with URL hacking you can start it again and it will start. I think that step 6 should either start both modules or leave both in the stopped state. Being stuck in the starting state is terrible -- at least if it won't automatically recover to the running state when the missing dependencies come online. Here's the stack traces from step 6. javax.portlet.PortletException: Configuration not found at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.processAction(ConfigManagerPortlet.java:131) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at
[jira] Resolved: (GERONIMO-1272) Edit Network Listener portlet should show name of listener being editted.
[ http://issues.apache.org/jira/browse/GERONIMO-1272?page=all ] Aaron Mulder resolved GERONIMO-1272: Fix Version: 1.0 Resolution: Fixed Assign To: Aaron Mulder (was: Vamsavardhana Reddy) Patch applied in revision 355267 -- thanks! Edit Network Listener portlet should show name of listener being editted. - Key: GERONIMO-1272 URL: http://issues.apache.org/jira/browse/GERONIMO-1272 Project: Geronimo Type: Improvement Components: console Reporter: Rick McGuire Assignee: Aaron Mulder Fix For: 1.0 Attachments: GERONIMO-1272.patch When you click on the edit operation of the Web Server-Network Listeners portlet, the editting portlet should show the name of the listener being editted. The lack if context is a little unsettling. -- 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-1225) The recently added Common Console Actions on welcome page doesn't work right
[ http://issues.apache.org/jira/browse/GERONIMO-1225?page=all ] Aaron Mulder resolved GERONIMO-1225: Resolution: Fixed Assign To: Aaron Mulder Patch applied in revision 355267 -- thanks! The recently added Common Console Actions on welcome page doesn't work right -- Key: GERONIMO-1225 URL: http://issues.apache.org/jira/browse/GERONIMO-1225 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: windows xp pro, IE and firefox Reporter: Joe Bohn Assignee: Aaron Mulder Fix For: 1.0 Attachments: GERONIMO-1225.patch Initial view of the welcome page is fine. However, when the user selects help for the portlet and then returns to view none of the icons are found and the links for the tasks don't work. When selecting a link to launch a task the following exeception is thrown: 08:48:11,686 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error whil e dispatching portlet. javax.portlet.PortletException: unknown portlet mode: services at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:262) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218 ) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde r.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvoke rImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerI mpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPo rtlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(Portl etFragment.java:168) at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService (ColumnFragment_jsp.java:60) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper .java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3 14) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde r.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(Abst ractFragment.java:112) at org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(Ro wFragment_jsp.java:57) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper .java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3 14) at
[jira] Resolved: (GERONIMO-886) Demo application cannot start using the Geronimo console
[ http://issues.apache.org/jira/browse/GERONIMO-886?page=all ] Aaron Mulder resolved GERONIMO-886: --- Resolution: Cannot Reproduce Assign To: Aaron Mulder No longer seeing this behavior, but the demo app has been restructured anyway. Demo application cannot start using the Geronimo console Key: GERONIMO-886 URL: http://issues.apache.org/jira/browse/GERONIMO-886 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Dave Colasurdo Assignee: Aaron Mulder Fix For: 1.0 From the geronimo console, I tried start the Demo application via Applications-Web App WARs and the application gets stuck in starting state. Other applications I have tried work fine.. I am using the latest unstable build. This looks similar to Geronimo-442.. Though that JIRA has already been fixed and the problem is still occuring when started from the 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
Re: Does there need to be a default web container?
I may have phrased the original issue badly. The installer has both Jetty and Tomcat as options to install on the main pack selection page. It was decided that because of the complexity of installing two web containers that we should not install both, but allow the operator to select one or the other. In M5, the installer actually allowed both containers to be configured, but did not have a way to validate the ports selected. When configured correctly with no conflicting ports, both containers will start. There's some goofiness with offlineDeployer and runtimeDeployer since one of the containers will win the config.xml entries if more than one is selected -- looks like Tomcat wins. For 1.0, both containers will be listed on the first selection screen. However, it didn't make sense to default both to install when the plan was to only allow one. Allowing both requires the installer to validate the ports and ensure that the operator does not configure both containers to the same port. This problem exists for other port types as well, but is less likely to be a problem. IzPack does not support this inter-panel validation easily i.e. through normal XML based configuration. It requires that java code be built to extend the user input panels. On the other hand, limiting the operator to one web container is no panacea either. To effectively do this, I have configured the XML to set Jetty as the default to install (Tomcat can be selected) since it's confusing to do otherwise in this scenario (although the default could just as easily be Tomcat and it looks like the vote is going that way). This effectively starts down a good path for this scenario, but the operator can easily select both containers again. To stop this, I will extend a userinput panel to be invoked to check that both are selected and not allow the install to proceed past the first userinput screen -- the first screen after the major component selection. This again requires java code since IzPack does not have a parameter to apply to packs such as exclusiveOf( packName ). This is interesting since it does have depends( packname ) which allows us to require the Tomcat container when installing the Tomcat console, etc. This may be more than everyone wants to know, but to answer your question, I don't see any particular reason why the installer cannot allow installation of both. However, it's very late in the 1.0 cycle and the current design is that we'd allow one or the other, but not both. I have no particular preference myself. On Thursday 08 December 2005 18:30, Jeff Genender wrote: This is obviously a hot topic and I hope that as a Geronimo PMC and user community we are not forced to have to show preference of one over the other. There is obviously some personal preferences on both sides and we are a great open source project because we do not have to get behind one *or* the other. We can get behind them both. May I ask why the installer/wizard cannot have a page called Choose Your Web Container and have an option for Jetty and Tomcat, but neither selected? Does there need to be a default? Can we just let the end user choose? IMHO, I don't think we should provide a preference for one over the other. I really like both. I think we should give the user the choice without hinting a preference. Thoughts and comments? Jeff -- Regards, Erik
[jira] Updated: (GERONIMO-1217) WARN message in console for JMS Server
[ http://issues.apache.org/jira/browse/GERONIMO-1217?page=all ] Aaron Mulder updated GERONIMO-1217: --- Fix Version: 1.0 Assign To: Aaron Mulder This will be fixed by adding activemq-core and activemq-gbean as dependencies of the console configuraitions -- I'm waiting to find out the best way to do this. WARN message in console for JMS Server -- Key: GERONIMO-1217 URL: http://issues.apache.org/jira/browse/GERONIMO-1217 Project: Geronimo Type: Improvement Components: console Versions: 1.0-M5 Reporter: Krishnakumar B Assignee: Aaron Mulder Priority: Minor Fix For: 1.0 When i click JMS Server in Console JMS Server Manager and Listeners are displayed. The following WARN message is displayed in console and is logged in log file. 11:20:55,076 WARN [BasicProxyManager] Could not load interface org.activemq.gbean.ActiveMQContainer in provided ClassLoader for ActiveMQ 11:20:55,797 WARN [BasicProxyManager] Could not load interface org.activemq.gbean.ActiveMQContainer in provided ClassLoader for ActiveMQ -- 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-1316) Create JMS destination pretty darn broken
Create JMS destination pretty darn broken - Key: GERONIMO-1316 URL: http://issues.apache.org/jira/browse/GERONIMO-1316 Project: Geronimo Type: Bug Components: ActiveMQ, console, management Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.1 Creating a destination is very broken -- often silently fails, creates a new GBean without adding it to a configuraiton (or deploying as a new configuration), etc. -- 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: Does there need to be a default web container?
Aaron Mulder wrote: I hate to say it, but from a usability perspective, I think we need to have a default. Otherwise, when installing Geronimo, the first thing the user has to do is make a decision that most users really have no basis for making. Granted a Wiki link would help, but I think we need to provide a 0-decision install path where you can essentially just click through and something good will happen. At the end of the day, I wish we could avoid the politics, and I definitely don't think we need to present this as an official Geronimo preference. Any documentation referenced can start out by saying either one will work fine and we fully support both (and the TAR/ZIP download page should say the same). Still, I would really prefer to have a pre-selected default on the install screen when it comes up. Thanks, Aaron I agree with Aaron with regard to usability. Users don't want to have to make any decisions on the first install (especially when they first pick it up for evaluation). My mom doesn't install anything on her computer unless she can click, click, click and get it working. I know our users are more sophisticated than her ... but we want to make it as easy as possibly to get something working quickly. We want to make this easy enough for my mom to install (even though she never will). :-) Joe On 12/8/05, John Sisson [EMAIL PROTECTED] wrote: +1 - I don't think we should make the decision for the user. It would be even better if the installer in a Choose Your Web Container page, provided a URL or link to a page on the Wiki that provided information that would help them make an informed decision. See related ideas in http://issues.apache.org/jira/browse/GERONIMO-1314 John Jeff Genender wrote: This is obviously a hot topic and I hope that as a Geronimo PMC and user community we are not forced to have to show preference of one over the other. There is obviously some personal preferences on both sides and we are a great open source project because we do not have to get behind one *or* the other. We can get behind them both. May I ask why the installer/wizard cannot have a page called Choose Your Web Container and have an option for Jetty and Tomcat, but neither selected? Does there need to be a default? Can we just let the end user choose? IMHO, I don't think we should provide a preference for one over the other. I really like both. I think we should give the user the choice without hinting a preference. Thoughts and comments? Jeff -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Does there need to be a default web container?
Joe Bohn wrote: I agree with Aaron with regard to usability. Users don't want to have to make any decisions on the first install (especially when they first pick it up for evaluation). My mom doesn't install anything on her computer unless she can click, click, click and get it working. I know our users are more sophisticated than her ... but we want to make it as easy as possibly to get something working quickly. We want to make this easy enough for my mom to install (even though she never will). :-) So you think your average Geronimo user will have no idea what a web container is? Joe On 12/8/05, John Sisson [EMAIL PROTECTED] wrote: +1 - I don't think we should make the decision for the user. It would be even better if the installer in a Choose Your Web Container page, provided a URL or link to a page on the Wiki that provided information that would help them make an informed decision. See related ideas in http://issues.apache.org/jira/browse/GERONIMO-1314 John Jeff Genender wrote: This is obviously a hot topic and I hope that as a Geronimo PMC and user community we are not forced to have to show preference of one over the other. There is obviously some personal preferences on both sides and we are a great open source project because we do not have to get behind one *or* the other. We can get behind them both. May I ask why the installer/wizard cannot have a page called Choose Your Web Container and have an option for Jetty and Tomcat, but neither selected? Does there need to be a default? Can we just let the end user choose? IMHO, I don't think we should provide a preference for one over the other. I really like both. I think we should give the user the choice without hinting a preference. Thoughts and comments? Jeff
Re: Does there need to be a default web container?
-0 As I have often said, in the long run the user should not care if they are using jetty or tomcat and it was a mistake for us to expose implementation detail as we have. I have always preferred the web tier to be just called web and then in future the developers will have the option to change implementations. Just as we may change the implementation of GBeans, CORBA, EJB, JMS or any other component. I would say that perhaps the installer should not even offer the option unless it is in some advanced mode. Less is more when it comes to configuration options. If at a later time we have a debate about technical advantages and support issues and decide that tomcat is a better default - then that can be changed in a future release (or we can continue to work hard to improve Jetty to meet the requirements of the geronimo community). regards Jeff Genender wrote: This is obviously a hot topic and I hope that as a Geronimo PMC and user community we are not forced to have to show preference of one over the other. There is obviously some personal preferences on both sides and we are a great open source project because we do not have to get behind one *or* the other. We can get behind them both. May I ask why the installer/wizard cannot have a page called Choose Your Web Container and have an option for Jetty and Tomcat, but neither selected? Does there need to be a default? Can we just let the end user choose? IMHO, I don't think we should provide a preference for one over the other. I really like both. I think we should give the user the choice without hinting a preference. Thoughts and comments? Jeff
Re: gbuild: chef and co offlline?
Back online now. Thanks, Aaron! -David On Dec 7, 2005, at 10:58 PM, David Blevins wrote: Aaron, The Chariot boxes chef, timmy, and jimmy can't be reached. I checked the gbuild logs and it seems the three of them disappeared just after 8:45pm PST. Any ideas? -David
Re: Build/test failure in Timer
this happens sometimes, these tests are slightly indeterminate due to the timer. For me they usually pass if I run them again without a lot of other work going on on my machine. thanks david jencks On Dec 8, 2005, at 3:07 PM, Christopher Chan wrote: Does anyone have any ideas? Thanks in advanced At revision 355260 in the geronimo 1.0 branch ... test:test: [junit] Running org.apache.geronimo.timer.jdbc.DerbyJDBCWorkerPersistenceTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 6.123 sec [junit] Running org.apache.geronimo.timer.TransactionalThreadPooledTimerTest [junit] Tests run: 10, Failures: 1, Errors: 0, Time elapsed: 25.556 sec [junit] [ERROR] TEST org.apache.geronimo.timer.TransactionalThreadPooledTimerTest FAILED [junit] Running org.apache.geronimo.timer.NontransactionalThreadPooledTimerTest [junit] Tests run: 10, Failures: 1, Errors: 0, Time elapsed: 25.313 sec [junit] [ERROR] TEST org.apache.geronimo.timer.NontransactionalThreadPooledTimerTest FAILED BUILD FAILED File.. /home/cchan/.maven/cache/maven-multiproject-plugin-1.3.1/ plugin.jellyElement... maven:reactor Line.. 217 Column 9 Unable to obtain goal [default] -- /home/cchan/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly:181:54: fail There were test failures. Total time: 9 minutes 19 seconds 14:53:14,706 INFO [App] Total time: 9 minutes 19 seconds 14:53:14,706 INFO [App] Total time: 9 minutes 19 seconds Finished at: Thu Dec 08 14:53:14 PST 2005
Re: Adding new dependencies to console in config/
The plan dependencies and imports and includes are added by the packaging plugin from the dependencies in the project.xml. properties geronimo.importtrue/geronimo.import /properties turns into import (parent) properties geronimo.dependencytrue/geronimo.dependency /properties turns into dependency properties geronimo.includetrue/geronimo.include /properties turns into include thanks david jencks On Dec 8, 2005, at 2:55 PM, Aaron Mulder wrote: The current console builds in config/ don't include enough ActiveMQ libraries on their class path. I can add the 2 ActiveMQ libraries as dependency elements in the console EAR deployment plans for console-tomcat and console-jetty, but that doesn't seem to be the way it's handled right now. Somehow now I think activemq-gbean-management is on the classpath, but activemq-core and activemq-gbean are not. So my question is, how is that being done? I didn't see the dependency plugin being used for the console, and when I grepped the config/ directories for activemq I didn't get any hits except in the CARs... so I'm just a little confused. Thanks, Aaron
Re: Does there need to be a default web container?
Jeff Genender wrote: Joe Bohn wrote: I agree with Aaron with regard to usability. Users don't want to have to make any decisions on the first install (especially when they first pick it up for evaluation). My mom doesn't install anything on her computer unless she can click, click, click and get it working. I know our users are more sophisticated than her ... but we want to make it as easy as possibly to get something working quickly. We want to make this easy enough for my mom to install (even though she never will). :-) So you think your average Geronimo user will have no idea what a web container is? I think they'll know what a web container is. I just don't think that they will initially care which web container they use the first time they install Geronimo. When they are ready to begin using Geronimo in earnest then they will take the time to decide which web container they want and if necessary the choose the non-default they can over-ride it. But for the first install I don't think most users will care. I just think that we want to make a good first impression by being easier to install then the user may have expected (which I'm currently hoping can eventually be click, click, click, done). Joe Joe On 12/8/05, John Sisson [EMAIL PROTECTED] wrote: +1 - I don't think we should make the decision for the user. It would be even better if the installer in a Choose Your Web Container page, provided a URL or link to a page on the Wiki that provided information that would help them make an informed decision. See related ideas in http://issues.apache.org/jira/browse/GERONIMO-1314 John Jeff Genender wrote: This is obviously a hot topic and I hope that as a Geronimo PMC and user community we are not forced to have to show preference of one over the other. There is obviously some personal preferences on both sides and we are a great open source project because we do not have to get behind one *or* the other. We can get behind them both. May I ask why the installer/wizard cannot have a page called Choose Your Web Container and have an option for Jetty and Tomcat, but neither selected? Does there need to be a default? Can we just let the end user choose? IMHO, I don't think we should provide a preference for one over the other. I really like both. I think we should give the user the choice without hinting a preference. Thoughts and comments? Jeff -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
[jira] Closed: (GERONIMO-1312) app client builder uses config-store in a way inconsistent with the packaging plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1312?page=all ] David Jencks closed GERONIMO-1312: -- Resolution: Fixed Fixed by making the MavenConfigStore able to install configurations. This area should be revisited when we have more time. I also included an experimental class for an offline deployer due to lack of time. Sendingplugins/geronimo-packaging-plugin/project.xml Sending plugins/geronimo-packaging-plugin/src/java/org/apache/geronimo/plugin/packaging/MavenConfigStore.java Sending plugins/geronimo-packaging-plugin/src/java/org/apache/geronimo/plugin/packaging/PackageBuilder.java Sending plugins/geronimo-packaging-plugin/src/java/org/apache/geronimo/plugin/packaging/PackageBuilderShell.java Adding plugins/geronimo-packaging-plugin/src/java/org/apache/geronimo/plugin/packaging/PackagingCommandLine.java Transmitting file data . Committed revision 355299. app client builder uses config-store in a way inconsistent with the packaging plugin Key: GERONIMO-1312 URL: http://issues.apache.org/jira/browse/GERONIMO-1312 Project: Geronimo Type: Bug Components: deployment Versions: 1.0 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0 the app client builder calls install on the config-store it knows about. However, the config store the packaging plugin uses is read-only. Thus it is currently impossible to deploy an app client using the packagin plugin. This is a problem for e.g. daytrader. -- 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: Does there need to be a default web container?
Jeff Genender wrote: So you think your average Geronimo user will have no idea what a web container is? It's possible. There are a lot of experienced J2EE developers out there who have only ever used full commercial stacks. Asking them to choose between two web containers is like asking them to choose EJB, MQ and Web Service implementations. They may pick Tomcat because they vaguely recognize the name, but having to make that choice will add anxiety to their install experience. Geronimo is also likely to become popular in academic settings (both classroom and self-study) where people will need to install the server before they get around to learning what a web container is. Cheers, Erin
Re: Statistics Management and Jetty/Tomcat
--- Joe Bohn [EMAIL PROTECTED] wrote: Greg I've modified the list below to add what we would like to present in Geronimo. Jeff and/or Anita, Do you think we can get comparable information from tomcat? We would also need to know how to enable, disable, and reset these statistics for tomcat. Tomcat Manager queries tomcat Mbean Catalina:type=GlobalRequestProcessor,. to get the following statistcs for each of its connectors. Their Jetty equivalents are written next to each. 1. RequestCount : private transient int _requests : total requests made to the server, I guess to get this add RequestCount from all the connectors. 2. maxTime : _requestsDurationMax : max request duration 3. bytesSent - no Jetty equivelent 4. bytesReceived - no Jetty equivalent 5. processingTime - _requestsDurationTotalTime : total request duration time 6. errorCount - _errors : total bad requests to the server Other than this, it provides per request statistics. These can be used to compute _requestsActive (number of requests currently being handled) ,e.g., go through each req stat, find the active ones, and count them up. I need to expose tomcat's mBeanServer via TomcatContainer, and write TomcatStatsGbean. setStatesOn would mean initializing All the stat attributes of the Mbeans. Jeff please comment? Tomcat does not provide (?) any connection statistics. I will not be able to do this pre 1.0. Thanks Anita Joe Greg Wilkins wrote: These new stats methods are in Jetty CVS if you want them in a hurry. I'll update the snapshot releases tomorrow. cheers Greg Wilkins wrote: So would you be OK with the following stats: private transient long _statsStartedAt=0; // time stats collection started private transient int _connections; // total number of connections made to server private transient int _connectionsOpen; // number of connections currently open private transient int _connectionsOpenMin; // min number of connections open simultaneously private transient int _connectionsOpenMax; // max number of connections open simultaneously private transient long _connectionsDurationMin; // min duration of a connection private transient long _connectionsDurationMax; // max duration of a connection private transient long _connectionsDurationTotalTime;// total duration of all coneection private transient long _connectionsDurationCount;// total number of connections created (I guess this would be the same as _connections above so perhaps we don't need it again in this form) private transient int _errors; // total bad requests to the server private transient int _requests; // total requests made to the server private transient int _requestsActive; // number of requests currently being handled private transient int _requestsActiveMin; // min number of connections handled simultaneously private transient int _requestsActiveMax; // max number of connections handled simultaneously private transient int _connectionsRequestsMin; // min requests per connection private transient int _connectionsRequestsMax; // max requests per connection private transient int _connectionsRequestsCurrent; // The number of connection requests currently in progress (I guess this would be no different than the _connectionsOpen above ... so perhaps we don't need this again in this form) private transient long _requestsDurationMin; // min request duration private transient long _requestsDurationMax; // max request duration private transient long _requestsDurationTotalTime; // total request duration time private transient long _requestsDurationCount; // total number of requests (I guess this would be no different than _requests above ... so perhaps we don't need it again in this form) -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [Vote] Installer: Default Web Container Selection
I have changed my mind, please ignore my previous vote. My vote is now: [ X ] Make Jetty the default Web Container install selection My initial concerns were with users not familiar with Jetty (e.g. Tomcat users) and the lack of Geronimo documentation on Jetty. I chatted to Greg W on IRC and he said he will improve the documentation. I have raised JIRAs GERONIMO-1314 and GERONIMO-1315. Thinking about it more, those who already use Tomcat in other projects are probably going to click Tomcat if they don't go to the trouble of looking into Jetty. I agree with Aaron that we should make it clear in the documentation that it is only a default to simplify the install process and either container can be used and both are supported. John Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
FYI, hardcoded version references
Just so this list isn't lost, this is the output of a grep I did for
1.0-SNAPSHOT in our current tree.
Aaron
applications/demo/src/webapp/WEB-INF/geronimo-web.xml:
configId=geronimo/security-demo/1.0-SNAPSHOT/car
applications/demo/src/webapp/WEB-INF/geronimo-web.xml:
parentId=geronimo/security/1.0-SNAPSHOT/car
applications/magicGball/src/plan/magicgball-corba-nosec-plan.xml:
parentId=geronimo/j2ee-server-corba/1.0-SNAPSHOT/car
applications/magicGball/src/webapp/WEB-INF/web.xml:
ejb-linkmagicGball-ejb-1.0-SNAPSHOT.jar#MagicGBall/ejb-link
applications/jmxdebug/src/webapp/WEB-INF/geronimo-web.xml:
configId=geronimo/debug-console/1.0-SNAPSHOT/car
applications/jmxdebug/src/webapp/WEB-INF/geronimo-web.xml:
parentId=geronimo/j2ee-server/1.0-SNAPSHOT/car
applications/console-standard/src/java/org/apache/geronimo/console/jmsmanager/JMSConnectionFactoryManagerPortlet.java:
private final static String PARENT_ID =
geronimo/activemq-broker/1.0-SNAPSHOT/car;
applications/console-standard/src/java/org/apache/geronimo/console/jmsmanager/handlers/CreateDestinationHandler.java:
private static final List parentId = Arrays.asList(new URI[]
{URI.create(geronimo/activemq-broker/1.0-SNAPSHOT/car)});
applications/console-standard/src/java/org/apache/geronimo/console/databasemanager/wizard/DatabasePoolPortlet.java:
connector.setParentID(geronimo/j2ee-server/1.0-SNAPSHOT/car);
applications/console-standard/src/webapp/WEB-INF/view/realmwizard/usage.jsp:
parentId=geronimo/j2ee-server/1.0-SNAPSHOT/cargt;
applications/remote-deploy/src/webapp/WEB-INF/geronimo-web.xml:
configId=geronimo/remote-deploy/1.0-SNAPSHOT/car
applications/remote-deploy/src/webapp/WEB-INF/geronimo-web.xml:
cfg:version1.0-SNAPSHOT/cfg:version
BUILDING.txt:$ cd target/geronimo-1.0-SNAPSHOT
etc/version-info.properties:geronimo_kernel_version=1.0-SNAPSHOT
etc/version-info.properties:geronimo_system_version=1.0-SNAPSHOT
etc/version-info.properties:geronimo_version=1.0-SNAPSHOT
etc/version-info.properties:tranql_version=1.0-SNAPSHOT
etc/version-info.properties:tranql_connector_version=1.0-SNAPSHOT
etc/version-info.properties:activecluster_version=1.0-SNAPSHOT
etc/project.properties:geronimo_version=1.0-SNAPSHOT
modules/client-builder/src/test-resources/plans/plan2.xml:
external-rartranql/rars/tranql-connector-1.0-SNAPSHOT/external-rar
modules/deploy-jsr88/src/conf/manifest.mf:Class-Path:
../lib/geronimo-common-1.0-SNAPSHOT.jar ../lib/geronimo-d
modules/deploy-jsr88/src/conf/manifest.mf: eployment-1.0-SNAPSHOT.jar
../lib/geronimo-deploy-jsr88-1.0-SNAPSHOT.
modules/deploy-jsr88/src/conf/manifest.mf: jar
../lib/geronimo-kernel-1.0-SNAPSHOT.jar ../lib/geronimo-system-1.
modules/activation/pom.xml:version1.0-SNAPSHOT/version
modules/tomcat/src/plan/tomcat-plan.xml:
urigeronimo/jars/geronimo-tomcat-1.0-SNAPSHOT.jar/uri
modules/tomcat/src/plan/tomcat-plan.xml:
urigeronimo/jars/geronimo-system-1.0-SNAPSHOT.jar/uri
openejb/m2/openejb-builder.pom: version1.0-SNAPSHOT/version
openejb/m2/openejb-builder.pom: version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/m2/openejb-root.pom:version1.0-SNAPSHOT/version
openejb/etc/project.properties:geronimo_version=1.0-SNAPSHOT
openejb/etc/project.properties:scout_version=1.0-SNAPSHOT
plugins/geronimo-dependency-plugin/project.xml:
currentVersion1.0-SNAPSHOT/currentVersion
plugins/geronimo-dependency-plugin/project.properties:geronimoVersion=1.0-SNAPSHOT
plugins/geronimo-deployment-plugin/plugin.properties:geronimoVersion=1.0-SNAPSHOT
Re: [Vote] Installer: Default Web Container Selection
+1 for Apache Tomcat Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ X ] Make Apache Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though. smime.p7s Description: S/MIME Cryptographic Signature
Re: Does there need to be a default web container?
Erin Mulder wrote: Jeff Genender wrote: So you think your average Geronimo user will have no idea what a web container is? It's possible. I asked average user...not whether its possible. The average user will probably be a developer...who has done some degree of background on the technologies. I would hazard to guess there are few people who use BEA or Websphere and have absolutely no idea what a web container is. The developer will likely know what it is. I have a hard time with equating someone's clickety-click Mom with our average user...its ridicules, which was really what my previous response was directed towards. There are a lot of experienced J2EE developers out there who have only ever used full commercial stacks. Asking them to choose between two web containers is like asking them to choose EJB, MQ and Web Service implementations. They may pick Tomcat because they vaguely recognize the name, but having to make that choice will add anxiety to their install experience. I am sorry but I cannot agree here. I cannot believe there are many experienced *J2EE* developers who have no idea what a web container is. That is preposterous. Are there some? Sure - but I would say very few. However, in servlet 101...of which many of these un-knowledgable users would go, surely a mention of a web container, what it is, and what they can use (including books, articles, internet), they should have a minimal understanding of web containers. Geronimo is also likely to become popular in academic settings (both classroom and self-study) where people will need to install the server before they get around to learning what a web container is. The academic component is such a small microcosm in the grand scheme of users, this not even a reason to think its has a major effect of the overall user-base. We should push the direction of Geronimo towards what the community wants. If the community wants Jetty, give it to them. If they want Tomcat, then let them have this. Let the community decide. Cheers, Erin
Re: [Vote] Installer: Default Web Container Selection
Ok then based on this... I hope that this group takes into the account of all votes, including those that use the app server, our community and users. If we cannot be neutral, then minimally we should let the users decide what they want as a default container. If everyone wants Jetty as a default, then I am behind it. But if a majority want Tomcat, lets give the community what they want. A vote was put out...lets see what our users want. Jeff John Sisson wrote: I have changed my mind, please ignore my previous vote. My vote is now: [ X ] Make Jetty the default Web Container install selection My initial concerns were with users not familiar with Jetty (e.g. Tomcat users) and the lack of Geronimo documentation on Jetty. I chatted to Greg W on IRC and he said he will improve the documentation. I have raised JIRAs GERONIMO-1314 and GERONIMO-1315. Thinking about it more, those who already use Tomcat in other projects are probably going to click Tomcat if they don't go to the trouble of looking into Jetty. I agree with Aaron that we should make it clear in the documentation that it is only a default to simplify the install process and either container can be used and both are supported. John Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
RE: Build/test failure in Timer
Thanks!! That pointed me to a gnome process going crazy. It's going through now. -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Thursday, December 08, 2005 5:09 PM To: dev@geronimo.apache.org Subject: Re: Build/test failure in Timer this happens sometimes, these tests are slightly indeterminate due to the timer. For me they usually pass if I run them again without a lot of other work going on on my machine. thanks david jencks On Dec 8, 2005, at 3:07 PM, Christopher Chan wrote: Does anyone have any ideas? Thanks in advanced At revision 355260 in the geronimo 1.0 branch ... test:test: [junit] Running org.apache.geronimo.timer.jdbc.DerbyJDBCWorkerPersistenceTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 6.123 sec [junit] Running org.apache.geronimo.timer.TransactionalThreadPooledTimerTest [junit] Tests run: 10, Failures: 1, Errors: 0, Time elapsed: 25.556 sec [junit] [ERROR] TEST org.apache.geronimo.timer.TransactionalThreadPooledTimerTest FAILED [junit] Running org.apache.geronimo.timer.NontransactionalThreadPooledTimerTest [junit] Tests run: 10, Failures: 1, Errors: 0, Time elapsed: 25.313 sec [junit] [ERROR] TEST org.apache.geronimo.timer.NontransactionalThreadPooledTimerTest FAILED BUILD FAILED File.. /home/cchan/.maven/cache/maven-multiproject-plugin-1.3.1/ plugin.jellyElement... maven:reactor Line.. 217 Column 9 Unable to obtain goal [default] -- /home/cchan/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly:181:54: fail There were test failures. Total time: 9 minutes 19 seconds 14:53:14,706 INFO [App] Total time: 9 minutes 19 seconds 14:53:14,706 INFO [App] Total time: 9 minutes 19 seconds Finished at: Thu Dec 08 14:53:14 PST 2005
Re: [Vote] Installer: Default Web Container Selection
+1 for Jetty -Brian On Dec 8, 2005, at 6:10 PM, Jeff Genender wrote: Ok then based on this... I hope that this group takes into the account of all votes, including those that use the app server, our community and users. If we cannot be neutral, then minimally we should let the users decide what they want as a default container. If everyone wants Jetty as a default, then I am behind it. But if a majority want Tomcat, lets give the community what they want. A vote was put out...lets see what our users want. Jeff John Sisson wrote: I have changed my mind, please ignore my previous vote. My vote is now: [ X ] Make Jetty the default Web Container install selection My initial concerns were with users not familiar with Jetty (e.g. Tomcat users) and the lack of Geronimo documentation on Jetty. I chatted to Greg W on IRC and he said he will improve the documentation. I have raised JIRAs GERONIMO-1314 and GERONIMO-1315. Thinking about it more, those who already use Tomcat in other projects are probably going to click Tomcat if they don't go to the trouble of looking into Jetty. I agree with Aaron that we should make it clear in the documentation that it is only a default to simplify the install process and either container can be used and both are supported. John Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
Re: [Vote] Installer: Default Web Container Selection
+1 for jetty david jencks On Dec 8, 2005, at 10:08 AM, Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though. -- Regards, Erik
[jira] Created: (GERONIMO-1317) Integration of the new maven goals with existing goals
Integration of the new maven goals with existing goals Key: GERONIMO-1317 URL: http://issues.apache.org/jira/browse/GERONIMO-1317 Project: Geronimo Type: Bug Components: buildsystem Versions: 1.0, 1.1 Environment: Maven 1.1Beta2 on WinXP Reporter: Donald Woods Assigned to: Donald Woods Priority: Critical Fix For: 1.0 For ongoing development builds, we need to get the clean, eclipse, idea and other Maven goals that we used to have working again. I have created updated \maven.xml and \project.properties files based on 1.0 Rev355316, which renames and integrates the new0-new5 goals into the m:default goal, only tries to build openejb and tranql if those directories exist and enables the usage of the rebuild-all, build-all, build, clean, clean-all, eclipse and idea goals. I'll attach the patch files and copies of the updated files for testing before integrating the 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
Re: Does there need to be a default web container?
Sorry Jeff, I have to disagree. If you asked me whether you should use Tomcat or Jetty, I really couldn't give you an informed answer. About the best I could say is they both work fine in Geronimo, they do a couple things like virtual hosting slightly differently, and the Jetty team is actively involved in Geronimo whereas we pretty much built the Tomcat integration on our own. Still, that doesn't give you much guidance (the last bit there is the only reason I personally would have any preference at all). And I feel like I'm in the *most* informed 1% of all possible Geronimo users. I don't think it's sensible to argue over what average people know or don't know, it's just my feeling that if I can't make a clear decision for obvious reasons, then I can't ask every user who ever installs the product to make that same decision. Thanks, Aaron On 12/8/05, Jeff Genender [EMAIL PROTECTED] wrote: Erin Mulder wrote: Jeff Genender wrote: So you think your average Geronimo user will have no idea what a web container is? It's possible. I asked average user...not whether its possible. The average user will probably be a developer...who has done some degree of background on the technologies. I would hazard to guess there are few people who use BEA or Websphere and have absolutely no idea what a web container is. The developer will likely know what it is. I have a hard time with equating someone's clickety-click Mom with our average user...its ridicules, which was really what my previous response was directed towards. There are a lot of experienced J2EE developers out there who have only ever used full commercial stacks. Asking them to choose between two web containers is like asking them to choose EJB, MQ and Web Service implementations. They may pick Tomcat because they vaguely recognize the name, but having to make that choice will add anxiety to their install experience. I am sorry but I cannot agree here. I cannot believe there are many experienced *J2EE* developers who have no idea what a web container is. That is preposterous. Are there some? Sure - but I would say very few. However, in servlet 101...of which many of these un-knowledgable users would go, surely a mention of a web container, what it is, and what they can use (including books, articles, internet), they should have a minimal understanding of web containers. Geronimo is also likely to become popular in academic settings (both classroom and self-study) where people will need to install the server before they get around to learning what a web container is. The academic component is such a small microcosm in the grand scheme of users, this not even a reason to think its has a major effect of the overall user-base. We should push the direction of Geronimo towards what the community wants. If the community wants Jetty, give it to them. If they want Tomcat, then let them have this. Let the community decide. Cheers, Erin
[jira] Updated: (GERONIMO-1317) Integration of the new maven goals with existing goals
[ http://issues.apache.org/jira/browse/GERONIMO-1317?page=all ] Donald Woods updated GERONIMO-1317: --- Attachment: maven.xml project.properties Copies of updated maven.xml and project.properties, for easy testing before integrating the changes... Integration of the new maven goals with existing goals Key: GERONIMO-1317 URL: http://issues.apache.org/jira/browse/GERONIMO-1317 Project: Geronimo Type: Bug Components: buildsystem Versions: 1.0, 1.1 Environment: Maven 1.1Beta2 on WinXP Reporter: Donald Woods Assignee: Donald Woods Priority: Critical Fix For: 1.0 Attachments: Geronimo-1317.patch, maven.xml, project.properties For ongoing development builds, we need to get the clean, eclipse, idea and other Maven goals that we used to have working again. I have created updated \maven.xml and \project.properties files based on 1.0 Rev355316, which renames and integrates the new0-new5 goals into the m:default goal, only tries to build openejb and tranql if those directories exist and enables the usage of the rebuild-all, build-all, build, clean, clean-all, eclipse and idea goals. I'll attach the patch files and copies of the updated files for testing before integrating the 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
[WEBCONSOLE] Start Playing with Pluto 1.1?
The Pluto team is preparing to release pluto-1.1-ALPHA. In addition to simplifying the container to be much easier to embed and customize, we have added support for runtime portlet deployment. I understand that this is something that you guys might be interested in. I have begun looking at your webconsole and think plugging in 1.1 should be pretty simple. If you're interested, I'd love to work with some of you at ApacheCon and help you get upgraded. Let me know, David
Re: [WEBCONSOLE] Start Playing with Pluto 1.1?
Sounds great to me, but I'm probably not going to have a ton of time to work on this in the immediate future on account of getting 1.0 out the door and so on. I'd love to at least talk at ApacheCon and lay the groundwork for moving forward with Pluto 1.1 for the next Geronimo version. Thanks, Aaron On 12/8/05, David H. DeWolf [EMAIL PROTECTED] wrote: The Pluto team is preparing to release pluto-1.1-ALPHA. In addition to simplifying the container to be much easier to embed and customize, we have added support for runtime portlet deployment. I understand that this is something that you guys might be interested in. I have begun looking at your webconsole and think plugging in 1.1 should be pretty simple. If you're interested, I'd love to work with some of you at ApacheCon and help you get upgraded. Let me know, David
Re: Does there need to be a default web container?
Then lets agree to disagree. We should probably take this offline if it needs to be discussed further. This is kind of off-topic. Jeff Aaron Mulder wrote: Sorry Jeff, I have to disagree. If you asked me whether you should use Tomcat or Jetty, I really couldn't give you an informed answer. About the best I could say is they both work fine in Geronimo, they do a couple things like virtual hosting slightly differently, and the Jetty team is actively involved in Geronimo whereas we pretty much built the Tomcat integration on our own. Still, that doesn't give you much guidance (the last bit there is the only reason I personally would have any preference at all). And I feel like I'm in the *most* informed 1% of all possible Geronimo users. I don't think it's sensible to argue over what average people know or don't know, it's just my feeling that if I can't make a clear decision for obvious reasons, then I can't ask every user who ever installs the product to make that same decision. Thanks, Aaron On 12/8/05, Jeff Genender [EMAIL PROTECTED] wrote: Erin Mulder wrote: Jeff Genender wrote: So you think your average Geronimo user will have no idea what a web container is? It's possible. I asked average user...not whether its possible. The average user will probably be a developer...who has done some degree of background on the technologies. I would hazard to guess there are few people who use BEA or Websphere and have absolutely no idea what a web container is. The developer will likely know what it is. I have a hard time with equating someone's clickety-click Mom with our average user...its ridicules, which was really what my previous response was directed towards. There are a lot of experienced J2EE developers out there who have only ever used full commercial stacks. Asking them to choose between two web containers is like asking them to choose EJB, MQ and Web Service implementations. They may pick Tomcat because they vaguely recognize the name, but having to make that choice will add anxiety to their install experience. I am sorry but I cannot agree here. I cannot believe there are many experienced *J2EE* developers who have no idea what a web container is. That is preposterous. Are there some? Sure - but I would say very few. However, in servlet 101...of which many of these un-knowledgable users would go, surely a mention of a web container, what it is, and what they can use (including books, articles, internet), they should have a minimal understanding of web containers. Geronimo is also likely to become popular in academic settings (both classroom and self-study) where people will need to install the server before they get around to learning what a web container is. The academic component is such a small microcosm in the grand scheme of users, this not even a reason to think its has a major effect of the overall user-base. We should push the direction of Geronimo towards what the community wants. If the community wants Jetty, give it to them. If they want Tomcat, then let them have this. Let the community decide. Cheers, Erin
Re: [Vote] Installer: Default Web Container Selection
Looking at the original proposal for geronimo makes me lean towards Tomcat. http://incubator.apache.org/projects/geronimo-proposal.html But from a more practical standpoint it's clear that Jetty has a long history of active involvement in the project.[ X ] Make Jetty the default Web Container install selectionBest wishes,Paul On 12/8/05, Erik Daughtrey [EMAIL PROTECTED] wrote:The installershould make either Tomcat or Jetty the default selection.The operator can always override and select the other.Vote:[] Make Jetty the default Web Container install selection[] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why itshouldn't be.FYI - it's been decided that installation of both web containers via theinstaller will not be allowed.Manual configuration of both is possible though.--Regards,Erik
[jira] Assigned: (GERONIMO-1317) Integration of the new maven goals with existing goals
[ http://issues.apache.org/jira/browse/GERONIMO-1317?page=all ] Donald Woods reassigned GERONIMO-1317: -- Assign To: (was: Donald Woods) Integration of the new maven goals with existing goals Key: GERONIMO-1317 URL: http://issues.apache.org/jira/browse/GERONIMO-1317 Project: Geronimo Type: Bug Components: buildsystem Versions: 1.0, 1.1 Environment: Maven 1.1Beta2 on WinXP Reporter: Donald Woods Priority: Critical Fix For: 1.0 Attachments: Geronimo-1317.patch, maven.xml, project.properties For ongoing development builds, we need to get the clean, eclipse, idea and other Maven goals that we used to have working again. I have created updated \maven.xml and \project.properties files based on 1.0 Rev355316, which renames and integrates the new0-new5 goals into the m:default goal, only tries to build openejb and tranql if those directories exist and enables the usage of the rebuild-all, build-all, build, clean, clean-all, eclipse and idea goals. I'll attach the patch files and copies of the updated files for testing before integrating the 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
Re: org.omg.CORBA.MARSHAL: java.lang.ClassCastException thrown while marshaling the reply
david, yes started working now. It was my mistake, didn't set CORBA SSL flags in JVM :) thanks akshay On Sat, 2005-11-26 at 13:12 -0800, David Jencks wrote: Unfortunately I can't give you any advice except to trace through the code to try to figure out what is going wrong. Are you fairly sure you have csiv2 set up on your c++ client compatible with the TSS setup you have specified? I would sort of expect a different exception if this is the problem, but it often seems to me that the sun corba implementation is written with the primary goal of concealing the cause of problems. Please keep us informed of your progress! thanks david jencks On Nov 26, 2005, at 6:49 AM, Panda, Akshaya Kumar ((Cognizant)) wrote: i think it didn't get posted earlier properly. forwarding again... Hi, I am trying to access a session bean deployed on Geronimo1.0M5 from a orbacus4.3.0 c++ client in fedora core3. 1. The client side corba url is: corbaname:iiop:[EMAIL PROTECTED]:1050#cts/sample/SampleSessionBean 2. The ejb deploment plan as follows: ?xml version=1.0 encoding=UTF-8? application xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-1.0; configId=SampleSession-configid parentId=org/apache/geronimo/ServerCORBA import uriorg/apache/geronimo/Security/uri /import module ejbCTS_SAMPLE_SESSION_GERONIMO.jar/ejb openejb-jar xmlns=http://www.openejb.org/xml/ns/openejb-jar-2.0; configId=ejb-SampleSessionBean-configid parentId=org/apache/geronimo/ServerCORBA enterprise-beans session ejb-nameSampleSessionBean/ejb-name jndi-namects/sample/SampleSessionBean/jndi-name tss-linkIdentityTokenNoSecurity/tss-link /session /enterprise-beans /openejb-jar /module /application 3. The orb-string_to_object() is successfull in client side and able to get the home reference. but the home-create() fails. The geronimo stack trace as follows: 12:14:48,102 INFO [Daemon] Server startup completed 12:14:54,635 DEBUG [ServerSecurityInterceptor] receive_request_service_contexts() 12:14:54,651 DEBUG [ServiceContextInterceptor] Looking for SSL Session 12:14:54,684 DEBUG [ServerSecurityInterceptor] receive_request(create [geronimo.server:EJBModule=ejb-SampleSessionBean- configid,J2EEApplication=null,J2EEServer=geronimo,j2eeType=StatelessSes sionBean,name=SampleSessionBean] 12:14:54,685 DEBUG [ServerSecurityInterceptor] Found server policy 12:14:54,711 DEBUG [ServerSecurityInterceptor] No security service context found 12:14:54,712 DEBUG [ServerSecurityInterceptor]Subject: Principal: public-properties-realm: [org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal: guest] Principal: public-properties-realm: [org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal: guest] 12:14:54,717 DEBUG [StandardServant] Calling create 12:14:54,884 DEBUG [ServerSecurityInterceptor] send_reply() 12:14:54,937 DEBUG [ClientSecurityInterceptor] Checking if target _is_a has a security policy 12:14:55,012 DEBUG [ClientSecurityInterceptor] Target has a security policy 12:14:55,020 DEBUG [ClientTransactionInterceptor] Checking if target _is_a has a transaction policy 12:14:55,020 DEBUG [ClientTransactionInterceptor] Target has a transaction policy 12:14:55,079 DEBUG [ServerSecurityInterceptor] receive_request_service_contexts() 12:14:55,079 DEBUG [ServiceContextInterceptor] Looking for SSL Session 12:14:55,079 DEBUG [ServerSecurityInterceptor] receive_request(_is_a [geronimo.server:EJBModule=ejb-SampleSessionBean- configid,J2EEApplication=null,J2EEServer=geronimo,j2eeType=StatelessSes sionBean,name=SampleSessionBean] 12:14:55,079 DEBUG [ServerSecurityInterceptor] Found server policy 12:14:55,079 DEBUG [ServerSecurityInterceptor] No security service context found 12:14:55,079 DEBUG [ServerSecurityInterceptor]Subject: Principal: public-properties-realm: [org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal: guest] Principal: public-properties-realm: [org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal: guest] 12:14:55,079 INFO [MappedServerTransactionPolicyConfig] No tx mapping for operation: _is_a 12:14:55,079 DEBUG [ServerSecurityInterceptor] send_reply() 12:14:55,097 DEBUG [Util] Exception in result copy org.omg.CORBA.MARSHAL: java.lang.ClassCastException thrown while marshaling the reply: null vmcid: 0x0 minor code: 0 completed: Yes at org.openejb.corba.CorbaApplicationServer.getEJBObject(CorbaApplicationS
Re: Does there need to be a default web container?
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1 X-MMS-Smtp-Auth: Authenticated As [EMAIL PROTECTED] X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1 I think the magic G-ball should be embedded in the installer and let it make a random choice for the user :) The answer is It is decidedly so. Matt Jeff Genender wrote: Then lets agree to disagree. We should probably take this offline if it needs to be discussed further. This is kind of off-topic. Jeff Aaron Mulder wrote: Sorry Jeff, I have to disagree. If you asked me whether you should use Tomcat or Jetty, I really couldn't give you an informed answer. About the best I could say is they both work fine in Geronimo, they do a couple things like virtual hosting slightly differently, and the Jetty team is actively involved in Geronimo whereas we pretty much built the Tomcat integration on our own. Still, that doesn't give you much guidance (the last bit there is the only reason I personally would have any preference at all). And I feel like I'm in the *most* informed 1% of all possible Geronimo users. I don't think it's sensible to argue over what average people know or don't know, it's just my feeling that if I can't make a clear decision for obvious reasons, then I can't ask every user who ever installs the product to make that same decision. Thanks, Aaron On 12/8/05, Jeff Genender [EMAIL PROTECTED] wrote: Erin Mulder wrote: Jeff Genender wrote: So you think your average Geronimo user will have no idea what a web container is? It's possible. I asked average user...not whether its possible. The average user will probably be a developer...who has done some degree of background on the technologies. I would hazard to guess there are few people who use BEA or Websphere and have absolutely no idea what a web container is. The developer will likely know what it is. I have a hard time with equating someone's clickety-click Mom with our average user...its ridicules, which was really what my previous response was directed towards. There are a lot of experienced J2EE developers out there who have only ever used full commercial stacks. Asking them to choose between two web containers is like asking them to choose EJB, MQ and Web Service implementations. They may pick Tomcat because they vaguely recognize the name, but having to make that choice will add anxiety to their install experience. I am sorry but I cannot agree here. I cannot believe there are many experienced *J2EE* developers who have no idea what a web container is. That is preposterous. Are there some? Sure - but I would say very few. However, in servlet 101...of which many of these un-knowledgable users would go, surely a mention of a web container, what it is, and what they can use (including books, articles, internet), they should have a minimal understanding of web containers. Geronimo is also likely to become popular in academic settings (both classroom and self-study) where people will need to install the server before they get around to learning what a web container is. The academic component is such a small microcosm in the grand scheme of users, this not even a reason to think its has a major effect of the overall user-base. We should push the direction of Geronimo towards what the community wants. If the community wants Jetty, give it to them. If they want Tomcat, then let them have this. Let the community decide. Cheers, Erin
