Geronimo Java EE 5.0 Report Card updated for 2.0-M4
I've updated the Geronimo Java EE 5.0 Report card on the wiki to reflect the latest 2.0-M4 information including milestone contents and package upgrades. http://cwiki.apache.org/GMOxPMGT/geronimo-java-ee-50-report-card.html Feel free to update any inaccuracies. -Dave-
Re: Context level clustering not supported in Tomcat it seems
Jeff Genender wrote: Dave Colasurdo wrote: IIUC the presence/absence of the distributable tag in web.xml also provides the same behavior. I gave this a quick test recently and it seemed to work that way. To a degree yes, but my understanding is all contexts would have the valves, manager, etc attached. Context level is clean IMHO. Thanks for the info Jeff! So, with "contexts" each clustered web application could have its own clustering characteristics such as which multicast address it uses etc.? -Dave-
Re: [Discussion] Geronimo web site update
Hernan Cunico wrote: Dave Colasurdo wrote: Looks great! A few minor nitpick comments on the website content: 1) Why are the guiding principles in blue text? At first glance, it makes it appear as though the items are links.. I know links are underlined.. though still seems odd. We already had them in blue in the original version, this blue shade is different form the links. The idea is to highlight these with the same tone as the banner bkground Still think it's confusing as many websites use "blue" to indicate unvisited hyperlinks. Of course, not a big deal since hovering removes any doubt. 2) Why are the news events in a table? Does the author field really provide any useful info to the user? These are automatically generated, a new way to keep the site up to date. Just click on "add news" (need to be a committer though) and the news will get populated on the home page, just 3 at a time. All the news will get stored either in events or news archive. Sounds like a great idea. Though not sure if the author info is really useful to users.. Are you saying the news items are limited to the last three that were added? That seems like a strange limitation. Seems all the relevant news should be available unless the volume of data gets too large.. Thanks -Dave-
Re: Context level clustering not supported in Tomcat it seems
Jeff Genender wrote: I'm trying to understand what advantage context attribute replication provides. Allows you to pick and choose which web apps are distributed and which are not. Example: There may be a mission critical app that needs clustering, but we most certainly wouldn't want to cluster the Geronimo web console. IIUC the presence/absence of the distributable tag in web.xml also provides the same behavior. I gave this a quick test recently and it seemed to work that way.
Re: Context level clustering not supported in Tomcat it seems
I'm still trying to understand what exactly this means to users of Geronimo/Tomcat. IIUC, enabling host/engine clustering basically means that all web applications on a particular host/engine that contain the distributable tag in their web.xml will replicate session state with other cluster members that use the same multicast address and are on the same subnet. Now for context attribute replication... Does this mean that a user can specify unique replication domain per individual web application from a common Tomcat/Geronimo installation? Or is it something different? I'm trying to understand what advantage context attribute replication provides. Thanks -Dave- Jeff Genender wrote: Shiva, Its supported but not the usual way. It uses a different context. We will need to change some of our code. Jeff Shiva Kumar H R wrote: Yes Filip, what we mean by Context-level (or application level) clustering is that the clustering configuration is specified in Tomcat's "context.xml" file. So this isn't supported right? I am dropping my idea of checking on Tomcat's mailing list and re-testing. -- Thx, Shiva On 3/1/07, *Filip Hanik - Dev Lists* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: maybe I misunderstood you, you are asking if you can shove the implementation in a context, the answer to that is no. 6 adds in support of clustering context attributes Filip Filip Hanik - Dev Lists wrote: > http://tomcat.apache.org/tomcat-6.0-doc/config/cluster.html > > Filip > > Shiva Kumar H R wrote: >> Is it! Is there some document that you are referring to? >> >> Meanwhile I will repost the query on Tomcat mailing list as well test >> context level clustering on Tomcat 6. >> >> -- >> Thx, >> Shiva >> >> On 2/28/07, *Filip Hanik - Dev Lists* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: >> >> Context level clustering is supported in TC 6 >> >> Shiva Kumar H R wrote: >> > As part of https://issues.apache.org/jira/browse/GERONIMO-2577 <https://issues.apache.org/jira/browse/GERONIMO-2577> >> I had >> > opened the following bug in Tomcat: >> > "Context level clustering on 3 or more nodes fails in Tomcat >> 5.5.20 >> > http://issues.apache.org/bugzilla/show_bug.cgi?id=41620 >> <http://issues.apache.org/bugzilla/show_bug.cgi?id=41620>" >> > >> > They have closed the bug as "Resolved Invalid" with the following >> > comments: >> > --- /Additional Comment #7 >> > < http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#c7> >> From Mark >> > Thomas <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED]>>> >> 2007-02-15 18:54 / [reply >> > < >> >> http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#add_comment <http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#add_comment>>] >> > --- >> > It is not possible to configure clustering in context.xml. It >> must be done at >> > the Host level (with the jvmRoute defined at the Engine level) >> within server.xml >> > That makes our default clustering article >> > >> http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html <http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html> >> > invalid. Should we now remove it saying that "Geronimo (Tomcat >> > version) supports clustering at the Host/Engine level only"? >> > >> > Dave Colasurdo and myself have already created a new article >> > illustrating how to setup Geronimo (Tomcat version) clustering >> at the >> > host/engine level: >> > >> >> http://cwiki.apache.org/GMOxDOC11/clustering-sample-application-tomcat-host-level.html >> >> >> < http://cwiki.apache.org/GMOxDOC11/clustering-sample-application-tomcat-host-level.html>. >> >> > Please suggest if we should retain only this and delete the other >> > article on context level clustering? >> > >> > -- Shiva >> > >> >> >> >> > >> > No virus found in this incoming message. >> > Checked by AVG Free Edition. >> > Version: 7.5.441 / Virus Database: 268.17.37/682 - Release Date: >> 2/12/2007 1:23 PM >> > >> >> >> >> >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.446 / Virus Database: 268.18.4/705 - Release Date: >> 2/27/2007 3:24 PM >> > > >
Re: [Discussion] Geronimo web site update
Looks great! A few minor nitpick comments on the website content: 1) Why are the guiding principles in blue text? At first glance, it makes it appear as though the items are links.. I know links are underlined.. though still seems odd. 2) Why are the news events in a table? Does the author field really provide any useful info to the user? 3) The news archive contains the "current events" in a different format. That seems strange.. I would expect this to contain only the older stale stuff.. 4) The archive button should be more closely located to the news itself. 5) Why is JIRA top ten on the front page. Seems this should be on a supporting page.. 6)The link to the wiki provides the correct wiki main page.. Though all the links on that page are dead.. Thanks -Dave- Hernan Cunico wrote: alright, I'm done with the updates. Finally moved all the content over. I will be calling a vote for changing the authoring tool from ant scripts and xdocs to confluence. This is the link to the migrated site http://geronimo.apache.org/newsite/ it gets updated 5 mins after every hour Cheers! Hernan Jason Dillon wrote: I put the edit links back on, I think they are helpful for use the site maintainers... especially since the links are not directly convertible from exported back to the confluence page. --jason On Feb 28, 2007, at 6:37 AM, Hernan Cunico wrote: nice! I'll probably be done with the updates today. Cheers! Hernan Jason Dillon wrote: FYI, its up now: http://geronimo.apache.org/newsite/ --jason On Feb 27, 2007, at 1:39 PM, Hernan Cunico wrote: Jason Dillon wrote: On Feb 27, 2007, at 12:24 PM, Hernan Cunico wrote: Jason Dillon wrote: On Feb 27, 2007, at 6:35 AM, Hernan Cunico wrote: yup, links look better now. What's the trick? are you massaging the pages during the rsync? Nope... Just rsycn -tr src/ dest/ hmm, I was wondering how different would it be from the one Jeff T is running. See his copies still point to cwiki. Um... huh? As for the account, I think there is already a discussion on infra@ for creating/securing a "confluence" based account on p.a.o Thats only to replace jeffs account, we still need an account setup to sync to /www/geronimo.apache.org oh, so we would need a confluence-Geronimo specific account on p.a.o. no idea how to make that req. nor how to maintain that account. No, infra is not going to setup a user for this... we just need to run it as me or you or someone. we'll toss a coin then :P ... Are you working on a new template? I think for now the template is okay, only changes might be to loose the tabs. I whacked the top right menu already, I guess we could also get rid of the other tabs too. Two things keep spinning in my head, one is the JIRAs on the front page. I really don't like the tables there, if we want it more dynamic let's find another way. The other thing is the "News" and how we use them. We can't use the "Add News" to inform about future events, the whole thing is tied up to the date the new was posted. So, any ideas how could we manage the "Events"? Maybe use one of the calendar plugins for confluence for events? The calendar plugin is really cool but guess what, doesn't cope very well with the autoexport. I'll keep playing with it, it's really nice :D Cheers! Hernan --jason
Re: Context level clustering not supported in Tomcat it seems
Agreed. If Tomcat can't claim support for this scenario then neither should Geronimo. Feel free to remove the "context clustering" article. We may need Hernan to help here as I suspect there are two copies of the article.. One in actual source and one via export.. Thanks -Dave- Jeff Genender wrote: Yep...I would update the Wiki and state Host/Engine only. Jeff Shiva Kumar H R wrote: As part of https://issues.apache.org/jira/browse/GERONIMO-2577 I had opened the following bug in Tomcat: "Context level clustering on 3 or more nodes fails in Tomcat 5.5.20 http://issues.apache.org/bugzilla/show_bug.cgi?id=41620"; They have closed the bug as "Resolved Invalid" with the following comments: --- /Additional Comment #7 <http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#c7> From Mark Thomas <mailto:[EMAIL PROTECTED]> 2007-02-15 18:54 / [reply <http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#add_comment>] --- It is not possible to configure clustering in context.xml. It must be done at the Host level (with the jvmRoute defined at the Engine level) within server.xml That makes our default clustering article http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html invalid. Should we now remove it saying that "Geronimo (Tomcat version) supports clustering at the Host/Engine level only"? Dave Colasurdo and myself have already created a new article illustrating how to setup Geronimo (Tomcat version) clustering at the host/engine level: http://cwiki.apache.org/GMOxDOC11/clustering-sample-application-tomcat-host-level.html. Please suggest if we should retain only this and delete the other article on context level clustering? -- Shiva
Clustering Geronimo with Open Terracotta
I've added an article to the Geronimo wiki that describes how to cluster Geronimo HTTP Session web application data using the Open Terracotta project. http://cwiki.apache.org/GMOxDEV/clustering-geronimo-with-open-terracotta.html Feel free to get it a try.. Also, the clustering articles in the wiki were recently reorganized (Thanks Hernan) to be rooted on a common page.. http://cwiki.apache.org/GMOxDEV/clustering.html Though I suspect the "Clustering - Initial Discussion" article on this page is somewhat stale.. -Dave-
Re: Geronimo v2.0 Documentation - Topics to cover
I suspect the Milestone 2 items on the page you referenced is out of date. The most recent info is contained in the 2.0-M2 Release Notes. -Dave- Hernan Cunico wrote: Hi All, I'm updating the existing Geronimo documentation to v2.0, here is the link. http://cwiki.apache.org/GMOxDOC20/documentation.html Are there any specific topics that you guys would like to see covered for v2.0 first? Are there any topics from previous releases you guys don't want to see anymore? Cheers! Hernan
Re: Release Notes for 2.0-M2 - Limitations and Issues Fixed sections
Agreed.. Seems like the list still has some stale entries and should be refreshed.. Here is a link to the current refreshed list. http://cwiki.apache.org/confluence/display/GMOxSBOX/Test13 BTW, the query being used here is the one that Hernan created for 2.0-M2 and is contained in the source of this wiki page. Thanks -Dave- Vamsavardhana Reddy wrote: I am noticing that "Known Issues and Limitations" section still lists some (atleast one, G-2745) JIRAs that have been addressed. "Known Issues and Limitations" and "Specific Issues, Features and Improvements fixed in Version 2.0-M2" sections need review. Vamsi
Re: Release Notes for 2.0-M2 - EJB content
Thanks... Have included the MDB restriction in the latest attachment. BTW, The version in the 2.0-M2 branch is quite stale. Can someone please refresh the copy at: https://svn.apache.org/repos/asf/geronimo/server/branches/2.0-M2/RELEASE-NOTES-2.0-M2.TXT with the included attachment. All future changes can then occur in the branch.. Thanks -Dave- David Blevins wrote: On Jan 26, 2007, at 5:46 AM, Dave Colasurdo wrote: Thanks... Have made the updates... Is there anything that should be added to the limitations section? One of the things I mentioned in another email is that MDBs are completely untested and should be assumed non-functional. Do we fully support EJB 3.0? :) -David -Dave- David Blevins wrote: On Jan 25, 2007, at 11:03 AM, Dave Colasurdo wrote: Limitations: - Undeploying an ejb module will not remove it's beans. The server has to be restarted to deploy the same module again. Ok, I've implemented undeploy and verified it works using the calculator sample app. I can guarantee there are leaks here (there always are the first few iterations), but the feature is functional. - Extended JNDI and DI types This works. If your env-entry-type is java.lang.String and we see you have a URL, for example, we will convert the value to a URL before injection. -David Release Notes -- Apache Geronimo -- Version 2.0 - Milestone 2 Geronimo URLs - Home Page: http://geronimo.apache.org/ Downloads: http://geronimo.apache.org/downloads.html Documentation: http://geronimo.apache.org/documentation.html Mailing Lists: http://geronimo.apache.org/mailing.html Source Code: http://geronimo.apache.org/svn.html Bug Tracking: http://issues.apache.org/jira/browse/GERONIMO Wiki: http://cwiki.apache.org/geronimo IMPORTANT - This is a Milestone release, that means that is not the final version of Apache Geronimo v2.0 Take a look at "Known Issues and Limitations" section for further details. System Requirements --- You need a platform that supports the Sun JDK 5.0+ (J2SE 1.5.0+). Most testing has been done on Linux, Mac OS X, and Windows. Significant Changes in the 2.0-M2 Release - - Java EE management 1.1 - EJB 3.0 support (via OpenEJB integration) - Web Services technologies - STAX 1.0 Streaming API for XML (JSR 173) - JAXB 2.0 - Java Architecture for XML Binding - JAX-WS 2.0 support is provided in this milestone. Only POJO based JAX-WS services are supported. (CXF integration) - JAX-RPC 1.1 (POJO Only) - JAXR 1.0 - Addition to admin console that allows users to graphically view classloader hierarchy, JNDI tree and module dependencies *See "Functional Characteristics" section below for more details on the new functions. Significant Changes in the 2.0-M1 Release (prior milestone) --- - Full Sun JDK 5.0+ (J2SE 1.5.0+) - Servlet 2.5 (Tomcat) - JSP 2.1 (Tomcat) - JSP Debug 1.0 (Tomcat) - Servlet 2.5 (Jetty) - JSP 2.1 (Jetty - via Jasper) - JSP Debug 1.0 (Jetty) - JSF 1.2 (JSF applications won't execute) - JSTL 1.2 - Common Annotations 1.0 - JAF 1.1 - JavaMail 1.4 - EJB 3.0 (JPA only) - JTA 1.1 - JMS 1.1 - JACC 1.1 Functional Characteristics for 2.0-M2 - - EJB 3.0 (via OpenEJB project) Supported: - JPA (Custom Provider, App-managed, Container-managed) (Also supported in 2.0-M1) - POJO as a Business Interface (both local and remote) - POJO Session EJBs - Deployment without ejb-jar.xml or openejb-jar - geronimo-openejb.xml file not required unless you have geronimo specific information to configure - Deployment of annotated beans (@Stateful and @Stateless) - Injection via deployment descriptor - @Resource injection for env-entries, resource-refs, message-destinations, service-refs, most resource-env-refs - @EJB injection of ejb-refs and ejb-local-refs - @PersistenceContext injection - @PersistenceUnit injection - JNDI references to the ejb - JNDI references from the ejb - Transaction support - Legacy component (i.e. home) interfaces on a Pojo session bean - Xml-based *and* annotation-based injection for ejbs, except for message-destinations, or SessionContext when the field or setter is not named setSessionContext - References to business interfaces, local or remote, from a servlet or an ejb - References to home interfaces, local or remote, from a servlet or an ejb - Extended JNDI and DI types Simple EJB 3.0 example application available at: http://cwiki.apache.org/confluence/display/GMOxDOC20/Using+some+of+EJB+3.0+functionalities Limitations: - Undeploying an ejb module will not remove it's beans. The server has to be restarted to deploy the same mo
Re: Release Notes for 2.0-M2 - EJB content
Ok, have added back the restriction regarding undeploying ejb modules for 2.0-M2. Attaching the latest release notes to this email. Please verify the eol characters are in the correct format.. Matt will add the Release Notes to the official build. -Dave- Prasad Kashyap wrote: Two issues here - 1) Dain's fixes are in trunk. They have not been merged with the M2 changes yet. So at the moment, the M2 has these limitations. 2) This is a bigger issue. I don't see the Release Notes in the unpacked server !!! Cheers Prasad On 1/26/07, Kevan Miller <[EMAIL PROTECTED]> wrote: On Jan 26, 2007, at 8:46 AM, Dave Colasurdo wrote: > Thanks... Have made the updates... Well, we need to be sure these changes are included in M2. I'm not sure where Matt is in terms of building an RC. --kevan > > Is there anything that should be added to the limitations section? > Do we fully support EJB 3.0? > > -Dave- > > David Blevins wrote: >> On Jan 25, 2007, at 11:03 AM, Dave Colasurdo wrote: >>>Limitations: >>> - Undeploying an ejb module will not remove it's beans. The >>> server has to be restarted to deploy the same module again. >> Ok, I've implemented undeploy and verified it works using the >> calculator sample app. I can guarantee there are leaks here >> (there always are the first few iterations), but the feature is >> functional. >>> - Extended JNDI and DI types >> This works. If your env-entry-type is java.lang.String and we see >> you have a URL, for example, we will convert the value to a URL >> before injection. >> -David Release Notes -- Apache Geronimo -- Version 2.0 - Milestone 2 Geronimo URLs - Home Page: http://geronimo.apache.org/ Downloads: http://geronimo.apache.org/downloads.html Documentation: http://geronimo.apache.org/documentation.html Mailing Lists: http://geronimo.apache.org/mailing.html Source Code: http://geronimo.apache.org/svn.html Bug Tracking: http://issues.apache.org/jira/browse/GERONIMO Wiki: http://cwiki.apache.org/geronimo IMPORTANT - This is a Milestone release, that means that is not the final version of Apache Geronimo v2.0 Take a look at "Known Issues and Limitations" section for further details. System Requirements --- You need a platform that supports the Sun JDK 5.0+ (J2SE 1.5.0+). Most testing has been done on Linux, Mac OS X, and Windows. Significant Changes in the 2.0-M2 Release - - Java EE management 1.1 - EJB 3.0 support (via OpenEJB integration) - Web Services technologies - STAX 1.0 Streaming API for XML (JSR 173) - JAXB 2.0 - Java Architecture for XML Binding - JAX-WS 2.0 support is provided in this milestone. Only POJO based JAX-WS services are supported. (CXF integration) - JAX-RPC 1.1 (POJO Only) (Only tested in CXF environment) - JAXR 1.0 - Addition to admin console that allows users to graphically view classloader hierarchy, JNDI tree and module dependencies *See "Functional Characteristics" section below for more details on the new functions. Significant Changes in the 2.0-M1 Release (prior milestone) --- - Full Sun JDK 5.0+ (J2SE 1.5.0+) - Servlet 2.5 (Tomcat) - JSP 2.1 (Tomcat) - JSP Debug 1.0 (Tomcat) - Servlet 2.5 (Jetty) - JSP 2.1 (Jetty - via Jasper) - JSP Debug 1.0 (Jetty) - JSF 1.2 (JSF applications won't execute) - JSTL 1.2 - Common Annotations 1.0 - JAF 1.1 - JavaMail 1.4 - EJB 3.0 (JPA only) - JTA 1.1 - JMS 1.1 - JACC 1.1 Functional Characteristics for 2.0-M2 - - EJB 3.0 (via OpenEJB project) Supported: - JPA (Custom Provider, App-managed, Container-managed) (Also supported in 2.0-M1) - POJO as a Business Interface (both local and remote) - POJO Session EJBs - Deployment without ejb-jar.xml or openejb-jar - geronimo-openejb.xml file not required unless you have geronimo specific information to configure - Deployment of annotated beans (@Stateful and @Stateless) - Injection via deployment descriptor - @Resource injection for env-entries, resource-refs, message-destinations, service-refs, most resource-env-refs - @EJB injection of ejb-refs and ejb-local-refs - @PersistenceContext injection - @PersistenceUnit injection - JNDI references to the ejb - JNDI references from the ejb - Transaction support - Legacy component (i.e. home) interfaces on a Pojo session bean - Xml-based *and* annotation-based injection for ejbs, except for message-destinations, or SessionContext when the field or setter is not named setSessionContext - References to business interfaces, local or remote, from a servlet or an ejb - Referenc
Re: Release Notes for 2.0-M2 - EJB content
Thanks... Have made the updates... Is there anything that should be added to the limitations section? Do we fully support EJB 3.0? -Dave- David Blevins wrote: On Jan 25, 2007, at 11:03 AM, Dave Colasurdo wrote: Limitations: - Undeploying an ejb module will not remove it's beans. The server has to be restarted to deploy the same module again. Ok, I've implemented undeploy and verified it works using the calculator sample app. I can guarantee there are leaks here (there always are the first few iterations), but the feature is functional. - Extended JNDI and DI types This works. If your env-entry-type is java.lang.String and we see you have a URL, for example, we will convert the value to a URL before injection. -David
Re: Release Notes for 2.0-M2 - EJB content
Ok, have clarified this in the release notes.. Thanks -Dave- Dain Sundstrom wrote: On Jan 25, 2007, at 11:03 AM, Dave Colasurdo wrote: - Deployment with no ejb-jar.xml or openejb-jar (just need a geronimo-openejb.xml for all the geronimo-specific deployment stuff) To be clear, the geronimo-openejb.xml file is only required if you have some geronimo specific stuff that must be configured. In general you don't need one. -dain
Release Notes for 2.0-M2 - EJB content
I'm helping Hernan update the Release Notes for 2.0-M2. Can folks please provide feedback for the EJB Content that gets documented in the Release Notes. Here is the current content.. - EJB 3.0 (via OpenEJB project) Supported: - JPA (Custom Provider, App-managed, Container-managed) (Also supported in 2.0-M1) - POJO as a Business Interface (both local and remote) - POJO Session EJBs - Deployment with no ejb-jar.xml or openejb-jar (just need a geronimo-openejb.xml for all the geronimo-specific deployment stuff) - Deployment of annotated beans (@Stateful and @Stateless) - Injection via deployment descriptor - @Resource injection for env-entries, resource-refs, message-destinations, service-refs, most resource-env-refs - @EJB injection of ejb-refs and ejb-local-refs - @PersistenceContext injection - @PersistenceUnit injection - JNDI references to the ejb - JNDI references from the ejb - Transaction support - Legacy component (i.e. home) interfaces on a Pojo session bean - Xml-based *and* annotation-based injection for ejbs, except for message-destinations, or SessionContext when the field or setter is not named setSessionContext - References to business interfaces, local or remote, from a servlet or an ejb - References to home interfaces, local or remote, from a servlet or an ejb Limitations: - Extended JNDI and DI types - Undeploying an ejb module will not remove it's beans. The server has to be restarted to deploy the same module again. Thanks -Dave-
Java EE Mgmt 1.1 available in 2.0-M1?
Anita, I noticed you updated the Java EE 5.0 Report card to mark Java EE Mgmt 1.1 as available in 2.0-M1. Is the geronimo work complete for this specification? Chris, Is there any other required work that you were tracking before marking this as complete on the roadmap? Thanks -Dave- anita kulshreshtha wrote: Are we not including J2EE Management 1.1 in this list because of JSR77.3.5.0.1 - deploymentDescriptor? Thanks Anita --- [EMAIL PROTECTED] wrote: Author: hogstrom Date: Sun Dec 17 21:53:00 2006 New Revision: 488131 URL: http://svn.apache.org/viewvc?view=rev&rev=488131 Log: Added RELEASE notes to assembly Added: geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt (with props) Added: geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt?view=auto&rev=488131 == --- geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt (added) +++ geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt Sun Dec 17 21:53:00 2006 @@ -0,0 +1,265 @@ +Release Notes -- Apache Geronimo -- Version 2.0 - Milestone 1 + +Geronimo URLs +- +Home Page: http://geronimo.apache.org/ +Downloads: http://geronimo.apache.org/downloads.html +Documentation: http://geronimo.apache.org/documentation.html +Mailing Lists: http://geronimo.apache.org/mailing.html +Source Code: http://geronimo.apache.org/svn.html +Bug Tracking: http://issues.apache.org/jira/browse/GERONIMO +Wiki: http://cwiki.apache.org/geronimo + + +IMPORTANT +- +This is a Milestone release, that means that is not the final version of +Apache Geronimo v2.0 Take a look at "Known Issues and Limitations" section for +further details. + +System Requirements +--- +You need a platform that supports the Sun JDK 5.0+ (J2SE 1.5.0+). + +Most testing has been done on Linux, Mac OS X, and Windows. + + +Significant Changes in the 2.0 Release +-- +Apache Geronimo v2.0 includes the following features: + +- Full Sun JDK 5.0+ (J2SE 1.5.0+) +- Servlet 2.5 (Tomcat) +- JSP 2.1 (Tomcat) +- JSP Debug 1.0 (Tomcat) +- Servlet 2.5 (Jetty) +- JSP 2.1 (Jetty - via Jasper) +- JSP Debug 1.0 (Jetty) +- JSF 1.2 +- JSTL 1.2 +- Common Annotations 1.0 +- JAF 1.1 +- JavaMail 1.4 +- EJB 3.0 (JPA only) +- JTA 1.1 +- JMS 1.1 +- JACC 1.1 + +Installing & Starting Geronimo +-- +To install, simply unpack the .zip (Windows) or tar.gz (Unix) file containing +Geronimo. + +If you wish to modify the default ports that Geronimo will use, edit the file +/var/config/config.xml + +Geronimo comes with batch and script files to control server start and stop +functions. To see usage examples simply type geronimo.bat or geronimo.sh +command as appropriate for your platform. It is necessary to set JAVA_HOME to +the copy of your Sun 5 JDK/JRE prior to executing the command. + +Here is an example to set JAVA_HOME: + +export JAVA_HOME= + +To see the available command options type: + +/bin/geronimo.sh +or +/bin/geronimo.bat + +The command will display help text instructing you as to how to start and stop +the Geronimo server. + +If you prefer to start the server without a script file you can simply type: + +java -jar /bin/server.jar + +Once the server has started, you can access the Geronimo Administration Console +at http://localhost:8080/console/ . The default user name is "system" and the +default password is "manager". + + +Administration Console Security Configuration +- +The default administration user/password for the Geronimo Administration Console +and deployment tool is system/manager. You can change these defaults directly +from the Geronimo Administration Console by accessing Security -> Console Realm +and change the user name and password from the Console Realm Users portlet. + +As an alternative, you can make the same changes by editing the +/var/security/users.properties and +/var/security/groups.properties files. + + +Deploying Applications +-- +Geronimo comes with deploy scripts and batch files to deploy J2EE modules or +applications. You can use the scripts or simply invoke the executable jar by +running the following command (note that you need to start Geronimo first): + +/bin/java -jar deployer.jar deploy my-web-app.war [deploy plan] + +You will need to use the username "system" and password "manager" unless you +customized those during the install process. The deployment plan argument is +optional -- y
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=comments#action_12459757 ] Dave Colasurdo commented on GERONIMO-2577: -- I have seen clustering fail in multicast mode when the physical machines were not on the same subnet... Even when you plug machines into adjacent wallports, oftentimes the subnets are different. That would be my first guess.. Lots more questions :) 5) I've heard that this same scenario works for you when using Tomcat w/o Geronimo. Did you run the tomcat test on the same exact same three machines as the geronimo test? 6) Are you certain that config.xml has a unique nodename (i.e jvmRoute)for each of the three nodes? 7) Are you certain that the IP addresses are unique (and correct) in the deployment plan for each node? 8) Can you provide all three deployment plans (one for each node)? 9) Any particular reason you set useDirtyFlag=true? 10) I see that you removed the mcastBindAddress setting in the deployment plan. I've heard differing information on whether or not this is needed. Have you tried setting this field in each of the nodes? 11) Have you tried removing waitForAck=true and using ackTimeout for the test? Thanks -Dave- > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are
Java EE 5.0 Report Card updated
The Java EE 5.0 Report card has been updated on the project wiki. This update incorporates all the recent 2.0-M1 activity and other recent developments relating to Java EE 5.0. Please take a second to review it for accuracy. http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+Java+EE+5.0+Report+Card Thanks -Dave-
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=comments#action_12459700 ] Dave Colasurdo commented on GERONIMO-2577: -- 1) Is node c (the failing node) always the same physical machine? 2) Are you 100% certain that all three nodes are on the same subnet? This is extremely important.. Applying the subnet mask to each nodes IP address should yield the exact same network portion of the IP address. 3) Have you added thetag to the web.xml for each clustered app? 4) Can you please elaborate on the following statement ..."When replication module is SimpleTcpReplicationManager, the geronimo cluster can continue the process." What exactly does that mean? What replication module are you using? Thanks > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D2
Wiki Update for Gcache
Here is an initial stab at documenting how to use Gcache with Geronimo for clustering. http://cwiki.apache.org/confluence/display/GMOxDEV/Geronimo+Clustering+with+Gcache The article still needs a bit of work and will be updated as the Gcache development effort progresses in the sandbox. Though wanted to share the current content with others. Feedback welcome.. Thanks -Dave-
Re: Web Service Sample Application
That would be awesome.. Thanks!! I'm unaware of anyone else working on this. -Dave- Lasantha Ranaweera wrote: Hi All, I saw there is an empty sample application under web services section in Geronimo user guide. Does anybody working on that? I would like to contribute on that. Thanks, Lasantha Ranaweera
Re: Release Early, Release Often
Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc.. http://en.wikipedia.org/wiki/Alpha_release The definitions pretty much agree with my preconception of what an Alpha would contain. IMHO, trunk is not currently in an Alpha state and doesn't accurately reflect the "majority of the software requirements" that will be addressed in G1.2. It seems that trunk is currently in a pre-alpha state and I believe making an occasional unstable/nightly build available would allow users/developers to get familiar with the latest and greatest functions in trunk without giving the false impression that G1.2 is currently in Alpha state. Just my .02 -Dave- Jason Dillon wrote: I am thinking about an 1.2-alpha release, which does not need to pass any tck, but can still be downloaded by folks that want to test their apps on the bleeding edge (with out having to build). While there is nothing major from a J2EE perspective in the alpha, a lot has changed, or will change very shortly. Here is a list with comments of new and upcoming stuff: ActiveMQ 4.1, is about to get committed. Derby is about to get upgraded. Log4j is about to get upgraded. Use of concurrent util is about to get changed to backport-concurrent-util. Lets not forget that we changed the build system, which mostly impacts development, but also has an impact on the configuration files, and plugins... new CAR m2 plugin. I think it would be really good to get an alpha out so that people can easily test and provide feedback. New m2 plugin to start/stop Geronimo, soon to have new deploy goals. A bunch of bug fixes. * * * I think that by releasing a 1.2-alpha, that we also start down the path of changing the perception of how quickly we release. The alpha can also serve to help us get some experience using the m2 release plugin so that when it comes time for a non-alpha/beta release that we have confidence in the procedure... and this will give us time to make sure that we have the right configurations and setup to make a release with relative ease. Also, more of a side effect, by making a new release, it helps control the JIRA roadmap, right now 1.2 is filled with a bunch of build system related fluff and other bits... I think that we have enough changes (or soon to change in the next days or so) to warrant an alpha. I don't see any reason why not to... we don't need to spend days/weeks to ensure the TCK passes, because we don't need to run it. It should be sufficient to vote on an alpha and then cut the release, which should be easy with the maven release plugin, and even easier with my gpg-sign'ing mojo to sign and upload all artifacts. I believe that having this alpha out will benefit our community, showing that we are going to start releasing more often, give people a chance to provide feedback more often an earlier. I certainly do not expect any production customers to use this, but I do expect that app developers will, so they can ready their apps for deployment on the platform. We will clearly label this as an alpha release, and clear state that it has not been TCK certified. I don't see any downside to cutting a release off of trunk soonish, in the next week or so. --jason On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote: On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote: According to our STATUS file, our last feature release (1.1) was on 2006-06-26 which is about 2.5 months ago. I'm not sure exactly what we have in trunk right now, but I'd guess we most likely have enough to do a release right now. I'm going to spend a few hours today browsing the JIRAs and SVN logs and compile a list of the features we have in trunk right now. Anyways, I'll let you know what I find and we can figure out what we want to do. I'd be interested to hear more concretely what's in Geronimo trunk, OpenEJB 2.2, etc that's not in 1.1.1... --kevan
Re: [VOTE] 1.1.1-rc2 Release
I assume you made a conscious choice not to remove the zero length dtd files in the binary distributions? -Dave- > It appears there are a bunch of zero length dtd files in the /schema directory > > application-client_1_2.dtd > application-client_1_3.dtd > application_1_2.dtd > application_1_3.dtd > connector_1_0.dtd > ejb-jar_1_1.dtd > ejb-jar_2_0.dtd > web-app_2_2.dtd > web-app_2_3.dtd > web-jsptaglibrary_1_1.dtd > web-jsptaglibrary_1_2.dtd Matt Hogstrom wrote: The changes pointed out by Bill have been incorporated (crossing my fingers). I have not received any other comments so I'm hoping that others have looked. Please review these items and cast your votes in this thread. Thanks in advance for your time and attention. Vote ends Monday morning at 0600 Eastern Time. If there are issues in advance of that date a new RC will be spun up and a new vote started. *Source* http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-1.1.1-rc2-src.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-1.1.1-rc2-src.zip *Specifications* http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-j2ee-jacc_1.0_spec-1.1.1-rc2.jar http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-schema-j2ee_1.4-1.0-src.jar http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-schema-j2ee_1.4-1.0.jar *Distributions* http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty-j2ee-1.1.1-rc2.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty-j2ee-1.1.1-rc2.zip http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty-minimal-1.1.1-rc2.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty-minimal-1.1.1-rc2.zip http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat-j2ee-1.1.1-rc2.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat-j2ee-1.1.1-rc2.zip http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat-minimal-1.1.1-rc2.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat-minimal-1.1.1-rc2.zip *Other Items* http://people.apache.org/~hogstrom/1.1.1-rc2/openejb-builder-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc2/openejb-core-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc2/openejb-pkgen-builder-2.1.1.jar
Re: [VOTE] 1.1.1-rc1 for Release
It appears there are a bunch of zero length dtd files in the /schema directory application-client_1_2.dtd application-client_1_3.dtd application_1_2.dtd application_1_3.dtd connector_1_0.dtd ejb-jar_1_1.dtd ejb-jar_2_0.dtd web-app_2_2.dtd web-app_2_3.dtd web-jsptaglibrary_1_1.dtd web-jsptaglibrary_1_2.dtd -Dave- Matt Hogstrom wrote: CTS is complete and here is the RC1 for your reviewing pleasure. Please send your comments to the dev@geronimo.apache.org list. If there are no negative comments after Monday, September 5th at 0900 ET. We'll move this to be the final and release it. If there are issues, they will be addressed and another e-mail will be issued resetting for an rc2 vote. Thanks. *Source* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1-src.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1-src.zip *Specifications* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-j2ee-jacc_1.0_spec-1.1.1.jar *Schemas* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema-j2ee_1.4-1.0-src.jar http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema-j2ee_1.4-1.0.jar *Distributions* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-minimal-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-minimal-1.1.1-rc1.zip If you want to build you will need these jars also (will be released simultaneously with Geronimo) and these need to be placed in your local Maven repository. *OpenEJB Jars* http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-builder-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-core-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-pkgen-builder-2.1.1.jar
Re: JEE 5.0 Report Card
I've reorganized the JEE 5.0 report card a bit and updated it with the latest info relating to the spec levels and available packages. See: http://cwiki.apache.org/GMOxPMGT/geronimo-jee-50-report-card.html Please take a few minutes to review and comment/update as appropriate. Thanks -Dave- David Klavon wrote: There has been a couple of requests on the user list about where Geronimo is in regard to moving to JEE 5.0. I started a 'JEE 5.0 Report Card' in the wiki in an attempt to capture all of the JEE 5.0 JSRs, and communicate where Geronimo plans to gain support for the various spec upgrades. Some of the packages listed are just ideas at this point in order to launch further discussion. Given that the JEE 5.0 rollout is expected to be implemented across several months and releases, it would be helpful to keep this chart updated as each JSR is addressed so our users know our rollout plan. Take a look... comments for improvement are welcomed. http://cwiki.apache.org/GMOxPMGT/geronimo-jee-50-report-card.html Dave
Re: Where is the source code for the G samples ?
A quick history... The Tomcat level for G1.1 was 5.5.15... However, the CSS vulnerability that was identified in http://issues.apache.org/jira/browse/GERONIMO-1540 wasn't fixed in Tomcat until 5.5.16. G1.1 was scheduled for release prior to 5.5.16...so we took 5.5.15 and extracted this additional CSS fix from "head", applied our geronimo custom fixes (as identified in GERONIMO-1299) and rebuilt Tomcat and published the resulting example wars.. So.. the source you want is probably 5.5.16 or later.. Best I can tell SVN link is rooted at: http://svn.apache.org/repos/asf/tomcat/container/tags/tc5.5.x/ (tagged releases) http://svn.apache.org/repos/asf/tomcat/current/tc5.5.x (open branch.. it's really there for extraction though does not show up in a browser window) After extraction the examples are located at: tomcat/servletapi/jsr152/examples and tomcat/servletapi/jsr154\examples IIRC, JDK5 was required to build the tree.. -Dave- Matt Hogstrom wrote: Dave Colasurdo did the workDave? Jason Dillon wrote: Where in tomcat? Got a SVN URL handy? --jason On Aug 16, 2006, at 12:47 PM, Dave Colasurdo wrote: We grabbed the jars from Tomcat, unpacked them and manually made a few changes to them (outside of source control) and published the resulting wars. Here is the description of the manual changes: http://issues.apache.org/jira/browse/GERONIMO-1299 -Dave- Matt Hogstrom wrote: Aaron, Its soming clearer now...I think we grabbed the jars straight from Tomcat. Aaron Mulder wrote: On 8/16/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I think they were removed from Geronimo as part of the plugins work. Aaron provides the samples as plugins now. Perhaps we need to have them in G as well due to the issues you are tracking. I think it made sense to move them previously but sounds like there are reasons to keep them in both places. Nope. I just took them out of the assemblies. I didn't change the way that they were built, other than to add the geronimo-plugin.xml to the various config/ modules. I've never seen the source for these examples. Didn't the JARs just pop off of Zeus' leg or something? Thanks, Aaron Prasad Kashyap wrote: > Does anybody know where I can find the source code for the geronimo > samples, jsp-examples and tomcat-examples ? > > We are using these in our builds from this repository > http://people.apache.org/repo/m1-snapshot-repository/geronimo-samples/wars/ > > We should archive the classes dirs in these wars just like we do to > the apps in our build. When these examples wars are used in our build > as is, there is a good possibility that it might hit the long path > limit on windows. > > Cheers > Prasad > > >
Re: Where is the source code for the G samples ?
We grabbed the jars from Tomcat, unpacked them and manually made a few changes to them (outside of source control) and published the resulting wars. Here is the description of the manual changes: http://issues.apache.org/jira/browse/GERONIMO-1299 -Dave- Matt Hogstrom wrote: Aaron, Its soming clearer now...I think we grabbed the jars straight from Tomcat. Aaron Mulder wrote: On 8/16/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I think they were removed from Geronimo as part of the plugins work. Aaron provides the samples as plugins now. Perhaps we need to have them in G as well due to the issues you are tracking. I think it made sense to move them previously but sounds like there are reasons to keep them in both places. Nope. I just took them out of the assemblies. I didn't change the way that they were built, other than to add the geronimo-plugin.xml to the various config/ modules. I've never seen the source for these examples. Didn't the JARs just pop off of Zeus' leg or something? Thanks, Aaron Prasad Kashyap wrote: > Does anybody know where I can find the source code for the geronimo > samples, jsp-examples and tomcat-examples ? > > We are using these in our builds from this repository > http://people.apache.org/repo/m1-snapshot-repository/geronimo-samples/wars/ > > We should archive the classes dirs in these wars just like we do to > the apps in our build. When these examples wars are used in our build > as is, there is a good possibility that it might hit the long path > limit on windows. > > Cheers > Prasad > > >
Re: Where is the source code for the G samples ?
IIRC, there were a few minor tweaks of the examples.. See GERONIMO-1299 and GERONIMO-1540 for details.. -Dave- Jeff Genender wrote: I believe we used the source from Tomcat verbatim as we did not want to fork the code. In fact IIRC, it was a rename of the jars. Jeff Prasad Kashyap wrote: Does anybody know where I can find the source code for the geronimo samples, jsp-examples and tomcat-examples ? We are using these in our builds from this repository http://people.apache.org/repo/m1-snapshot-repository/geronimo-samples/wars/ We should archive the classes dirs in these wars just like we do to the apps in our build. When these examples wars are used in our build as is, there is a good possibility that it might hit the long path limit on windows. Cheers Prasad
Doc - plan update for tomcat clustering example
Hernan, It seems the 1.1 tomcat clustering example had recently ceased to work. I've made the appropriate minor changes to the 1.1 deployment plan (servlets-examples-tomcat-cluster-plan-5.5.15.xml) on the old confluence wiki: http://opensource.atlassian.com/confluence/oss/pages/viewpageattachments.action?pageId=2578 Any chance you can move this attachment to the new cwiki? Also, when will the 1.1 doc go live on the Geronimo website? Seems it should be available when 1.1 releases. Thanks -Dave-
[jira] Commented: (GERONIMO-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2112?page=comments#action_12416199 ] Dave Colasurdo commented on GERONIMO-2112: -- I believe the following changes are still required: License.txt - add licenses for castor and possibly antlr Notice.txt - add notices for castor and xpp3 > Place required attrtibutions in the NOTICES.txt file or a license included in > the LICENSE.txt file > -- > > Key: GERONIMO-2112 > URL: http://issues.apache.org/jira/browse/GERONIMO-2112 > Project: Geronimo > Type: Task > Security: public(Regular issues) > Components: documentation > Versions: 1.1 > Reporter: John Sisson > Assignee: Kevan Miller > Priority: Blocker > Fix For: 1.1 > Attachments: LICENSE.txt, NOTICE.txt, NOTICE.txt, NOTICES-draft1.txt, > geronimo-1.1-RC-licenses-attributions-draft1.txt, > geronimo-1.1-RC-licenses-attributions-draft2.txt > > I have collated a list of components in the attached file indicating whether > IMHO they require an attribution in the NOTICES.txt file or a license > included in the LICENSE.txt file. > See http://www.apache.org/dev/apply-license.html#new for information on > license files. > See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example > of a LICENSE file containing other licenses. -- 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-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2112?page=comments#action_12416113 ] Dave Colasurdo commented on GERONIMO-2112: -- That was the format I used in the original LICENSE.TXT and NOTICE.txt that I attached (separating licenses from attributions). I suspect tweaking those files with updated info may be the way to go.. -Dave- > Place required attrtibutions in the NOTICES.txt file or a license included in > the LICENSE.txt file > -- > > Key: GERONIMO-2112 > URL: http://issues.apache.org/jira/browse/GERONIMO-2112 > Project: Geronimo > Type: Task > Security: public(Regular issues) > Components: documentation > Versions: 1.1 > Reporter: John Sisson > Priority: Blocker > Fix For: 1.1 > Attachments: LICENSE.txt, NOTICE.txt, NOTICE.txt, NOTICES-draft1.txt, > geronimo-1.1-RC-licenses-attributions-draft1.txt, > geronimo-1.1-RC-licenses-attributions-draft2.txt > > I have collated a list of components in the attached file indicating whether > IMHO they require an attribution in the NOTICES.txt file or a license > included in the LICENSE.txt file. > See http://www.apache.org/dev/apply-license.html#new for information on > license files. > See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example > of a LICENSE file containing other licenses. -- 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: rc1 Status and Next Steps
Dave Colasurdo wrote: John Sisson wrote: 6. Third Party Licenses. This needs to be reviewed and the appropriate licenses compiled. Volunteers? We did not have one in the 1.0 stream so I'd like clarification if this is a requirement or something that can be deferred. IMO this is a requirement. Just have a look at some of the licenses for components we are redistributing. I have collated a list of components attached to a file in http://issues.apache.org/jira/browse/GERONIMO-2112 indicating whether IMHO they require an attribution in the NOTICES.txt file or a license included in the LICENSE.txt file and where to get the information from. There are some that require further investigation as IMNAL. Can people please look at the file attached to GERONIMO-2112 and see if there are any obvious omissions/errors and comment on the items requiring further investigation. If someone has time to pick it up from and start assembling the LICENSE.txt and NOTICE.txt files, please do, otherwise I'll continue in the morning (Sydney time). John, I am also investigating. I suspect jdom and castor may also need to be added to the list.. Will make an initial pass at the files and attach them to GERONIMO-2112.. Of course IANAL.. :) Have attached LICENSE.txt and NOTICE.txt to the JIRA: http://issues.apache.org/jira/browse/GERONIMO-2112 I still need some input on openejb and stax-api.. David Blevins and James Strachan.. Are there any license terms or notices that need to be added for these projects? Thanks -Dave-
[jira] Updated: (GERONIMO-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2112?page=all ] Dave Colasurdo updated GERONIMO-2112: - Attachment: NOTICE.txt LICENSE.txt Here is the initial pass at the LICENSE.TXT and NOTICE.TXT files for Geronimo 1.1.. Still need input on Openejb and stax-api .. and of course a thorough review of all content.. Note that antlr contains two licenses.. I suspect only the first one is needed but included both so that you could see them. Thanks -Dave- > Place required attrtibutions in the NOTICES.txt file or a license included in > the LICENSE.txt file > -- > > Key: GERONIMO-2112 > URL: http://issues.apache.org/jira/browse/GERONIMO-2112 > Project: Geronimo > Type: Task > Security: public(Regular issues) > Components: documentation > Versions: 1.1 > Reporter: John Sisson > Priority: Blocker > Fix For: 1.1 > Attachments: LICENSE.txt, NOTICE.txt, NOTICES-draft1.txt, > geronimo-1.1-RC-licenses-attributions-draft1.txt > > I have collated a list of components in the attached file indicating whether > IMHO they require an attribution in the NOTICES.txt file or a license > included in the LICENSE.txt file. > See http://www.apache.org/dev/apply-license.html#new for information on > license files. > See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example > of a LICENSE file containing other licenses. -- 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: rc1 Status and Next Steps
John Sisson wrote: 6. Third Party Licenses. This needs to be reviewed and the appropriate licenses compiled. Volunteers? We did not have one in the 1.0 stream so I'd like clarification if this is a requirement or something that can be deferred. IMO this is a requirement. Just have a look at some of the licenses for components we are redistributing. I have collated a list of components attached to a file in http://issues.apache.org/jira/browse/GERONIMO-2112 indicating whether IMHO they require an attribution in the NOTICES.txt file or a license included in the LICENSE.txt file and where to get the information from. There are some that require further investigation as IMNAL. Can people please look at the file attached to GERONIMO-2112 and see if there are any obvious omissions/errors and comment on the items requiring further investigation. If someone has time to pick it up from and start assembling the LICENSE.txt and NOTICE.txt files, please do, otherwise I'll continue in the morning (Sydney time). John, I am also investigating. I suspect jdom and castor may also need to be added to the list.. Will make an initial pass at the files and attach them to GERONIMO-2112.. Of course IANAL.. :) Thanks -Dave-
Re: 1.1-rc1 Now Available
It seems the out of box use of plugins in the admin console is erroneously creating url links to install the "welcome app" and "admin console" plugins. They are already installed and started in the j2ee distribution. Thanks -Dave- Matt Hogstrom wrote: Over the past few days the outstanding issues that were raised about the first candidate have been addressed. They were that we were missing the LICENSE.txt as well as Notices from the distribution. I added them. Guillaume also pointed out that he noted that there should be a Third Party Notices. This was not included in the original 1.0 or previous distributions so I did not follow it up. Thoughts? Also, the 1.0 release notes were removed and updated the thread started by Hernan. The Wiki has been updated and the wiki was the source used to create the RELEASE-NOTES-1.1.txt file you will find in the build. To avoid issues with the version number and the plugins I used rc1 which Aaron had added in the plugins for supported versions so I trust that works here. JSisson addressed the problem with not being able to run Geronimo under CygWin and Kevan worked with Aaron to address a new deployment problem that left partially deployed artifacts in the repository. I have taken this build and run some performance tests on it and we are significantly better in 1.1 than we were in 1.0. We have a lot of improvement left for CMP EJBs. It appears that the performance improvements in the EJB tier has changed a race condition when running under DB2. I'm afraid that the only way to address the problem is to add a new feature to TranQL and OEJB that allow for the specification of Isolation Levels for individual beans. This is a relatively simple change but the build as it stands is specification compliant. I would prefer to let this release go forward since CMP 2.1 EJBs are not nearly as common as the other J2EE components. I would like to address this in 1.1.1 however I don't think we've locked down whether that would be allowed or not. The change would affect TranQL and OpenEJB so they are really included components so I'd be interested in people's feedback. So please accept a named RC1. Your voting and feedback are for: Geronimo 1.1 DayTrader 1.1 Specs 1.1 The vote will stand for 72 hours. Issues raised will be discussed and if we conclude that there is a bug that must be addressed then we will mitigate the problem and respin a new rc for a 72 hour vote. If this is accepted all three of the above components will be released simultaneously. Here are the builds for your review and comment: http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.tar.gz http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.zip http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-j2ee-1.1-rc1.tar.gz http://people.apache.org/~hogstrom/rc1/geronimo-romcat-j2ee-1.1-rc1.zip http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.tar.gz http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.zip http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.tar.gz http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.zip http://people.apache.org/~hogstrom/rc1/daytrader-ear-1.1-rc1.zip Looking forward to your comments and feedback.
Re: RELEASE-NOTES-1.1
2) In section "Significant Changes" -Shared Library Support -Statement Cache for JDBC drivers -Dynamic Plugin support -In-place deployment of exploded applications -Dependent Package Upgrades (Tomcat, Jetty, etc.) DONE. Seems that 3 of the items above are missing from the release notes in the 1.1 rc1 build? 3)Also, probably want a new section on "Migrating applications from previous releases" that references the existence of the Upgrade tool that David J has created (and Lin is documenting) and any other major differences that existing users will need to know. It should link to any other migration documentation that we have. Didn't see any references/links to the "plan upgrade tool" in the 1.1 rc1 release notes? Thanks -Dave-
Re: [jira] Commented: (GERONIMO-1638) Multiple servers sharing the same repo and config store
BTW, I think additional fixes are required in 1.1.1 before claiming support for multiple concurrent server instances from a single installation.. Awhile back I was able to start the server using an external var directory (via -Dorg.apache.geronimo.server.dir). After changing all the ports and trying to start a second instance from the default location, I encountered a startup exception regarding the activemq transaction journal. Suspect code changes are needed to relocate the journal to a location outside the installation directory. Thanks -Dave- John Sisson (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12415496 ] John Sisson commented on GERONIMO-1638: --- Currently working on scripts as discussed at http://www.mail-archive.com/dev@geronimo.apache.org/msg22807.html . Have made changes but they need to be tested on windows, cygwin and unix, so looks like this is going to be for 1.1.1 . Multiple servers sharing the same repo and config store --- Key: GERONIMO-1638 URL: http://issues.apache.org/jira/browse/GERONIMO-1638 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: usability Versions: 1.0 Reporter: Gianny Damour Assignee: John Sisson Fix For: 1.1 David J. sent to the dev mailing list: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are "located" outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to "relocate". I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like "resolveVar" and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the "var" trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now "var". Several people have suggested putting an additional config-store into var for "private" use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
Re: RELEASE-NOTES-1.1
Hernan Cunico wrote: Dave Colasurdo wrote: Hernan Cunico wrote: Hi All, I updated the release notes and it is ready for your review and comments, here is the link http://cwiki.apache.org/GMOxDOC11/release-notes-11txt.html Cheers! Hernan Thanks Hernan! A few comments: 1) In section "Installing and Starting Geronimo" Suspect the geronimo.sh reference should be ./geronimo.sh I did not include the ./ because I specified the full path. Having the full path do you still need to specify the ./ ? Nope. It works fine with the full path. 2) In section "Significant Changes" -Shared Library Support -Statement Cache for JDBC drivers -Dynamic Plugin support -In-place deployment of exploded applications -Dependent Package Upgrades (Tomcat, Jetty, etc.) DONE. Thanks 3)Also, probably want a new section on "Migrating applications from previous releases" that references the existence of the Upgrade tool that David J has created (and Lin is documenting) and any other major differences that existing users will need to know. It should link to any other migration documentation that we have. Is that doc already available, I couldn't find the pointer on the dev list. http://www.mail-archive.com/user@geronimo.apache.org/msg03519.html Thanks -Dave- Thanks for the comments. Cheers! Hernan
Re: RELEASE-NOTES-1.1
Hernan Cunico wrote: Hi All, I updated the release notes and it is ready for your review and comments, here is the link http://cwiki.apache.org/GMOxDOC11/release-notes-11txt.html Cheers! Hernan Thanks Hernan! A few comments: 1) In section "Installing and Starting Geronimo" Suspect the geronimo.sh reference should be ./geronimo.sh 2) In section "Significant Changes" -Shared Library Support -Statement Cache for JDBC drivers -Dynamic Plugin support -In-place deployment of exploded applications -Dependent Package Upgrades (Tomcat, Jetty, etc.) 3)Also, probably want a new section on "Migrating applications from previous releases" that references the existence of the Upgrade tool that David J has created (and Lin is documenting) and any other major differences that existing users will need to know. It should link to any other migration documentation that we have. Thanks -Dave-
Re: 1.1 Candidate releases available
Guillaume Nodet wrote: and the plugins portlet does not display hyperlinks, so plugins can not be installed... Aaron, It seems that the plugin problems (installing samples, installing plugins from the admin console)that we saw last week have reappeared in the RC build. These problems originally appeared ...then disappeared for a few builds but have resurfaced again in the RC build. Is this a geronimo problem or a plugins regen or plugins website issue? It does not seem to be related to ibiblio availability.. Here is a link to an earlier append on this subject: http://www.mail-archive.com/dev@geronimo.apache.org/msg23286.html Thanks -Dave-
Re: [Fwd: build: Geronimo 1.1-410806] - Sample Installation fails
Also, doesn't look like the admin console is finding any installable plugins when "search for plugins" is selected. :( Thanks -Dave- Aaron Mulder wrote: Well, that would seem to rule out an ibiblio problem. I guess we need to change the error message to indicate which dependency is missing. :) Thanks, Aaron On 6/1/06, Dave Colasurdo <[EMAIL PROTECTED]> wrote: All three sample installations fail with the same exception shown below... Aaron Mulder wrote: > The sample plugins are built as part of the build, but there's a > separate process to build the repository metadata and update the > plugin site. > > As for this specific error, the JSP and LDAP examples have external > dependencies, but the Servlets examples don't -- so if the Servlets > example works but the others don't, that suggests a problem with > ibiblio. > > Thanks, >Aaron > > On 6/1/06, Dave Colasurdo <[EMAIL PROTECTED]> wrote: >> It seems that the default samples won't install from the welcome page >> for this build. Do the plugins for the samples need to be updated and >> regenerated? Looks like a missing dependency.. >> >> BTW, where does the plugin regeneration take place? Is it part of the >> geronimo build or is it done externally? >> >> Hmmm.. Looks like http://www.ibiblio.org/maven2/ is intermittently >> available/not available.. Perhaps that is the real issue.. >> >> Here is the stacktrace: >> >> 11:51:44,404 ERROR [[servlet_sample_installer]] Servlet.service() for >> servlet servlet_sample_installer threw exception >> org.apache.geronimo.kernel.repository.MissingDependencyException: Cannot >> install plugin geronimo/servlets-examples-tomcat/1.1-SNAPSHOT/car on >> Geronimo 1.1-410806 >> at >> org.apache.geronimo.system.plugin.PluginInstallerGBean.validatePlugin(PluginInstallerGBean.java:563) >> >> at >> org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:618) >> >> at >> org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:378) >> >> at >> org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:307) >> >> at >> org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCGLIB$$cebc327e.invoke() >> >> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) >> at >> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) >> >> at >> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) >> >> at >> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) >> >> at >> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) >> at >> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) >> >> at >> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) >> >> at >> org.apache.geronimo.system.plugin.PluginInstaller$$EnhancerByCGLIB$$2fd39c57.install() >> >> at >> org.apache.geronimo.welcome.AbsentSampleServlet.doInstall(AbsentSampleServlet.java:72) >> >> at >> org.apache.geronimo.welcome.AbsentSampleServlet.doGet(AbsentSampleServlet.java:52) >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) >> >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) >> >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) >> >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) >> >> at >> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46) >> >> at >> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) >> >> at >> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) >> >> at >> org.apache.catalina.core.Standard
Re: [Fwd: build: Geronimo 1.1-410806] - Sample Installation fails
All three sample installations fail with the same exception shown below... Aaron Mulder wrote: The sample plugins are built as part of the build, but there's a separate process to build the repository metadata and update the plugin site. As for this specific error, the JSP and LDAP examples have external dependencies, but the Servlets examples don't -- so if the Servlets example works but the others don't, that suggests a problem with ibiblio. Thanks, Aaron On 6/1/06, Dave Colasurdo <[EMAIL PROTECTED]> wrote: It seems that the default samples won't install from the welcome page for this build. Do the plugins for the samples need to be updated and regenerated? Looks like a missing dependency.. BTW, where does the plugin regeneration take place? Is it part of the geronimo build or is it done externally? Hmmm.. Looks like http://www.ibiblio.org/maven2/ is intermittently available/not available.. Perhaps that is the real issue.. Here is the stacktrace: 11:51:44,404 ERROR [[servlet_sample_installer]] Servlet.service() for servlet servlet_sample_installer threw exception org.apache.geronimo.kernel.repository.MissingDependencyException: Cannot install plugin geronimo/servlets-examples-tomcat/1.1-SNAPSHOT/car on Geronimo 1.1-410806 at org.apache.geronimo.system.plugin.PluginInstallerGBean.validatePlugin(PluginInstallerGBean.java:563) at org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:618) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:378) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:307) at org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCGLIB$$cebc327e.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.system.plugin.PluginInstaller$$EnhancerByCGLIB$$2fd39c57.install() at org.apache.geronimo.welcome.AbsentSampleServlet.doInstall(AbsentSampleServlet.java:72) at org.apache.geronimo.welcome.AbsentSampleServlet.doGet(AbsentSampleServlet.java:52) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) Thanks -Dave- Original Message Subject: build: Geronimo 1.1-410806 Date: 1 Jun 2006 10:08:57 - From: [EMAIL PROTECTED] Reply-To: user@geronimo.apache.org To: user@geronimo.apache.org Geronimo 1.1-410806 (June 1, 2006) http://people.apache.org/dist/geronimo/unstable/1.1-410806 geronimo-1.1-410806-sr
[Fwd: build: Geronimo 1.1-410806] - Sample Installation fails
It seems that the default samples won't install from the welcome page for this build. Do the plugins for the samples need to be updated and regenerated? Looks like a missing dependency.. BTW, where does the plugin regeneration take place? Is it part of the geronimo build or is it done externally? Hmmm.. Looks like http://www.ibiblio.org/maven2/ is intermittently available/not available.. Perhaps that is the real issue.. Here is the stacktrace: 11:51:44,404 ERROR [[servlet_sample_installer]] Servlet.service() for servlet servlet_sample_installer threw exception org.apache.geronimo.kernel.repository.MissingDependencyException: Cannot install plugin geronimo/servlets-examples-tomcat/1.1-SNAPSHOT/car on Geronimo 1.1-410806 at org.apache.geronimo.system.plugin.PluginInstallerGBean.validatePlugin(PluginInstallerGBean.java:563) at org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:618) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:378) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:307) at org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCGLIB$$cebc327e.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.system.plugin.PluginInstaller$$EnhancerByCGLIB$$2fd39c57.install() at org.apache.geronimo.welcome.AbsentSampleServlet.doInstall(AbsentSampleServlet.java:72) at org.apache.geronimo.welcome.AbsentSampleServlet.doGet(AbsentSampleServlet.java:52) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) Thanks -Dave- Original Message Subject: build: Geronimo 1.1-410806 Date: 1 Jun 2006 10:08:57 - From: [EMAIL PROTECTED] Reply-To: user@geronimo.apache.org To: user@geronimo.apache.org Geronimo 1.1-410806 (June 1, 2006) http://people.apache.org/dist/geronimo/unstable/1.1-410806 geronimo-1.1-410806-src.tar.gz01-Jun-2006 02:31 7.9M geronimo-1.1-410806-src.zip 01-Jun-2006 02:27 11M geronimo-jetty-j2ee-1.1-410806.tar.gz 01-Jun-2006 02:26 35M geronimo-jetty-j2ee-1.1-410806.zip01-Jun-2006 02:31 35M geronimo-jetty-minimal-1.1-410806.tar.gz 01-Jun-2006 02:27 16M geronimo-jetty-minimal-1.1-410806.zip 01-Jun-2006 02:34 16M geronimo-tomcat-j2ee-1.1-410806.tar.gz01-Jun-2006 02:29 35M geronimo-tomcat-j2ee-1.1-410806.zip 01-Jun-2006 02:24 35M geronimo-tomcat-minimal-1.1-410806.tar.gz 01-Jun-2006 02:32 16M
[jira] Commented: (GERONIMO-2006) Deploying an application with an incorrect deployment plan results in non-functional admin console panel
[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=comments#action_12402408 ] Dave Colasurdo commented on GERONIMO-2006: -- Thanks for looking at this issue.. I originally created the pblm on a build that was done just prior to the cut-over to moduleId. So the original reported failures weren't related to configId -vs- moduleId.. though that pblm is also worth investigation. Concerning the non-functioning "web app WARs" panel .. The failure was pretty solid.. Perhaps this has gone away. I will try to recreate after getting a clean build. Though may be a bit delayed as I have been encountering connection errors ( svn: PROPFIND of '/openejb/branches/v2_1/openejb2': could not connect to server (https://svn.codehaus.org)) with maven m:fresh-checkout all day :( -Dave- > Deploying an application with an incorrect deployment plan results in > non-functional admin console panel > > > Key: GERONIMO-2006 > URL: http://issues.apache.org/jira/browse/GERONIMO-2006 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment, console > Versions: 1.1 > Reporter: Dave Colasurdo > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.1 > Attachments: Myapp.war, badPlan.xml, badPlan2.xml, stackTrace.log > > Deploying myApp.war using badPlan.xml (both attached) results in a > non-functioning "Show Web App Wars" panel. > The console "Deploy Applications" panel reports "application installed and > started successfully". However, the application did not startup succesfully. > The badPlan file is actually missing tcpListenerAddress=auto which causes > TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the > JIRA. > From then on, the "Web App Wars" console panel shows "portlet error" and > there is no way to uninstall the bad application via the console. The server > must be stopped and restarted in order to have the "Web App War" panel > function correctly. > The console should be able to report the true status of the "deploy/start" > and recover from deploying a bad plan. -- 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: Please try out the upgrade jar
I've also noticed another difference between the 1.0 and 1.1 deployment plans. Concerning the following xml: geronimo-properties-realm class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"/> class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"/> IIRC, for *G1.0*, certain applications required this xml in order to deploy/start properly on Jetty. It was *not* required for Tomcat. For *G1.1*, it seems that these security settings are required for both Jetty and Tomcat. The point is that Jetty applications will migrate fine though Tomcat applications may now require these few additional lines of xml. Perhaps the Upgrade tool should account for this case.. Thanks -Dave- David Jencks wrote: Thanks for trying it out. I changed how it starts quite a bit today -- I hope it hasn't become too slow. I also think I fixed the schema issue Dave Colasurdo found. thanks david jencks On May 14, 2006, at 3:57 PM, Chris Cardona wrote: Hi David J., This is very helpful! So far it worked for the simple ejb, war, ear that I've tested. I'll let you know if I ran into problems deploying other modules. Dave Colasurdo, FYI, I tried upgrading my geronimo-web.xml and it was converted from: http://geronimo.apache.org/xml/ns/web"; ... To: http://geronimo.apache.org/xml/ns/j2ee/web-1.1"; ... Maybe the upgrade tool is not expecting: http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0"; ... Not sure if this is a bug or that's the expected behavior. Chris --- Dave Colasurdo <[EMAIL PROTECTED]> wrote: Thanks David! It seems to run fine on the simple plans that I have tried though I do have a few quick comments and observations.. 1) Should the version in the schema name be updated (from 1.0 -> 1.1) for both jetty and tomcat plans? For example, the following line is unchanged when the tool is run.. xmlns="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0";> 2) When using a unicode file as input (on windows platform) the output file isn't created in unicode format. 3) On windows platform, it seems that CR (x'0D') is inserted on the end of every line.. This appears as a musical note in my editor :) -Dave- David Jencks wrote: I put the upgrade jar at http://people.apache.org/~djencks/geronimo-upgrade-1.1-SNAPSHOT.jar It would be very helpful to find out to what extent this works in real life. It's supposed to include all the classes it needs (that's why its so big) usage: java -jar geronimo-upgrade-1.1-SNAPSHOT.jar to source plan> [ to target plan>] if you leave out the target, you'll get output in the same directory as the source. thanks david jencks __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Please try out the upgrade jar
Thanks David! It seems to run fine on the simple plans that I have tried though I do have a few quick comments and observations.. 1) Should the version in the schema name be updated (from 1.0 -> 1.1) for both jetty and tomcat plans? For example, the following line is unchanged when the tool is run.. http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0";> 2) When using a unicode file as input (on windows platform) the output file isn't created in unicode format. 3) On windows platform, it seems that CR (x'0D') is inserted on the end of every line.. This appears as a musical note in my editor :) -Dave- David Jencks wrote: I put the upgrade jar at http://people.apache.org/~djencks/geronimo-upgrade-1.1-SNAPSHOT.jar It would be very helpful to find out to what extent this works in real life. It's supposed to include all the classes it needs (that's why its so big) usage: java -jar geronimo-upgrade-1.1-SNAPSHOT.jar [to target plan>] if you leave out the target, you'll get output in the same directory as the source. thanks david jencks
Re: New Feature Wednesday
I think Joe has raised a valid point here... Providing ongoing unstable builds is quite useful. However, if there is no simple link to them from the Geronimo website then how will users find them? Why not add a simple link to the unstable builds (or at least the location of the most recent 1.1 build) on the Geronimo main download page? This will encourage user participation and feedback for 1.1.. -Dave- Joe Bohn wrote: I agree with everyone else that it is really great to have these unstable builds being produced and posted on a regular basis! It will help encourage users to pick up the latest more quickly and provide us with quicker feedback. How is it expected that users will find these unstable builds? Is there some way to get to the unstable builds from the geronimo web site? I think more people would find it and use it if there was a link from the downloads page to http://cvs.apache.org/dist/geronimo/unstable/ . One more question: How long will these builds "hang around"? I see that there are still builds from 1.0 out there. Just a nit - but it would be nice if we could put the most recent build at the top of the list. Joe David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Latest +Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David
Geronimo 1.1 web tier clustering (with Tomcat 5.5.15) - documentation
The Geronimo 1.1 web tier clustering documentation (using Tomcat 5.5.15) and updated deployment plans are available at: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Clustering+Example -Dave-
Re: Tomcat version in G1.1 for clustering
Filip Hanik - Dev Lists wrote: Dave Colasurdo wrote: *Problem1* When testing Sticky session, my browser locks unto a particular cluster member (e.g. node1) due to the nodeid in the cookie. If I kill node1, the session fails over into node2 and all my session data is still present. This is good. The nodeid in the cookie continues to say node1 (this is also true w/ TC 5.5.9 w/ and mod-jk).. ok, this is probably not desired behavior for a cluster with more than 2 nodes. For this to work correctly, you need to have the JvmRouteBinderValve configured in tomcat. This valve, will rewrite the sessionId to include the new jvmRoute, node2 in your scenario. Filip Updated the deployment plan with the new Valve (included in the Valve Chain) and all now works as expected. After failover, the cookie is updated with the nodeid of the new server that processes the request. name="className">org.apache.catalina.cluster.session.JvmRouteBinderValve enabled=true Will update the G1.1 plan on the wiki. -Dave-
[jira] Updated: (GERONIMO-2006) Deploying an application with an incorrect deployment plan results in non-functional admin console panel
[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=all ] Dave Colasurdo updated GERONIMO-2006: - Summary: Deploying an application with an incorrect deployment plan results in non-functional admin console panel (was: Deploying an application with an incorrect depolyment plan results in non-functional admin console panel) > Deploying an application with an incorrect deployment plan results in > non-functional admin console panel > > > Key: GERONIMO-2006 > URL: http://issues.apache.org/jira/browse/GERONIMO-2006 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Dave Colasurdo > Attachments: Myapp.war, badPlan.xml, badPlan2.xml, stackTrace.log > > Deploying myApp.war using badPlan.xml (both attached) results in a > non-functioning "Show Web App Wars" panel. > The console "Deploy Applications" panel reports "application installed and > started successfully". However, the application did not startup succesfully. > The badPlan file is actually missing tcpListenerAddress=auto which causes > TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the > JIRA. > From then on, the "Web App Wars" console panel shows "portlet error" and > there is no way to uninstall the bad application via the console. The server > must be stopped and restarted in order to have the "Web App War" panel > function correctly. > The console should be able to report the true status of the "deploy/start" > and recover from deploying a bad plan. -- 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-2006) Deploying an application with an incorrect depolyment plan results in non-functional admin console panel
[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=all ] Dave Colasurdo updated GERONIMO-2006: - Attachment: badPlan2.xml Here is another bad plan (badPlan2) that results in a slightly different error (i.e the deploy panel doesn't refresh and returns a blank page). > Deploying an application with an incorrect depolyment plan results in > non-functional admin console panel > > > Key: GERONIMO-2006 > URL: http://issues.apache.org/jira/browse/GERONIMO-2006 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Dave Colasurdo > Attachments: Myapp.war, badPlan.xml, badPlan2.xml, stackTrace.log > > Deploying myApp.war using badPlan.xml (both attached) results in a > non-functioning "Show Web App Wars" panel. > The console "Deploy Applications" panel reports "application installed and > started successfully". However, the application did not startup succesfully. > The badPlan file is actually missing tcpListenerAddress=auto which causes > TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the > JIRA. > From then on, the "Web App Wars" console panel shows "portlet error" and > there is no way to uninstall the bad application via the console. The server > must be stopped and restarted in order to have the "Web App War" panel > function correctly. > The console should be able to report the true status of the "deploy/start" > and recover from deploying a bad plan. -- 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-2006) Deploying an application with an incorrect depolyment plan results in non-functional admin console panel
[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=all ] Dave Colasurdo updated GERONIMO-2006: - Attachment: stackTrace.log badPlan.xml Myapp.war > Deploying an application with an incorrect depolyment plan results in > non-functional admin console panel > > > Key: GERONIMO-2006 > URL: http://issues.apache.org/jira/browse/GERONIMO-2006 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Dave Colasurdo > Attachments: Myapp.war, badPlan.xml, stackTrace.log > > Deploying myApp.war using badPlan.xml (both attached) results in a > non-functioning "Show Web App Wars" panel. > The console "Deploy Applications" panel reports "application installed and > started successfully". However, the application did not startup succesfully. > The badPlan file is actually missing tcpListenerAddress=auto which causes > TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the > JIRA. > From then on, the "Web App Wars" console panel shows "portlet error" and > there is no way to uninstall the bad application via the console. The server > must be stopped and restarted in order to have the "Web App War" panel > function correctly. > The console should be able to report the true status of the "deploy/start" > and recover from deploying a bad plan. -- 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-2006) Deploying an application with an incorrect depolyment plan results in non-functional admin console panel
Deploying an application with an incorrect depolyment plan results in non-functional admin console panel Key: GERONIMO-2006 URL: http://issues.apache.org/jira/browse/GERONIMO-2006 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.1 Reporter: Dave Colasurdo Deploying myApp.war using badPlan.xml (both attached) results in a non-functioning "Show Web App Wars" panel. The console "Deploy Applications" panel reports "application installed and started successfully". However, the application did not startup succesfully. The badPlan file is actually missing tcpListenerAddress=auto which causes TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the JIRA. >From then on, the "Web App Wars" console panel shows "portlet error" and there >is no way to uninstall the bad application via the console. The server must >be stopped and restarted in order to have the "Web App War" panel function >correctly. The console should be able to report the true status of the "deploy/start" and recover from deploying a bad plan. -- 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
G1.1 Tomcat Clustering - Good news
Now that we have officially upgraded to TC 5.5.15, I've gone back and retried the clustering tests and it looks like G1.1 clustering is now working with TC5.5.15!! The "Unable to send message through cluster sender" exception that was being thrown was caused by a problem in the application deployment plan. Specifically, the tcpListen address had extra whitespace on the end that creates this problem. Seems this should be trimmed automatically. name="className">org.apache.catalina.cluster.tcp.ReplicationListener tcpListenAddress=192.168.0.1 tcpListenPort=4001 tcpSelectorTimeout=100 tcpThreadCount=6 Anyway, it seems that we can change this value to auto (e.g. tcpListenAddress=auto) for TC 5.5.15 and all works well. -Dave-
[jira] Commented: (GERONIMO-1976) Change Welcome Application for G1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1976?page=comments#action_12377630 ] Dave Colasurdo commented on GERONIMO-1976: -- BTW, the patch should get applied to /applications/welcome/src/webapp/ Thanks > Change Welcome Application for G1.1 > --- > > Key: GERONIMO-1976 > URL: http://issues.apache.org/jira/browse/GERONIMO-1976 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: usability > Versions: 1.1 > Reporter: Dave Colasurdo > Attachments: welcome-app.patch > > Update the G1.1 welcome app.. > - Unclutter the initial welcome screen > - Moved "replace url" information to backup page > - Moved "slimmer geronimo" info to backup page > - Updated "replace url" user deployment xml to G1.1 format > - Geronimo-1900 adds a graphic that can be used on the new panels. The > graphic is referenced though commented out for now. It can be uncommented > when Geronimo-1900 patch is committed. > Also, the writeup for "slimmer Geronimo" still needs to evaluated in light of > the new little-G offering and Plugin capabilities. > I suspect we should reference all three on the "slimmerG" page. Thoughts? > Thanks > -Dave- -- 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-1976) Change Welcome Application for G1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1976?page=all ] Dave Colasurdo updated GERONIMO-1976: - Attachment: welcome-app.patch > Change Welcome Application for G1.1 > --- > > Key: GERONIMO-1976 > URL: http://issues.apache.org/jira/browse/GERONIMO-1976 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: usability > Versions: 1.1 > Reporter: Dave Colasurdo > Attachments: welcome-app.patch > > Update the G1.1 welcome app.. > - Unclutter the initial welcome screen > - Moved "replace url" information to backup page > - Moved "slimmer geronimo" info to backup page > - Updated "replace url" user deployment xml to G1.1 format > - Geronimo-1900 adds a graphic that can be used on the new panels. The > graphic is referenced though commented out for now. It can be uncommented > when Geronimo-1900 patch is committed. > Also, the writeup for "slimmer Geronimo" still needs to evaluated in light of > the new little-G offering and Plugin capabilities. > I suspect we should reference all three on the "slimmerG" page. Thoughts? > Thanks > -Dave- -- 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-1976) Change Welcome Application for G1.1
Change Welcome Application for G1.1 --- Key: GERONIMO-1976 URL: http://issues.apache.org/jira/browse/GERONIMO-1976 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: usability Versions: 1.1 Reporter: Dave Colasurdo Update the G1.1 welcome app.. - Unclutter the initial welcome screen - Moved "replace url" information to backup page - Moved "slimmer geronimo" info to backup page - Updated "replace url" user deployment xml to G1.1 format - Geronimo-1900 adds a graphic that can be used on the new panels. The graphic is referenced though commented out for now. It can be uncommented when Geronimo-1900 patch is committed. Also, the writeup for "slimmer Geronimo" still needs to evaluated in light of the new little-G offering and Plugin capabilities. I suspect we should reference all three on the "slimmerG" page. Thoughts? Thanks -Dave- -- 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-1900) Sample app links on welcome app are broken by default
[ http://issues.apache.org/jira/browse/GERONIMO-1900?page=comments#action_12377441 ] Dave Colasurdo commented on GERONIMO-1900: -- I still have a general uneasy feeling about this overall approach for the default examples. Prasad has done a good job given the current requirements/assumptions/restrictions of this JIRA. However, I question the assumptions. The flow is currently: 1) User hits the welcome page and selects "servlets-examples" 2) The "would you like to install examples" page is presented 3) User selects "yes" and is brought to the admin console logon page 4) After logging on, the plugins page is displayed 5) User selects the plugin server and chooses "search" 6) User is presented with list of plugins (apachds, various examples, ldap-realm) 7) User selects "servlets-examples" for the appropriate web container 8) Servlets-examples is magically installed along with any dependencies 9) User is presented with panel to "start servlets-examples" 10) User selects "start" and is returned to the plugins menu The major problems I have with this approach is: a) The user that is trying to run a few simple examples is tossed into the middle of the admin console. b) First time users should be gently introduced to the console via the front welcome page c) Users will be exposed to many other plugins (the list is growing) that are useful but not particulary pertinent to the task of installing examples c) The user is left stranded in the plugins page of the admin console without any path back to the original thing they wanted to do (i.e. run the samples).. They either have to retype the original url or hit the back button several times.. Any chance of either pre-installing the samples (like G1.0) or installing the samples with one click (perhaps cmdline plugin under the covers) and automatically redirecting the user to the samples with minimal user intervention? Are we trying to showcase the plugin technology user interface or are we trying to provide a mechanism to quickly let the user run the samples? Perhaps there should be a separate "plugins" link from the welcome page to showcase the plugin technology. Thanks -Dave- > Sample app links on welcome app are broken by default > - > > Key: GERONIMO-1900 > URL: http://issues.apache.org/jira/browse/GERONIMO-1900 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: usability, sample apps > Versions: 1.1 > Reporter: Aaron Mulder > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.1 > Attachments: welcome-2.patch, welcome-3.patch, welcome.patch > > It would be nice to take users to a page that would prompt them to install > the sample if they click a link to it and it's not present. However, > automating this would require us to be able to construct a link into a > portlet, which does not seem easy. > For now, the welcome app can include pages at the locations where the sample > apps will be bound, with text to the effect of: > This sample has not yet been installed. To install it, visit the > (URL)console(/URL) and select the Plugins page, click the Search for Plugins > button, and select the (NAME HERE) sample to install. Then visit this same > URL again to view the (NAME HERE) example. -- 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-1955) Move user applications out of Geronimo repo
Move user applications out of Geronimo repo --- Key: GERONIMO-1955 URL: http://issues.apache.org/jira/browse/GERONIMO-1955 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: usability Versions: 1.1 Reporter: Dave Colasurdo User applications should be moved out of the Geronimo repository (i.e. /Geronimo-1.1/repository/geronimo ).. This may be as simple as changing the sample/default deployment plans to contain a common groupid name. I'd recommend a short simple groupid name of "user-apps" or possibly user-applications".. Alternately Matt has suggested "installedJ2EEApps". Whatever groupid name is chosen, the following should be changed: -Change documentation to specify the default deployment location (groupid in the deployment plans) and other references in the doc. -Consider creating this as an empty directory in the distributions. -Change the deployment plans for the available examples to use this groupid. -- 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: user-apps directory
Keeping with the theme of talking to myself.. I guess it is simpler to just change the groupid in the sample deployment plans to user-apps. Of course users are free to specify any groupid they want .. but the default in the sample plans that we provide (including our documentation) will result in the user applications being separated from the geronimo plumbing by naming convention without any code impact.. -Dave- Dave Colasurdo wrote: This reminds me of a topic from a few weeks ago.. Is there a JIRA open to address separating the end user applications from the geronimo internal plumbing? Specifically, /Geronimo-1.1/repository/geronimo/ seems like a strange spot for end user applications. Searching for deployed applications seems a bit like looking for a needle in the haystack. /Geronimo-1.1/repository/ has nearly 40 directories /Geronimo-1.1/repository/geronimo has nearly 70 directories. How about a simple /Geronimo-1.1/user-apps/ that contains only deployed user applications? Thanks -Dave- David Jencks (JIRA) wrote: remove config-store directories from assemblies, now that they aren't used any more --- Key: GERONIMO-1932 URL: http://issues.apache.org/jira/browse/GERONIMO-1932 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 modify the assembly plugin to not create the bogus empty unused obsolete config-store directory
Re: Simplify the welcome application
Aaron Mulder wrote: On 4/28/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Can we simplify the welcome application for the server? I find the shear amount of text on the page overwhelming. I'm hoping we can push the fine detail of to secondary pages. Do you have a proposal for what should go on the front page and what should not? It does seem like a lot of information for the initial welcome page. This will likely be the first page users hit to see if their installation is successful. We should keep it real simple with additional inks for more info.. I think we should create links for: "Would you like your application to appear at this URL?" and "Would you like a slimmer Geronimo installation?" And move the details to separate pages. Also, what is the strategy for easily acquiring the samples? Someone was looking at that -- maybe pkashyap, I forget. It was mentioned on IRC yesterday. The deal is if you click a link to a sample that's not installed, it will explain and have a link to "click here to go to the plugin download page where you can install sample XYZ" or whatever. I think the idea of web-based repository of plugins for geronimo is really cool and will benefit the project. From the perspective of samples, the web-based plugin repository can provide an easy way to organize and quickly install samples. However, I'm wondering if the plugin repository is really the best fit for quickly showcasing a few simple examples (e.g. servlets-examples). A typical first time user will install geronimo, go to the welcome page and probably follow a few of the links to the samples. In G1.0 it all merely works. In G1.1, the user will need to navigate several panels (e.g. Would you like to install samples, provide id/pw for console, get plugins from remote repo, start sample). I know we could probably suppress some of these panels, though the user will still likely need to make a few decisions about things they might not yet understand. Also they are dependent on network connectivity as well as remote server availability. Don't get me wrong, I think the plugin technology is a great idea and quite useful. I'm just wondering if we should continue to pre-populate the G binary image with 1 or 2 simple samples that just merely work for first time users.. Thanks -Dave- Thanks, Aaron
user-apps directory
This reminds me of a topic from a few weeks ago.. Is there a JIRA open to address separating the end user applications from the geronimo internal plumbing? Specifically, /Geronimo-1.1/repository/geronimo/ seems like a strange spot for end user applications. Searching for deployed applications seems a bit like looking for a needle in the haystack. /Geronimo-1.1/repository/ has nearly 40 directories /Geronimo-1.1/repository/geronimo has nearly 70 directories. How about a simple /Geronimo-1.1/user-apps/ that contains only deployed user applications? Thanks -Dave- David Jencks (JIRA) wrote: remove config-store directories from assemblies, now that they aren't used any more --- Key: GERONIMO-1932 URL: http://issues.apache.org/jira/browse/GERONIMO-1932 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 modify the assembly plugin to not create the bogus empty unused obsolete config-store directory
Re: Release 1.1 - Question about Java 1.5 Warning message
Users that deploy DayTrader or use CORBA EJBS will still encounter problems when using JDK 1.5. Is it possible to spit out some sort of conditional warning such as "JDK 1.5 not supported for CORBA" and "DayTrader application not supported on JDK 1.5" for these cases? Or at least "tone down" the JVM warning text at startup to be less harsh and specifically mention only the known restrictions. -Dave- Matt Hogstrom wrote: All, I wanted to clarify what our plan is for the JVM Check that is done to verify that a user is running on Java 1.4. If someone chooses to accept the responsibility and use Java 1.5 it would be rather annoying to have this message come out every time. I think we have three options: 1. Leave it as is (warning comes out all the time) 2. Allow someone to set a property or other mechanism to tell the server to not to issue the warning message. 3. Take the message out because 1.1 will tolerate 1.5 and we're not shipping DayTrader installed so the javax.xml.namespace.QName problem won't be visible. Personally I prefer 3 if there are no other issues. Thoughts? Matt
[jira] Commented: (GERONIMO-1884) Samples not installed properly in G1.1 - several issues
[ http://issues.apache.org/jira/browse/GERONIMO-1884?page=comments#action_12376249 ] Dave Colasurdo commented on GERONIMO-1884: -- Reopened ...so that most recent comments won't get lost.. -Dave- > Samples not installed properly in G1.1 - several issues > --- > > Key: GERONIMO-1884 > URL: http://issues.apache.org/jira/browse/GERONIMO-1884 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: sample apps > Versions: 1.1 > Reporter: Dave Colasurdo > Assignee: Aaron Mulder > Priority: Critical > Fix For: 1.1 > > IT appears that the Geronimo samples have recently been removed from the > default distributions and replaced with the ability to download them through > the admin console. There are several issues that need to be addressed: > 1) The Sample links on the Geronimo welcome page are dead.. This needs to be > updated with instructions on how to download, start and access the samples.. > 2) Assuming that the admin console "plugins" is the correct spot to download > the samples.. > 2a) The initial panel presented to the user is a bit confusing and is > missing the ldap-demo.. > 2b) After downloading the jsp or servlet examples.. The user is presented > with a "start examples" box.. Selecting this does not work and results in an > exception (attached below) > 2c) "start examples" box does not return any status > 2d) Manually starting the example via the command line also does not work. > and results in an exception... > Exception for 2b > Geronimo Application Server started > > # Installed configuration > # id = geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car > # location = > /home/davecola/geronimo-1.1-041906/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/repository/geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/jsp-examples-tomcat-1.1-SNAPSHOT.car > > 14:12:04,651 ERROR [GBeanInstanceState] Error while starting; GBean is now in > the FAILED state: > abstractName="geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car?configurationName=geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car" > java.lang.ClassCastException > at > org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:380) > at > org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322) > at > org.apache.geronimo.kernel.config.Configuration.(Configuration.java:267) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:274) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:932) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:525) > at > org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:376) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:143) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:267) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:235) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:210) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(G
[jira] Commented: (GERONIMO-1884) Samples not installed properly in G1.1 - several issues
[ http://issues.apache.org/jira/browse/GERONIMO-1884?page=comments#action_12376064 ] Dave Colasurdo commented on GERONIMO-1884: -- Thanks Aaron!! The servlet and jsp examples seem to install and start fine with the latest build.. A few comments: - Is it possible to suppress the missing web containers examples (e.g. suppress jetty examples in the tomcat distribution and vice versa). There presence seems awkward.. - There seems to be a mismatch in terminology.. Title reads import/export configurations.. the details talk about installing a plugin.. - The Ldap example is missing from the list. - It would be nice if there were a few words documenting how to uninstall the config/plugin. Perhaps just a simple statement "imported configurations can be removed by uninstalling the appropriate application" It wasn't clear to me at first if the term "plugin" implied some uninstall step beyond a simple application uninstall. Thanks -Dave- > Samples not installed properly in G1.1 - several issues > --- > > Key: GERONIMO-1884 > URL: http://issues.apache.org/jira/browse/GERONIMO-1884 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: sample apps > Versions: 1.1 > Reporter: Dave Colasurdo > Assignee: Aaron Mulder > Priority: Critical > Fix For: 1.1 > > IT appears that the Geronimo samples have recently been removed from the > default distributions and replaced with the ability to download them through > the admin console. There are several issues that need to be addressed: > 1) The Sample links on the Geronimo welcome page are dead.. This needs to be > updated with instructions on how to download, start and access the samples.. > 2) Assuming that the admin console "plugins" is the correct spot to download > the samples.. > 2a) The initial panel presented to the user is a bit confusing and is > missing the ldap-demo.. > 2b) After downloading the jsp or servlet examples.. The user is presented > with a "start examples" box.. Selecting this does not work and results in an > exception (attached below) > 2c) "start examples" box does not return any status > 2d) Manually starting the example via the command line also does not work. > and results in an exception... > Exception for 2b > Geronimo Application Server started > > # Installed configuration > # id = geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car > # location = > /home/davecola/geronimo-1.1-041906/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/repository/geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/jsp-examples-tomcat-1.1-SNAPSHOT.car > > 14:12:04,651 ERROR [GBeanInstanceState] Error while starting; GBean is now in > the FAILED state: > abstractName="geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car?configurationName=geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car" > java.lang.ClassCastException > at > org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:380) > at > org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322) > at > org.apache.geronimo.kernel.config.Configuration.(Configuration.java:267) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:274) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:932) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:525) > at > org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:376) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:143) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:267) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loa
[jira] Created: (GERONIMO-1884) Samples not installed properly in G1.1 - several issues
Samples not installed properly in G1.1 - several issues --- Key: GERONIMO-1884 URL: http://issues.apache.org/jira/browse/GERONIMO-1884 Project: Geronimo Type: Bug Security: public (Regular issues) Components: sample apps Versions: 1.1 Reporter: Dave Colasurdo Priority: Critical IT appears that the Geronimo samples have recently been removed from the default distributions and replaced with the ability to download them through the admin console. There are several issues that need to be addressed: 1) The Sample links on the Geronimo welcome page are dead.. This needs to be updated with instructions on how to download, start and access the samples.. 2) Assuming that the admin console "plugins" is the correct spot to download the samples.. 2a) The initial panel presented to the user is a bit confusing and is missing the ldap-demo.. 2b) After downloading the jsp or servlet examples.. The user is presented with a "start examples" box.. Selecting this does not work and results in an exception (attached below) 2c) "start examples" box does not return any status 2d) Manually starting the example via the command line also does not work. and results in an exception... Exception for 2b Geronimo Application Server started # Installed configuration # id = geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car # location = /home/davecola/geronimo-1.1-041906/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/repository/geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/jsp-examples-tomcat-1.1-SNAPSHOT.car 14:12:04,651 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName="geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car?configurationName=geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car" java.lang.ClassCastException at org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:380) at org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.(Configuration.java:267) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:932) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:525) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:376) at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:143) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:267) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:235) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:210) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$a14ba351.loadConfiguration() at org.apache.geronimo.console.car.ResultsHandler.actionAfterView(ResultsHandler.java:75) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:116) at org.apache.pluto.core.PortletServlet.disp
Re: [continuum] BUILD FAILURE: Geronimo 1.1
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Final Memory : 5M/14M Total time : 1 minutes 34 seconds Finished at : Thursday, April 20, 2006 12:54:20 PM EDT Aaron Mulder wrote: Curious, I had a different error in the j2ee-installer (something about missing daytrader CARs). Are you sure you're getting the SerializedConfigurationMarshaler error in j2ee-installer? (That part is buried a bit further down the stack trace.) Thanks, Aaron On 4/20/06, Dave Colasurdo <[EMAIL PROTECTED]> wrote: Manually building the j2ee-server-tomcat and j2ee-server-jetty assemblies seems to work fine Though manually building the j2ee-installer fails with the same error you are seeing... -Dave- Kevan Miller wrote: OK. It's causing me problems, now. Guess we'd better do something about it... ;-) Dave, have you tried removing installer from your assemblies? Wonder if this is an installer assembly issue or a general assembly issue. I would assume it's a general issue... Running with maven -X, you get the following. I'll start digging... BUILD FAILED File.. /home/kevan/geronimo/branches/1.1/maven.xml Element... maven:reactor Line.. 63 Column -1 Unable to obtain goal [multiproject:install-callback] -- /home/kevan/.maven/cache/geronimo-assembly-plugin-1.1.0-9/plugin.jelly:224:-1: nullorg.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [new5] -- /home/kevan/geronimo/branches/1.1/maven.xml:63:-1: Reactor subproject failure occurred at org.apache.maven.werkz.Goal.fire(Goal.java:663) at org.apache.maven.werkz.Goal.attain(Goal.java:592) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:693) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:511) at org.apache.maven.cli.App.main(App.java:1258) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) org.apache.commons.jelly.JellyTagException: /home/kevan/geronimo/branches/1.1/maven.xml:63:-1: Reactor subproject failure occurred at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:378) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:78) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:109) at org.apache.maven.werkz.Goal.fire(Goal.java:656) at org.apache.maven.werkz.Goal.attain(Goal.java:592) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:693) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:511) at org.apache.maven.cli.App.main(App.java:1258) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [multiproject:install-callback] -- /home/kevan/.maven/cache/geronimo-assembly-plugin-1.1.0-9/plugin.jelly:224:-1: null at org.apache.maven.werkz.Goal.fire(Goal.java:663) at org.apache.maven.werkz.Goal.attain(Goal.java:592) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:693) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368) ... 16 more Root cause org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [multiproject:install-callback] -- /home/kevan/.maven/cache/geronimo-assembly-plugin-1.1.0-9/plugin.jelly:224:-1: null at org.apache.maven.werkz.Goal.fire(Goal.java:663) at org.apache.maven.werkz.Goal.attain(Goal.java:592) at org.apache.maven.p
Re: [continuum] BUILD FAILURE: Geronimo 1.1
hodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Final Memory : 7M/17M Total time : 3 minutes 51 seconds Finished at : Thursday, April 20, 2006 10:35:52 AM EDT On Apr 20, 2006, at 9:01 AM, Dave Colasurdo wrote: continuum wrote: [snip] BUILD FAILED File.. /home/continuum/continuum-1.0.2/apps/continuum/work/68/maven.xml Element... maven:reactor Line.. 63 Column -1 Unable to obtain goal [multiproject:install-callback] -- /home/continuum/.geronimo-1.1-maven/cache/geronimo-assembly-plugin-1.1.0-9/plugin.jelly:224:-1: null Total time : 16 minutes 57 seconds Finished at : Thursday, April 20, 2006 12:19:28 AM PDT Anyone know how to get past this build failure? It continues to fail even after a clean checkout and online build. I know others are seeing this same failure.. Thanks -Dave-
Re: [continuum] BUILD FAILURE: Geronimo 1.1
continuum wrote: [snip] BUILD FAILED File.. /home/continuum/continuum-1.0.2/apps/continuum/work/68/maven.xml Element... maven:reactor Line.. 63 Column -1 Unable to obtain goal [multiproject:install-callback] -- /home/continuum/.geronimo-1.1-maven/cache/geronimo-assembly-plugin-1.1.0-9/plugin.jelly:224:-1: null Total time : 16 minutes 57 seconds Finished at : Thursday, April 20, 2006 12:19:28 AM PDT Anyone know how to get past this build failure? It continues to fail even after a clean checkout and online build. I know others are seeing this same failure.. Thanks -Dave-
Re: Tomcat version in G1.1 for clustering
Thanks Filip!! Filip Hanik - Dev Lists wrote: 5.5.15,16,17 has some new features, like the JvmRouteBinderValve, that will rewrite the session id for a new node when a node crashes. This is an important feature. The coordination error that you ran into I am not yet sure why it is happening, hence I can't comment on it, and I don't know if it is a result of a code change or just a one time fluke. I would make the same recommendation, to use 5.5.9 for 1.1 since 1.1 is right around the corner. And I will extend/commit my help to get 1.2/5.5.17 in a good shape, including documentation and testing for the clustering piece. Filip Dave Colasurdo wrote: Jeff Genender wrote: I would vote for not moving to 5.5.16 for 1.1. IMHO, its too close. We did some preliminary testing for 5.5.15 and it seems ok...and we will know in the next several days if its good to bake in to 1.1. Filip, How significant are the 5.5.15 bugs that you alluded to? Or is this just a general request to use the latest level... Are the problems unique to clustering? Do you suspect the coordination error to be a code bug in 5.5.15? AFAICT, my setup is identical to 5.5.9.. Would like your input on 5.5.9 -vs- 5.5.15.. Thanks -Dave- 5.5.9 is fine to stick with since its pretty stable and it just works, and in the event 5.5.15 causes any discomfort during testing, we are comfortable that we can fall back on it. IIRC, the 5.5.16 issues had to do with cross context stuff that David Jencks and I worked pretty diligently on to fix. So I would probably be apt to push a -1 on 5.5.16 for 1.1. Jeff Dave Colasurdo wrote: Hmmm.. What level of Tomcat does the community want to include in G1.1? Background... Tomcat 5.5.9 - current working level in G1.0 and G1.1.. Clustering works.. TCK is testing with this level.. Tomcat 5.5.10-5.5.14 - clustering is broken Tomcat 5.5.15 - Clustering seems to work somewhat. We've encountered at least one bug. Filip (tomcat clustering developer) mentioned there are still some significant bugs in this level and advises us to move to 5.5.16. Tomcat 5.5.16 - Jeff has mentioned that he and David J had previously discovered some issues that required significant rework that he didn't want to tackle until G1.2.. So... Do we stick with 5.5.9 for G1.1 and move to 5.5.16+ in G1.2? Thanks -Dave- Filip Hanik - Dev Lists wrote: looks like you are right, there where some other fixes in .16 that were important, so it may be better to use that one. seems like you got a coordination error, ie, node1 requested state from node2, but node2 didn't know about node1, and that caused the stack trace from below. Filip Dave Colasurdo wrote: Thanks Filip!! http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] seems to indicate that it is fixed in 5.5.15.. Is it fixed in 5.5.15 or 5.5.16? Thanks -Dave- Filip Hanik - Dev Lists wrote: Clustering was broken in Tomcat 5.5.10-5.5.15 due to a protocol change, this was corrected in 5.5.16. I would run the tests again that version, and then I can help you out with any problems you run into. Filip Dave Colasurdo wrote: Jeff, Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and ran the clustering tests. The *good* news... Load balancing, sticky session, session replication and session failover seem to work using the same deployment plan that was created for G1.1 w/ TC 5.5.9.. The *bad* news... *Problem1* When testing Sticky session, my browser locks unto a particular cluster member (e.g. node1) due to the nodeid in the cookie. If I kill node1, the session fails over into node2 and all my session data is still present. This is good. The nodeid in the cookie continues to say node1 (this is also true w/ TC 5.5.9 w/ and mod-jk).. Now, if I restart node1 and wait a minute or so and then hit my browser,I am directed to node1 and all my session data is gone. :( BTW, an earlier run using TC 5.5.9 also resulted in being directed back to node1 though the httpsession is retained. I think this may be related to problems replicating data whenever nodes are added.. Which leads me to ... *Problem2* Whenever a cluster member is added to the cluster, the other nodes receive the following exception. This occurs both during the initial addition of a node and after a stopped node is restarted... (Though later when I access an httpsession (via a servlet request)it does result in session replication between members.) 15:30:19,352 INFO [SimpleTcpCluster] Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.14.160 :4001,catalina,192.168.14.160,4001 , alive=0] 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sender. java.io.IOException: Sender not available. Make sure sender information is available to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmi
Re: Tomcat version in G1.1 for clustering
Jeff Genender wrote: I would vote for not moving to 5.5.16 for 1.1. IMHO, its too close. We did some preliminary testing for 5.5.15 and it seems ok...and we will know in the next several days if its good to bake in to 1.1. Filip, How significant are the 5.5.15 bugs that you alluded to? Or is this just a general request to use the latest level... Are the problems unique to clustering? Do you suspect the coordination error to be a code bug in 5.5.15? AFAICT, my setup is identical to 5.5.9.. Would like your input on 5.5.9 -vs- 5.5.15.. Thanks -Dave- 5.5.9 is fine to stick with since its pretty stable and it just works, and in the event 5.5.15 causes any discomfort during testing, we are comfortable that we can fall back on it. IIRC, the 5.5.16 issues had to do with cross context stuff that David Jencks and I worked pretty diligently on to fix. So I would probably be apt to push a -1 on 5.5.16 for 1.1. Jeff Dave Colasurdo wrote: Hmmm.. What level of Tomcat does the community want to include in G1.1? Background... Tomcat 5.5.9 - current working level in G1.0 and G1.1.. Clustering works.. TCK is testing with this level.. Tomcat 5.5.10-5.5.14 - clustering is broken Tomcat 5.5.15 - Clustering seems to work somewhat. We've encountered at least one bug. Filip (tomcat clustering developer) mentioned there are still some significant bugs in this level and advises us to move to 5.5.16. Tomcat 5.5.16 - Jeff has mentioned that he and David J had previously discovered some issues that required significant rework that he didn't want to tackle until G1.2.. So... Do we stick with 5.5.9 for G1.1 and move to 5.5.16+ in G1.2? Thanks -Dave- Filip Hanik - Dev Lists wrote: looks like you are right, there where some other fixes in .16 that were important, so it may be better to use that one. seems like you got a coordination error, ie, node1 requested state from node2, but node2 didn't know about node1, and that caused the stack trace from below. Filip Dave Colasurdo wrote: Thanks Filip!! http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] seems to indicate that it is fixed in 5.5.15.. Is it fixed in 5.5.15 or 5.5.16? Thanks -Dave- Filip Hanik - Dev Lists wrote: Clustering was broken in Tomcat 5.5.10-5.5.15 due to a protocol change, this was corrected in 5.5.16. I would run the tests again that version, and then I can help you out with any problems you run into. Filip Dave Colasurdo wrote: Jeff, Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and ran the clustering tests. The *good* news... Load balancing, sticky session, session replication and session failover seem to work using the same deployment plan that was created for G1.1 w/ TC 5.5.9.. The *bad* news... *Problem1* When testing Sticky session, my browser locks unto a particular cluster member (e.g. node1) due to the nodeid in the cookie. If I kill node1, the session fails over into node2 and all my session data is still present. This is good. The nodeid in the cookie continues to say node1 (this is also true w/ TC 5.5.9 w/ and mod-jk).. Now, if I restart node1 and wait a minute or so and then hit my browser,I am directed to node1 and all my session data is gone. :( BTW, an earlier run using TC 5.5.9 also resulted in being directed back to node1 though the httpsession is retained. I think this may be related to problems replicating data whenever nodes are added.. Which leads me to ... *Problem2* Whenever a cluster member is added to the cluster, the other nodes receive the following exception. This occurs both during the initial addition of a node and after a stopped node is restarted... (Though later when I access an httpsession (via a servlet request)it does result in session replication between members.) 15:30:19,352 INFO [SimpleTcpCluster] Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.14.160 :4001,catalina,192.168.14.160,4001 , alive=0] 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sender. java.io.IOException: Sender not available. Make sure sender information is available to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:857) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Re plicationTransmitter.java:430) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluste r.java:1074) at org.apache.catalina.cluster.session.DeltaManager.sendSessions(DeltaMa nager.java:1690) at org.apache.catalina.cluster.session.DeltaManager.handleGET_ALL_SESSIO NS(DeltaManager.java:1629) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(Delt aManager.java:1443) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived( DeltaManager.java:1
Re: Tomcat version in G1.1 for clustering
Hmmm.. What level of Tomcat does the community want to include in G1.1? Background... Tomcat 5.5.9 - current working level in G1.0 and G1.1.. Clustering works.. TCK is testing with this level.. Tomcat 5.5.10-5.5.14 - clustering is broken Tomcat 5.5.15 - Clustering seems to work somewhat. We've encountered at least one bug. Filip (tomcat clustering developer) mentioned there are still some significant bugs in this level and advises us to move to 5.5.16. Tomcat 5.5.16 - Jeff has mentioned that he and David J had previously discovered some issues that required significant rework that he didn't want to tackle until G1.2.. So... Do we stick with 5.5.9 for G1.1 and move to 5.5.16+ in G1.2? Thanks -Dave- Filip Hanik - Dev Lists wrote: looks like you are right, there where some other fixes in .16 that were important, so it may be better to use that one. seems like you got a coordination error, ie, node1 requested state from node2, but node2 didn't know about node1, and that caused the stack trace from below. Filip Dave Colasurdo wrote: Thanks Filip!! http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] seems to indicate that it is fixed in 5.5.15.. Is it fixed in 5.5.15 or 5.5.16? Thanks -Dave- Filip Hanik - Dev Lists wrote: Clustering was broken in Tomcat 5.5.10-5.5.15 due to a protocol change, this was corrected in 5.5.16. I would run the tests again that version, and then I can help you out with any problems you run into. Filip Dave Colasurdo wrote: Jeff, Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and ran the clustering tests. The *good* news... Load balancing, sticky session, session replication and session failover seem to work using the same deployment plan that was created for G1.1 w/ TC 5.5.9.. The *bad* news... *Problem1* When testing Sticky session, my browser locks unto a particular cluster member (e.g. node1) due to the nodeid in the cookie. If I kill node1, the session fails over into node2 and all my session data is still present. This is good. The nodeid in the cookie continues to say node1 (this is also true w/ TC 5.5.9 w/ and mod-jk).. Now, if I restart node1 and wait a minute or so and then hit my browser,I am directed to node1 and all my session data is gone. :( BTW, an earlier run using TC 5.5.9 also resulted in being directed back to node1 though the httpsession is retained. I think this may be related to problems replicating data whenever nodes are added.. Which leads me to ... *Problem2* Whenever a cluster member is added to the cluster, the other nodes receive the following exception. This occurs both during the initial addition of a node and after a stopped node is restarted... (Though later when I access an httpsession (via a servlet request)it does result in session replication between members.) 15:30:19,352 INFO [SimpleTcpCluster] Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.14.160 :4001,catalina,192.168.14.160,4001 , alive=0] 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sender. java.io.IOException: Sender not available. Make sure sender information is available to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:857) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Re plicationTransmitter.java:430) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluste r.java:1074) at org.apache.catalina.cluster.session.DeltaManager.sendSessions(DeltaMa nager.java:1690) at org.apache.catalina.cluster.session.DeltaManager.handleGET_ALL_SESSIO NS(DeltaManager.java:1629) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(Delt aManager.java:1443) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived( DeltaManager.java:1225) at org.apache.catalina.cluster.session.ClusterSessionListener.messageRec eived(ClusterSessionListener.java:85) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.receive(SimpleTcpClu ster.java:1160) at org.apache.catalina.cluster.tcp.ClusterReceiverBase.messageDataReceiv ed(ClusterReceiverBase.java:418) at org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java :107) at org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(Tcp ReplicationThread.java:131) at org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicati onThread.java:69) 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sen der. java.io.IOException: Sender not available. Make sure sender information is avail able to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:
Re: Tomcat version in G1.1 for clustering
Thanks Filip!! http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] seems to indicate that it is fixed in 5.5.15.. Is it fixed in 5.5.15 or 5.5.16? Thanks -Dave- Filip Hanik - Dev Lists wrote: Clustering was broken in Tomcat 5.5.10-5.5.15 due to a protocol change, this was corrected in 5.5.16. I would run the tests again that version, and then I can help you out with any problems you run into. Filip Dave Colasurdo wrote: Jeff, Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and ran the clustering tests. The *good* news... Load balancing, sticky session, session replication and session failover seem to work using the same deployment plan that was created for G1.1 w/ TC 5.5.9.. The *bad* news... *Problem1* When testing Sticky session, my browser locks unto a particular cluster member (e.g. node1) due to the nodeid in the cookie. If I kill node1, the session fails over into node2 and all my session data is still present. This is good. The nodeid in the cookie continues to say node1 (this is also true w/ TC 5.5.9 w/ and mod-jk).. Now, if I restart node1 and wait a minute or so and then hit my browser,I am directed to node1 and all my session data is gone. :( BTW, an earlier run using TC 5.5.9 also resulted in being directed back to node1 though the httpsession is retained. I think this may be related to problems replicating data whenever nodes are added.. Which leads me to ... *Problem2* Whenever a cluster member is added to the cluster, the other nodes receive the following exception. This occurs both during the initial addition of a node and after a stopped node is restarted... (Though later when I access an httpsession (via a servlet request)it does result in session replication between members.) 15:30:19,352 INFO [SimpleTcpCluster] Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.14.160 :4001,catalina,192.168.14.160,4001 , alive=0] 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sender. java.io.IOException: Sender not available. Make sure sender information is available to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:857) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Re plicationTransmitter.java:430) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluste r.java:1074) at org.apache.catalina.cluster.session.DeltaManager.sendSessions(DeltaMa nager.java:1690) at org.apache.catalina.cluster.session.DeltaManager.handleGET_ALL_SESSIO NS(DeltaManager.java:1629) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(Delt aManager.java:1443) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived( DeltaManager.java:1225) at org.apache.catalina.cluster.session.ClusterSessionListener.messageRec eived(ClusterSessionListener.java:85) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.receive(SimpleTcpClu ster.java:1160) at org.apache.catalina.cluster.tcp.ClusterReceiverBase.messageDataReceiv ed(ClusterReceiverBase.java:418) at org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java :107) at org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(Tcp ReplicationThread.java:131) at org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicati onThread.java:69) 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sen der. java.io.IOException: Sender not available. Make sure sender information is avail able to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:857) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Re plicationTransmitter.java:430) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluste r.java:1074) at org.apache.catalina.cluster.session.DeltaManager.handleGET_ALL_SESSIO NS(DeltaManager.java:1660) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(Delt aManager.java:1443) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived( DeltaManager.java:1225) at org.apache.catalina.cluster.session.ClusterSessionListener.messageRec eived(ClusterSessionListener.java:85) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.receive(SimpleTcpClu ster.java:1160) at org.apache.catalina.cluster.tcp.ClusterReceiverBase.messageDataReceiv ed(ClusterReceiverBase.java:418) at org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java :107) at org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(Tcp ReplicationThread.java:131) at
Re: Tomcat version in G1.1 for clustering
Jeff, Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and ran the clustering tests. The *good* news... Load balancing, sticky session, session replication and session failover seem to work using the same deployment plan that was created for G1.1 w/ TC 5.5.9.. The *bad* news... *Problem1* When testing Sticky session, my browser locks unto a particular cluster member (e.g. node1) due to the nodeid in the cookie. If I kill node1, the session fails over into node2 and all my session data is still present. This is good. The nodeid in the cookie continues to say node1 (this is also true w/ TC 5.5.9 w/ and mod-jk).. Now, if I restart node1 and wait a minute or so and then hit my browser, I am directed to node1 and all my session data is gone. :( BTW, an earlier run using TC 5.5.9 also resulted in being directed back to node1 though the httpsession is retained. I think this may be related to problems replicating data whenever nodes are added.. Which leads me to ... *Problem2* Whenever a cluster member is added to the cluster, the other nodes receive the following exception. This occurs both during the initial addition of a node and after a stopped node is restarted... (Though later when I access an httpsession (via a servlet request)it does result in session replication between members.) 15:30:19,352 INFO [SimpleTcpCluster] Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.14.160 :4001,catalina,192.168.14.160,4001 , alive=0] 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sender. java.io.IOException: Sender not available. Make sure sender information is available to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:857) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Re plicationTransmitter.java:430) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluste r.java:1074) at org.apache.catalina.cluster.session.DeltaManager.sendSessions(DeltaMa nager.java:1690) at org.apache.catalina.cluster.session.DeltaManager.handleGET_ALL_SESSIO NS(DeltaManager.java:1629) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(Delt aManager.java:1443) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived( DeltaManager.java:1225) at org.apache.catalina.cluster.session.ClusterSessionListener.messageRec eived(ClusterSessionListener.java:85) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.receive(SimpleTcpClu ster.java:1160) at org.apache.catalina.cluster.tcp.ClusterReceiverBase.messageDataReceiv ed(ClusterReceiverBase.java:418) at org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java :107) at org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(Tcp ReplicationThread.java:131) at org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicati onThread.java:69) 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sen der. java.io.IOException: Sender not available. Make sure sender information is avail able to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:857) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Re plicationTransmitter.java:430) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluste r.java:1074) at org.apache.catalina.cluster.session.DeltaManager.handleGET_ALL_SESSIO NS(DeltaManager.java:1660) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(Delt aManager.java:1443) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived( DeltaManager.java:1225) at org.apache.catalina.cluster.session.ClusterSessionListener.messageRec eived(ClusterSessionListener.java:85) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.receive(SimpleTcpClu ster.java:1160) at org.apache.catalina.cluster.tcp.ClusterReceiverBase.messageDataReceiv ed(ClusterReceiverBase.java:418) at org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java :107) at org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(Tcp ReplicationThread.java:131) at org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicati onThread.java:69) *Problem3* Getting a bunch of exceptions relating to session invalidation [snip] java.lang.IllegalStateException: getId: Session already invalidated [snip] This one may not be new.. Thanks -Dave- Jeff Genender wrote: Dave, Thanks for doing this. Jeff Dave Colasurdo wrote: I've validated that the Geronimo clustering example (http://opensource.atlassian.com/confluence/oss/di
Re: Tomcat version in G1.1 for clustering
I've validated that the Geronimo clustering example (http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Clustering+Example) still works for Geronimo 1.1 (with Tomcat 5.5.9). The application deployment plan (attached to email) required some changes. I'm now rebuilding G1.1 with Tomcat 5.5.15 to determine if the clustering Gbeans and plans still work.. -Dave- Jeff Genender wrote: IIRC, 5.5.15 went to backward compatibility... http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] Perhaps Filip can fill us in on this. If I remember right, the 5.5.9 clustering GBeans will work on forward versions. So I don't think there is a problem there. HEAD has been set to 5.5.15 for quite some time. Nevertheless, it doesn't hurt to try em out ;-) Jeff Dave Colasurdo wrote: Jeff (et al.), Will G1.1 definitely be upgraded to Tomcat 5.5.15? IIRC, the clustering deployment plans were quite different for 5.5.9 -vs- 5.5.12. If we upgrade to 5.5.15, we will likely need a new plan that accounts for both the webcontainer upgrade as well as the new G1.1 plan format.. Thanks -Dave- Jeff Genender wrote: Thanks Rainer. But I think 5.5.15 will be the one for 1.1. But possibly 5.5.17 for 1.2 ;-) Jeff Rainer Jung wrote: Just for your information: 5.5.16 was released a couple of weeks ago, but has some problems with de delivered packaginf of examples app under windows. 5.5.17 is expected to be cut on friday and voted stable eventually 1-2 weeks later. Jeff Genender wrote: Yep...need to update the plan. Its updated in trunk. Dave Colasurdo wrote: It appears that G1.1 is still using Tomcat 5.5.9 http://svn.apache.org/repos/asf/geronimo/branches/1.1/etc/project.properties Wasn't a tomcat upgrade to 5.5.15 in plan for G1.1?? Perhaps I am confused with the plans for trunk.. ?? Thanks -Dave- http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.1";> http://geronimo.apache.org/xml/ns/deployment-1.1";> geronimo servlets-examples-tomcat-cluster 1.1-SNAPSHOT car /servlets-examples-cluster false geronimo-properties-realm TomcatCluster org.apache.catalina.cluster.tcp.SimpleTcpCluster managerClassName=org.apache.catalina.cluster.session.DeltaManager expireSessionsOnShutdown=false useDirtyFlag=false notifyListenersOnReplication=true TomcatMembership TomcatReceiver TomcatSender ReplicationValve org.apache.catalina.cluster.mcast.McastService mcastAddr=228.0.0.4 mcastBindAddress=xx.yy.zz.aa mcastPort=45564 mcastFrequency=500 mcastDropTime=3000 org.apache.catalina.cluster.tcp.ReplicationListener tcpListenAddress=xx.yy.zz.aa tcpListenPort=4001 tcpSelectorTimeout=100 tcpThreadCount=6 org.apache.catalina.cluster.tcp.ReplicationTransmitter replicationMode=pooled ackTimeout=15000 org.apache.catalina.cluster.tcp.ReplicationValve filter=.*\.gif;.*\.js;.*\.css;.*\.png;.*\.jpeg;.*\.jpg;.*\.htm;.*\.html;.*\.txt;
Re: Tomcat version in G1.1 for clustering
Jeff (et al.), Will G1.1 definitely be upgraded to Tomcat 5.5.15? IIRC, the clustering deployment plans were quite different for 5.5.9 -vs- 5.5.12. If we upgrade to 5.5.15, we will likely need a new plan that accounts for both the webcontainer upgrade as well as the new G1.1 plan format.. Thanks -Dave- Jeff Genender wrote: Thanks Rainer. But I think 5.5.15 will be the one for 1.1. But possibly 5.5.17 for 1.2 ;-) Jeff Rainer Jung wrote: Just for your information: 5.5.16 was released a couple of weeks ago, but has some problems with de delivered packaginf of examples app under windows. 5.5.17 is expected to be cut on friday and voted stable eventually 1-2 weeks later. Jeff Genender wrote: Yep...need to update the plan. Its updated in trunk. Dave Colasurdo wrote: It appears that G1.1 is still using Tomcat 5.5.9 http://svn.apache.org/repos/asf/geronimo/branches/1.1/etc/project.properties Wasn't a tomcat upgrade to 5.5.15 in plan for G1.1?? Perhaps I am confused with the plans for trunk.. ?? Thanks -Dave-
Re: Tomcat version in G1.1
Thanks for the update Rainer. As Geronimo 1.1 includes an early copy of the 5.5.16 examples, I'd like to verify there is no Geronimo issue here. Is the problem limited to: http://issues.apache.org/bugzilla/show_bug.cgi?id=39041 If so, shouldn't be a problem for Geronimo.. Thanks -Dave- Rainer Jung wrote: Just for your information: 5.5.16 was released a couple of weeks ago, but has some problems with de delivered packaginf of examples app under windows. 5.5.17 is expected to be cut on friday and voted stable eventually 1-2 weeks later. Jeff Genender wrote: Yep...need to update the plan. Its updated in trunk. Dave Colasurdo wrote: It appears that G1.1 is still using Tomcat 5.5.9 http://svn.apache.org/repos/asf/geronimo/branches/1.1/etc/project.properties Wasn't a tomcat upgrade to 5.5.15 in plan for G1.1?? Perhaps I am confused with the plans for trunk.. ?? Thanks -Dave-
Tomcat version in G1.1
It appears that G1.1 is still using Tomcat 5.5.9 http://svn.apache.org/repos/asf/geronimo/branches/1.1/etc/project.properties Wasn't a tomcat upgrade to 5.5.15 in plan for G1.1?? Perhaps I am confused with the plans for trunk.. ?? Thanks -Dave-
Re: Cannot build 1.1 on Windows - long file paths
I believe it's important to keep the CARs expanded as I suspect users
(in development mode) would want the ability to easily update JSPs and
classes without redeploying. I also think Dain's suggestion to shrink
the path length is the right approach.. Other comments below..
-Dave-
Dain Sundstrom wrote:
Man I hate Windows
Anyway, if you have a real OS and list the files in an assembly, you
will see that the problem is caused by the combination of two changes:
we now keep configurations in the repository and we unpack them. If you
look closer you will see that the big offenders are unpacked ears and wars.
I believe the following are the longest paths in the server:
(270)
geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-jetty/1.1-SNAPSHOT/daytrader-derby-jetty-1.1-SNAPSHOT.car/daytrader-web-1.1-SNAPSHOT.war/META-INF/geronimo-generated/org/apache/geronimo/axis/client/GenericServiceEndpointWrapper$$EnhancerByCGLIB$$36344d29.class
(264)
geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1-SNAPSHOT/webconsole-jetty-1.1-SNAPSHOT.car/geronimo-console-standard-1.1-SNAPSHOT.war/WEB-INF/classes/org/apache/geronimo/console/databasemanager/wizard/DatabasePoolPortlet$ResourceAdapterParams.class
One thing to note here is that the longest paths are all classes
generated by Geronimo, nested classes in wars or compiled JSP pages.
Someone should look into makeing maven jar the latter two and Geronimo
should be creating jars when generating classes (actually we should stop
generating classes a head of time but that is another story).
Breaking down the longest path, we have:
GeronimoName (22)
geronimo-1.1-SNAPSHOT
RepositoryPath (55)
repository/geronimo/daytrader-derby-jetty/1.1-SNAPSHOT
FileName (39)
daytrader-derby-jetty-1.1-SNAPSHOT.car
NestedPath (154)
daytrader-web-1.1-SNAPSHOT.war/META-INF/geronimo-generated/org/apache/geronimo/axis/client/GenericServiceEndpointWrapper$$EnhancerByCGLIB$$36344d29.class
The first thing to note is if we simply replace "SNAPSHOT" with "0", we
drop 28 characters which makes the longest path 242; not enough head
room. Of course, when we switch our groupId to the maven standard
org.apache.geronimo we eat up 20 more characters. If we are going to
unpack war files there is very little we can do about the NestedPath, so
we have very few choices left. If we simply combine combine
${GeronimoName}/${FileName}/${NestedPath} we are up to 115 characters
leaving only 41 characters for anything else, but when you add back the
28 from "SNAPSHOT", you get to a more comfortable level.
I think if we combine this problem with Sachin's request for a separate
directory for applications, we could do something like this:
${GeronimoName}/apps/${FileName}/${NestedPath}
Are you suggesting removing the RepositoryPath from the actual directory
structure? If this is technically possible, I like the approach as I
think it keeps with the idea of "providing an intuitive structure that
users would expect" as opposed to an "obfuscated structure that is
dictated by the technology".
As has been suggested by others.. perhaps we have two unique directory
paths:
${GeronimoName}/sys-apps/${FileName}/${NestedPath}
${GeronimoName}/apps/${FileName}/${NestedPath}
sys-apps - would contain all of the geronimo internal apps and
configurations (uddi, webconsole, activemq, etc.)
apps - would contain the welcome app, samples and end user applications
There are several problems with this. I think users will confuse the
hot-deploy directory "deploy" with the "apps" directory [1]. Then
We can rename the deploy directory to hot-deploy for clarity..
again, if you look at the problem configurations they are all apps the
users may want to remove (sample apps and the console), so may be we
Users can freely undeploy any of the apps in the apps directory.. This
would be documented as a common thing to do.
Undeploying apps in the sys-apps directory is less common and while it
is supported we document that this should only be done when users really
know what they are doing.
should just put these in the hot-deploy directory. Another problem is
that it will be much more difficult to query a repository without a
directory structure. The server will basically have to read the
configuration from these apps on startup to determine what they are, so
again we may just want to use the hot-deploy directory. I'm not a fan
of the hot-deploy directory, but I'm not sure there is a better solution.
Again I renew my hate of Windows...
/me shakes his fist at Bill Gates
-dain
[1] As a side issue, I prefer the name "apps" because it will be most
familiar to tomcat users.
Re: Cannot build 1.1 on Windows - long file paths
I tried with: winzip - indicates an unzip error infozip - no error but omits the offending files jar -xvf - gets the following exception java.io.FileNotFoundException: geronimo-1.1-SNAPSHOT\repository\geronimo\daytrad er-derby-tomcat\1.1-SNAPSHOT\daytrader-derby-tomcat-1.1-SNAPSHOT.car\daytrader-w eb-1.1-SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis\client\ GenericServiceEndpointWrapper$$EnhancerByCGLIB$$6a6aebe.class (The system cannot find the path specified) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:179) at java.io.FileOutputStream.(FileOutputStream.java:131) at sun.tools.jar.Main.extractFile(Main.java:712) at sun.tools.jar.Main.extract(Main.java:678) at sun.tools.jar.Main.run(Main.java:190) at sun.tools.jar.Main.main(Main.java:904) The problem isn't with the unzip program.. The problem is that the images have files with path lengths that exceed the current limit of 256 for the windows platform.. -Dave- Dain Sundstrom wrote: What if you unpack with jar -xf? -dain On Apr 6, 2006, at 1:07 PM, Dave Colasurdo wrote: The "long file path" problem on the windows platform isn't limited to building G1.1 on this platform. The current images are incompatible with windows even when the images are generated on a different platform.. Specifically, I built G1.1 on linux and then FTP'd the generated windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows machine.. The resulting image can't unzip on the windows platform due to the path length problem.. :( e.g. C:\z\geronimo-1.1-SNAPSHOT\repository\geronimo\webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class Guess this is obvious in hindsight, though was thinking it was strictly a build issue.. This absolutely needs to get fixed.. -Dave- Joe Bohn wrote: You beat me to it John I'm hitting the exact same problem. Joe John Sisson wrote: I had issues relating to long file paths when building 1.1 from my C:\dev\asf\geronimo\branches\1.1 directory, so I tried building from a shorter directory ( C:\geronimo1.1 ) and still have issues (see below). I haven't had a chance to look into this yet but I consider this to be a blocker. Once we can build on windows we then need to test that Geronimo can be installed in common locations on windows (e.g. under C:\Program Files\Geronimo-1.1 ) without encountering file path length issues. The following path (from the output below) is 317 bytes long: C:\geronimo1.1\assemblies\j2ee-installer\target\geronimo-1.1-SNAPSHOT\repository\geronimo\daytrader-derby-jetty\1.1-SNAPSHOT\daytrader-derby-jetty-1.1-SNAPSHOT.car\daytrader-web-1.1-SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis\client\GenericServiceEndpointWrapper$$EnhancerByCGLIB$$2ae63e1d.class See http://issues.apache.org/jira/browse/GERONIMO-1790 for more info on the long file path issue. John 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 : C:\geronimo1.1\assemblies\j2ee-installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml [java] -> Output : C:\geronimo1.1\assemblies\j2ee-installer/target/geronimo-installer-1.1-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] 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: ProcessPanel.Spec.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]
Re: Cannot build 1.1 on Windows - long file paths
The "long file path" problem on the windows platform isn't limited to building G1.1 on this platform. The current images are incompatible with windows even when the images are generated on a different platform.. Specifically, I built G1.1 on linux and then FTP'd the generated windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows machine.. The resulting image can't unzip on the windows platform due to the path length problem.. :( e.g. C:\z\geronimo-1.1-SNAPSHOT\repository\geronimo\webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class Guess this is obvious in hindsight, though was thinking it was strictly a build issue.. This absolutely needs to get fixed.. -Dave- Joe Bohn wrote: You beat me to it John I'm hitting the exact same problem. Joe John Sisson wrote: I had issues relating to long file paths when building 1.1 from my C:\dev\asf\geronimo\branches\1.1 directory, so I tried building from a shorter directory ( C:\geronimo1.1 ) and still have issues (see below). I haven't had a chance to look into this yet but I consider this to be a blocker. Once we can build on windows we then need to test that Geronimo can be installed in common locations on windows (e.g. under C:\Program Files\Geronimo-1.1 ) without encountering file path length issues. The following path (from the output below) is 317 bytes long: C:\geronimo1.1\assemblies\j2ee-installer\target\geronimo-1.1-SNAPSHOT\repository\geronimo\daytrader-derby-jetty\1.1-SNAPSHOT\daytrader-derby-jetty-1.1-SNAPSHOT.car\daytrader-web-1.1-SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis\client\GenericServiceEndpointWrapper$$EnhancerByCGLIB$$2ae63e1d.class See http://issues.apache.org/jira/browse/GERONIMO-1790 for more info on the long file path issue. John 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 : C:\geronimo1.1\assemblies\j2ee-installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml [java] -> Output : C:\geronimo1.1\assemblies\j2ee-installer/target/geronimo-installer-1.1-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] 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: ProcessPanel.Spec.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:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal one-compiler-custom-3.8.0.jar!/bin/panels/HelloPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal one-compiler-custom-3.8.0.jar!/bin/panels/LicencePanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal one-compiler-custom-3.8.0.jar!/bin/panels/TargetPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal one-compiler-custom-3.8.0.jar!/bin/panels/ImgPacksPanel.jar [java] Add
G1.1 testing - default applications
The welcome app, servlets-examples, jsp-examples and ldap-demo work fine (unchanged) for both tomcat and jetty with the latest G1.1 build.. Will now try the clustering example and others.. -Dave-
Package upgrades for Geronimo
I took a quick swag at identifying the current package levels in Geronimo 1.0 and 1.1 as well as identifying the most recent stable build for each package. It may be useful to reference the table when determining which packages we should upgrade for G1.1, 1.2 , etc.. Here's the link: http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking Feel free to correct any inaccuracies or provide updates for the table.. -Dave-
Re: Multiple servers sharing the same repo and config store
Can you please elaborate a bit more on what exactly this provides? Can I now have two separate instances each with their own unique applications/configurations/logs (i.e. config-store, deploy and var directories) sharing the same geronimo installation binaries (i.e. bin, lib and repository directories)? If so, how do we create the additional instances? I assume the binary distribution creates the the first instance during the build and that users need to create the additional instances manually for now.. Thanks -Dave- Gianny Damour wrote: Hi, The second solution has been implemented. When starting G, it is now possible to specify one of these two system properties: * org.apache.geronimo.server.name: name of the server to be started. If "server1" is specified, then G will use the directory installation dir>/server1; or * org.apache.geronimo.server.dir: directory of the server to be started. This can be either a relative or an absolute path. For instance, if "./server1" is specified, then G will use the directory installation dir>/server1. I still need to provide a patch for an AMQ GBean, JournalPersistenceAdapterGBean, in order to resolve its directory attribute based on the server directory - will do that during the day. Thanks, Gianny David Jencks wrote: On Feb 12, 2006, at 9:17 AM, Vincent Massol wrote: Hi David and everyone, Any progress on this? not yet, sorry. it is pretty easy, but I am tied up in the configid branch right now. david jencks Thanks -Vincent -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 08:23 To: dev@geronimo.apache.org Subject: Multiple servers sharing the same repo and config store Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are "located" outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to "relocate". I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like "resolveVar" and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the "var" trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now "var". Several people have suggested putting an additional config-store into var for "private" use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
Re: Error in 1.0 branch - maven m:fresh-checkout
Ah.. just found Jacek's post on this subject from yesterday.. Dave Colasurdo wrote: Anyone have any insight on the following error when issuing m:fresh-checkout on the 1.0 branch? I'm seeing it on two different machines.. Thanks -Dave- AUM:/home/davecola/geronimo_1.0_branch_try2 # maven m:fresh-checkout __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-2 DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:start: m:fresh-checkout: m:checkout: [exec] Error validating server certificate for 'https://svn.codehaus.org:443': [exec] - The certificate is not issued by a trusted authority. Use the [exec]fingerprint to validate the certificate manually! [exec] Certificate information: [exec] - Hostname: *.codehaus.org [exec] - Valid: from Apr 6 00:00:00 2005 GMT until Apr 6 23:59:59 2006 GMT [exec] - Issuer: (c)2002 Comodo Limited, Terms and Conditions of use: http://www.comodo.net/repository, Comodo Trust Network, Comodo Limited, GB [exec] - Fingerprint: 4f:ad:4a:ad:05:b1:1d:3e:4b:5f:94:ad:07:db:7d:40:90:18:63:39 [exec] (R)eject, accept (t)emporarily or accept (p)ermanently? svn: PROPFIND request failed on '/openejb/branches/v2_0/openejb2' [exec] svn: PROPFIND of '/openejb/branches/v2_0/openejb2': Server certificate verification failed: issuer is not trusted (https://svn.codehaus.org) [exec] [ERROR] Result: 1 [exec] At revision 375684. BUILD SUCCESSFUL Total time : 23 seconds Finished at : Tuesday, February 7, 2006 3:47:10 PM EST Thanks -Dave-
Error in 1.0 branch - maven m:fresh-checkout
Anyone have any insight on the following error when issuing m:fresh-checkout on the 1.0 branch? I'm seeing it on two different machines.. Thanks -Dave- AUM:/home/davecola/geronimo_1.0_branch_try2 # maven m:fresh-checkout __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-2 DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:start: m:fresh-checkout: m:checkout: [exec] Error validating server certificate for 'https://svn.codehaus.org:443': [exec] - The certificate is not issued by a trusted authority. Use the [exec]fingerprint to validate the certificate manually! [exec] Certificate information: [exec] - Hostname: *.codehaus.org [exec] - Valid: from Apr 6 00:00:00 2005 GMT until Apr 6 23:59:59 2006 GMT [exec] - Issuer: (c)2002 Comodo Limited, Terms and Conditions of use: http://www.comodo.net/repository, Comodo Trust Network, Comodo Limited, GB [exec] - Fingerprint: 4f:ad:4a:ad:05:b1:1d:3e:4b:5f:94:ad:07:db:7d:40:90:18:63:39 [exec] (R)eject, accept (t)emporarily or accept (p)ermanently? svn: PROPFIND request failed on '/openejb/branches/v2_0/openejb2' [exec] svn: PROPFIND of '/openejb/branches/v2_0/openejb2': Server certificate verification failed: issuer is not trusted (https://svn.codehaus.org) [exec] [ERROR] Result: 1 [exec] At revision 375684. BUILD SUCCESSFUL Total time : 23 seconds Finished at : Tuesday, February 7, 2006 3:47:10 PM EST Thanks -Dave-
[jira] Commented: (GERONIMO-1577) Installer - User Interface changes
[ http://issues.apache.org/jira/browse/GERONIMO-1577?page=comments#action_12365077 ] Dave Colasurdo commented on GERONIMO-1577: -- The Izpack guy(s) are looking into item 1 (dependencies and indentation) and will get back to us on Monday. Their initial feedback looks promising. > Installer - User Interface changes > -- > > Key: GERONIMO-1577 > URL: http://issues.apache.org/jira/browse/GERONIMO-1577 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1, 1.1 > Reporter: Dave Colasurdo > > The Installer should consider changing the following: > 1) Represent the PacksPanel dependencies visually in a hierarchical tree > (I'm awaiting a rsp on ipack mailing list to see if this is possible) > 2) Suppress the dependencies box on the PacksPanel (I'm awaiting rsp on > iPack mailing list to see if this is possible) > 3) The Configuration Checkpoint page should include a list of all the > selected options and a summary of their combined sizes. Title on this page > ahould be updated to "Install Confirmation Panel" > 4) The Processing Panel - this panel shows up and executes afterit appears > that the install has already completed. Would be nice to have a better > description title on the page "Installing configurations and Applications" > and a better indication of success when the install completes. -- 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-1577) Installer - User Interface changes
Installer - User Interface changes -- Key: GERONIMO-1577 URL: http://issues.apache.org/jira/browse/GERONIMO-1577 Project: Geronimo Type: Improvement Components: installer Versions: 1.0.1, 1.1 Reporter: Dave Colasurdo The Installer should consider changing the following: 1) Represent the PacksPanel dependencies visually in a hierarchical tree (I'm awaiting a rsp on ipack mailing list to see if this is possible) 2) Suppress the dependencies box on the PacksPanel (I'm awaiting rsp on iPack mailing list to see if this is possible) 3) The Configuration Checkpoint page should include a list of all the selected options and a summary of their combined sizes. Title on this page ahould be updated to "Install Confirmation Panel" 4) The Processing Panel - this panel shows up and executes afterit appears that the install has already completed. Would be nice to have a better description title on the page "Installing configurations and Applications" and a better indication of success when the install completes. -- 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: differences between installer installation and tomcat/jetty installations
Erik Daughtrey wrote: On Wednesday 01 February 2006 03:09, David Jencks wrote: On Jan 31, 2006, at 9:08 PM, John Sisson wrote: 1) In the 1.0 branch I noticed that an installer installation has geronimo/repository/geronimo/cars directory (containing approx 42 MB of car files) but the tomcat & jetty assemblies don't have the car directory. Is this intended? Yes When are car files in the repository used? During final processing, the ConfigInstaller runs which installs the cars associated with the selected packs into the config-store. The ConfigInstaller reads var/config/configure.xml to determine which cars need to be installed. Configure.xml is created by the assembly plugin, but contains variables to be replaced at install time to inform ConfigInstaller of which cars need to be installed. Assuming these aren't needed after installation, can/should these files be deleted by the installer therefore saving 42M? I know diskpace is cheap, though it is one of the measurements that gets used when comparisons are done against other application servers. Does this directory need to be retained when advancedMode is true? I think this is an artifact of the way the installer is working right now, namely including a repo inside it and copying everything into the server under construction, whether or not it is used. I want it to install only the stuff you select. 2) I also noticed that in the installer installation using the default options, the following files (that are installed for the jetty/tomcat assemblies) are not installed: I fixed this with the patch on GERONIMO-1518. Originally, I had missed the dependency in project.xml and the files were not copied to target. geronimo/repository/jars/geronimo-javamail-transport-1.0.1- SNAPSHOT.jar geronimo/repository/jars/geronimo-mail-1.0.1-SNAPSHOT.jar What happens if the user initially does not select SMTP transport (the default) in the installer and then after installation changes their mind? How are we expecting the user to get it installed? Interesting question. There are some interesting options here. 1. If one uses the installer in default mode, the situation mentioned will occur. For instance, if javamail is not selected, then it will not be installed and the easiest remedy is a reinstall. 2. If, however, one uses the -Dadvancedmode=true mode of the the installer, then it's possible to install the configuration, but have it inactive at runtime. It'll be in the config, but not running in the server. Of course, with item #1, it's possible to install everything and disable unwanted items in config.xml manually and achieve the same goal. 3. There's actually a third option that's not exposed well (yet?). One might install everything with the advanced installer then delete everything in config-store, modify configure.xml, run ConfigInstaller to get a new configuration and modify config.xml accordingly. Of course, this would be for very advanced folks. In the future, it may be worth considering "late-feature addition". The user can rerun the installer, it detects what is already installed and allows the user to select and install additional components. Of course, I realize that izpack probably doesn't lend itself to this and am not suggesting this for any current release. Just wanted to throw out the idea for the future. For now, option 1 seems fine. Due to my theory about (1), I think that these are simply left out of the installers internal repo and so the mail config may not work. As noted in (1) in my opinion these should get copied into the server under construction only if you select the mail configuration for installation. 1518 accomplishes this. thanks david jencks Thanks, John
Re: Roadmap, tasks and things to do?
We also need to decide whether Geronimo will provide any of the following: -Incremental Update - Provide a mechanism that allows users to apply fixes from a "dot" release to an existing *binary* installation (e.g. apply 2.0.1 fixes (jars) to an existing 2.0 installation) -Migration - Provide a mechanism to migrate applications and configurations to a later release (e.g. user upgrade from 1.0 -> 2.0) Basically providing easy ways for users to move to later versions of code. -Dave- Dain Sundstrom wrote: Ever since we shipped 1.0, I have been getting a surprising number of private emails from old fiends, old Geronimo contributers, companies, and just random people telling me that the are excited about Geronimo and want to join in. They all inevitably ask me for advise on what to work on, and I really have no idea other than "look at JIRA". So I'd like to solicit the community to help me create a roadmap, tasks, things to do list, what ever we call it. Before we get into building this, I'd like to focus the discussion, so we don't end up in mailing-list fantasy land :) Lets agree to not talk about the technology used to track the tasks; once we have the content we can discuss using JIRA, wiki, html or creating a Gopher site. Secondly, lets focus on things that are reasonable to do in the next 9 months. Finally, don't worry about someone else working on something you want to work on. With open communication on the mailing list, I think everyone will be able to work something they find interesting without stepping on toes. Oh, one final thing, please don't try to "take a task" until we have this list complete. Without further delay, here are some things off the top of my head: o Conversion to Maven 2 - Very important and a huge task o Ant versions of the Geronimo plugins o XDoclet for all configurations o Integration tests that cover servlets, webservices and jms o Little-G - Geronimo with a small foot print o Global non-persistent JNDI implementation o EJB 2.x - Once I get my refractor committed, it will be obvious where the 2.x implementation needs work like better caching o JEE 5 - There is a ton of stuff under this, but it would be good to start with a list of what is required for JEE 5 I don't want to speak for the other ares of Geronimo I don't work on regularly, but I am sure that there are good opportunities to help in the console, jms, javamail, ejb, clustering, esb/jbi/bpm, tooling, performance, build, testing, samples, documentation, so if you are more familiar with one of those areas, please post. I think this is a "once in a project chance" to build a big vibrant community of developers, and let's not let it pass us by. Thanks in advance, -dain
Re: Multiple servers sharing the same repo and config store
As far as directory structure, it seems that WebSphere separates the binaries (e.g. jars, scripts) from the instance data. Each instance has it's own copy of configuration data, installed applications, logs and properties. The scripts (e.g. startup/shutdown) are also available in each instance such that the user doesn't need to specify any environmental variables or parameters to indicate "which instance" when executing the scripts. -Dave- Dain Sundstrom wrote: Does anyone know how other J2EE servers structure their directories when they have multiple instances configured? -dain On Jan 30, 2006, at 5:04 AM, Aaron Mulder wrote: This sounds reasonable to me. I'd prefer to have resolveServer and always look for /var under there. If there are multiple config stores, we'll have to figure out how the deploy tool will know which one to use. Perhaps there should be something indicating whether the config store is "writable" at runtime (vs at server construction time) and only the server-specific one would be writeable? Or at least, the tools would default to writeable ones over not? (Right now they'd theoretically deploy to all available config stores, but I think there's an outstanding issue that the Deployer GBean doesn't let you specify a config store even if you wanted to.) Thanks, Aaron On 1/30/06, David Jencks <[EMAIL PROTECTED]> wrote: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are "located" outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to "relocate". I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like "resolveVar" and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the "var" trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now "var". Several people have suggested putting an additional config-store into var for "private" use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
Re: v1.x Installer comments - Long
David Jencks wrote: On Jan 27, 2006, at 5:54 AM, Erik Daughtrey wrote: Given the comments I've gotten, I'm going to change the installer and go back to the behavior where it does not allow the selection of both web container packs to install. I'm going to ditch the additional buttons which allow selected features to be inactive at runtime. We could put this up for a vote, but since there have been very few comments on this topic, I assume that most folks just want an installer that works well. I pretty much strongly prefer the way the installer works now, I think I asked for it to be this way :-) I won't stand in anyones way though. My view is that the installer should present all the options reasonably available. They are MUCH easier to configure in the installer than in any other way, and I think that the additional confusion while using the installer is minimal. I think most folks agree that the vast majority of users will never want to run with two web containers installed. The exceptions that I can think of are: 1) Geronimo developers - who most likely won't ever use the installer 2) Novice users who aren't sure which web container to use and want to try them both out. Rather than confusing them with instructions on how to setup ports for simultaneous containers or instructions on how to switch between web containers (creating two separate config stores or enabling the config to use just certain portions of the same config-store). Isn't it just simpler/easier to have them lay down two separate *isolated* installations for their comparisons? IMHO, the confusion of someone accidentally laying down two web containers outweighs any potential benefit. Concerning the enable/disable of selected components. It seems quite strange to select installation options on panel 1 and then have panel 4 and panel 5 ask if you want the options that you selected on panel 1 enabled. I would guess that an average user might think "Didn't I already tell the installer I want these options installed?" What is the common use case for someone wanting to install an option and then disable it immediately in the installer? Thanks -Dave- thanks david jencks regards, erik On Wednesday 25 January 2006 21:53, Matt Hogstrom wrote: David Jencks wrote: On Jan 25, 2006, at 2:48 PM, Joe Bohn wrote: I agree with Dave on the issue of multiple containers. We had many discussions on this list concerning the number of containers in an image. The result was that we agreed to deliver 2 different assemblies rather than having multiple containers in one assembly. If that was the decision for the assemblies then I would think it makes sense to do the same in the installer. +1 One container per instance will satisfy 99% of the users I suspect. I also agree with Dave that we should revisit the issue of presenting the list of components twice: once to include them in the image and once to activate them in the runtime. I doubt that most users would understand this distinction when initially installing Geronimo. Most other packages consider the activation/ inactivation of components to be post-install setup and choose the defaults that make the most sense. In our case I would expect that all components selected during install would be active by default. I think that is what we have now. I don't see why we shouldn't let people turn them off if they want to. I think for now we should dump them all to disk and then allow them to assemble the user. I don't think were sophisticated enough yet to help users understand the difference. One can refer to them as options available for later configuration (disk bloat) and options for runtime configuration (memory bloat). I'd leave it simple for now. david jencks Joe Dave Colasurdo wrote: Erik Daughtrey wrote: Dave, Thanks for the comments... I made comments below. Would you create installer component JIRAs for the items that make sense? Yep. BTW, has it been decided if the installer is a 1.0.1 or 1.1 item? On Thursday 19 January 2006 17:02, Dave Colasurdo wrote: Looks like the Installer has made quite a bit of progress. Thanks Erik!! I'd like to suggest a few Usabality changes to the current installer.. I'm sure you are already aware of many of these and have plans to update them. Just wanted to provide some input based on my first impression. BTW, I've attempted to provide input based on my thoughts on how this would be perceived from the perspective of a first time user. *Package Selection Panel* 1)The available selections are really a hierarchy -Server --J2EE Features ---Jetty Web Container Jetty Sample Applications ---Tomcat Web Container Tomcat Sample Applications Does Izpack allow you to capture the hierarchy graphically? Not that I've seen. It looks like it's strictly a list box. If not, anyway to i
[jira] Updated: (GERONIMO-1540) Fix security vulnerability in jsp-examples
[ http://issues.apache.org/jira/browse/GERONIMO-1540?page=all ]
Dave Colasurdo updated GERONIMO-1540:
-
Attachment: geronimo-servlet-examples-tomcat-5.5.15.war
examples-cumulative.patch
As suggested by Kevan, have also upgraded servlet-examples to the TC 5.5.15
level.
Have included a *cumulative patch* (examples-cumulative.patch) that covers both
upgrading servlet-examples to 5.5.15 and upgrading jsp-examples to 5.5.15 (plus
security fix from head).. Have also attached the new servlet-example war file
at the TC 5.5.15 with our custom changes..
Have given the two wars each a unique version number to differentiate the
official "5.5.15" released version from the "5.5.15 plus head" version.
Feel free to update the version info if you disagree..
Thanks
-Dave-
> Fix security vulnerability in jsp-examples
> --
>
> Key: GERONIMO-1540
> URL: http://issues.apache.org/jira/browse/GERONIMO-1540
> Project: Geronimo
> Type: Bug
> Components: sample apps
> Versions: 1.0.1, 1.1
> Reporter: Dave Colasurdo
> Assignee: Kevan Miller
> Attachments: examples-cumulative.patch,
> geronimo-jsp-examples-tomcat-5.5.15-plus.war,
> geronimo-servlet-examples-tomcat-5.5.15.war, jsp-examples.patch
>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat
> jsp-examples that are included in Geronimo. It fails on both Jetty and
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console. That
> problem is addressed in GERONIMO-1474.
>
--
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-1540) Fix security vulnerability in jsp-examples
[
http://issues.apache.org/jira/browse/GERONIMO-1540?page=comments#action_12364086
]
Dave Colasurdo commented on GERONIMO-1540:
--
It appears the corruption of the war file was a temporary JIRA problem. The
same war file looks fine today. Please publish the war and the patch at your
convenience..
Thanks
-Dave-
> Fix security vulnerability in jsp-examples
> --
>
> Key: GERONIMO-1540
> URL: http://issues.apache.org/jira/browse/GERONIMO-1540
> Project: Geronimo
> Type: Bug
> Components: sample apps
> Versions: 1.1, 1.0.1
> Reporter: Dave Colasurdo
> Attachments: geronimo-jsp-examples-tomcat-5.5.15-plus.war, jsp-examples.patch
>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat
> jsp-examples that are included in Geronimo. It fails on both Jetty and
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console. That
> problem is addressed in GERONIMO-1474.
>
--
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-1540) Fix security vulnerability in jsp-examples
[
http://issues.apache.org/jira/browse/GERONIMO-1540?page=comments#action_12364012
]
Dave Colasurdo commented on GERONIMO-1540:
--
The original warfile that I've attached seems to work fine on my machine (and
another) though appears to be corrupted when I re-download it from JIRA. It
seems the JIRA system is having problems and I am receiving lots of garbled
info when viewing items. Not yet certain if the two issues are related
though please hold off on publishing the war until the issue is resolved.
Thanks..
-Dave-
> Fix security vulnerability in jsp-examples
> --
>
> Key: GERONIMO-1540
> URL: http://issues.apache.org/jira/browse/GERONIMO-1540
> Project: Geronimo
> Type: Bug
> Components: sample apps
> Versions: 1.0.1, 1.1
> Reporter: Dave Colasurdo
> Attachments: geronimo-jsp-examples-tomcat-5.5.15-plus.war, jsp-examples.patch
>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat
> jsp-examples that are included in Geronimo. It fails on both Jetty and
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console. That
> problem is addressed in GERONIMO-1474.
>
--
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-1540) Fix security vulnerability in jsp-examples
[ http://issues.apache.org/jira/browse/GERONIMO-1540?page=all ]
Dave Colasurdo updated GERONIMO-1540:
-
Geronimo Info: [Patch Available]
> Fix security vulnerability in jsp-examples
> --
>
> Key: GERONIMO-1540
> URL: http://issues.apache.org/jira/browse/GERONIMO-1540
> Project: Geronimo
> Type: Bug
> Components: sample apps
> Versions: 1.0.1, 1.1
> Reporter: Dave Colasurdo
> Attachments: geronimo-jsp-examples-tomcat-5.5.15-plus.war, jsp-examples.patch
>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat
> jsp-examples that are included in Geronimo. It fails on both Jetty and
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console. That
> problem is addressed in GERONIMO-1474.
>
--
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-1540) Fix security vulnerability in jsp-examples
[ http://issues.apache.org/jira/browse/GERONIMO-1540?page=all ]
Dave Colasurdo updated GERONIMO-1540:
-
Attachment: jsp-examples.patch
geronimo-jsp-examples-tomcat-5.5.15-plus.war
> Fix security vulnerability in jsp-examples
> --
>
> Key: GERONIMO-1540
> URL: http://issues.apache.org/jira/browse/GERONIMO-1540
> Project: Geronimo
> Type: Bug
> Components: sample apps
> Versions: 1.0.1, 1.1
> Reporter: Dave Colasurdo
> Attachments: geronimo-jsp-examples-tomcat-5.5.15-plus.war, jsp-examples.patch
>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat
> jsp-examples that are included in Geronimo. It fails on both Jetty and
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console. That
> problem is addressed in GERONIMO-1474.
>
--
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-1540) Fix security vulnerability in jsp-examples
[
http://issues.apache.org/jira/browse/GERONIMO-1540?page=comments#action_12364003
]
Dave Colasurdo commented on GERONIMO-1540:
--
The Tomcat team has fixed this in their open builds (but *not* in Tomcat
5.5.15). I've extracted the latest Tomcat source and built it to get the
latest binary image of the jsp-examples.
Tomcat info:
Path: .
URL: http://svn.apache.org/repos/asf/tomcat/current/tc5.5.x
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 372275
Node Kind: directory
Schedule: normal
Last Changed Author: remm
Last Changed Rev: 344145
Last Changed Date: 2005-11-14 10:19:03 -0500 (Mon, 14 Nov 2005)
Properties Last Updated: 2006-01-25 12:21:02 -0500 (Wed, 25 Jan 2006)
Also, merged our custom geronimo changes to the war file and change the
geronimo build to pickup the new warfile.
I've provided a geronimo patch for the 1.0 branch and anupdated war file.
The attached warfile needs to get published to
http://svn.apache.org/repository/geronimo-samples/wars/ prior to committing the
patch.
> Fix security vulnerability in jsp-examples
> --
>
> Key: GERONIMO-1540
> URL: http://issues.apache.org/jira/browse/GERONIMO-1540
> Project: Geronimo
> Type: Bug
> Components: sample apps
> Versions: 1.0.1, 1.1
> Reporter: Dave Colasurdo
>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat
> jsp-examples that are included in Geronimo. It fails on both Jetty and
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console. That
> problem is addressed in GERONIMO-1474.
>
--
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-1540) Fix security vulnerability in jsp-examples
[ http://issues.apache.org/jira/browse/GERONIMO-1540?page=all ]
Dave Colasurdo updated GERONIMO-1540:
-
Component: sample apps
Version: 1.0.1
1.1
> Fix security vulnerability in jsp-examples
> --
>
> Key: GERONIMO-1540
> URL: http://issues.apache.org/jira/browse/GERONIMO-1540
> Project: Geronimo
> Type: Bug
> Components: sample apps
> Versions: 1.0.1, 1.1
> Reporter: Dave Colasurdo
>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat
> jsp-examples that are included in Geronimo. It fails on both Jetty and
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console. That
> problem is addressed in GERONIMO-1474.
>
--
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-1540) Fix security vulnerability in jsp-examples
Fix security vulnerability in jsp-examples
--
Key: GERONIMO-1540
URL: http://issues.apache.org/jira/browse/GERONIMO-1540
Project: Geronimo
Type: Bug
Reporter: Dave Colasurdo
Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat
jsp-examples that are included in Geronimo. It fails on both Jetty and Tomcat.
This can be reproduced with the following urls:
http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
This JIRA does not address a related problem in the admin console. That
problem is addressed in GERONIMO-1474.
--
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
