Building 1.0 release candidate from source - URL for svn checkout
Hi, Which URL should be used with svn to checkout the source for building 1.0 release candidate? Is it https://svn.apache.org/repos/asf/geronimo/branches/1.0/ or https://svn.apache.org/repos/asf/geronimo/tags/1.0.0/ or something else? Thanks, Vamsi
[jira] Reopened: (GERONIMO-1012) Tomcat integration does not set a subject in an unsecured web module in a secured ejb application
[ http://issues.apache.org/jira/browse/GERONIMO-1012?page=all ] David Jencks reopened GERONIMO-1012: Assign To: David Jencks (was: Jeff Genender) As noted in one of the comments, the previous fix did not work for unprotected pages in a web-app with some secured pages. > Tomcat integration does not set a subject in an unsecured web module in a > secured ejb application > - > > Key: GERONIMO-1012 > URL: http://issues.apache.org/jira/browse/GERONIMO-1012 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0-M5 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0-M5 > > In the jetty integration, in SecurityContextBeforeAfter, a request for an > unsecured page results in the default subject being set in the ContextManager > (line 288). This provides a way to call secured ejbs and also provides a > source for credentials for calling secured web services. > In tomcat, we don't do anything like that: in particular there is no source > of credentials for secured web services. > I think the simplest solution is to, if the app is secured, to add another > valve after the standard tomcat security valve, that sets the default subject > into the ContextManager if none is there already. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1012) Tomcat integration does not set a subject in an unsecured web module in a secured ejb application
[ http://issues.apache.org/jira/browse/GERONIMO-1012?page=all ] David Jencks closed GERONIMO-1012: -- Fix Version: 1.1 (was: 1.0-M5) Resolution: Fixed Jeff pointed out how to add the DefaultSubjectValve after the authentication valve. This fixes the problems for unauthenticated pages in a secured web app. Sending modules/tomcat/src/java/org/apache/geronimo/tomcat/GeronimoStandardContext.java Transmitting file data . Committed revision 366121. > Tomcat integration does not set a subject in an unsecured web module in a > secured ejb application > - > > Key: GERONIMO-1012 > URL: http://issues.apache.org/jira/browse/GERONIMO-1012 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0-M5 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.1 > > In the jetty integration, in SecurityContextBeforeAfter, a request for an > unsecured page results in the default subject being set in the ContextManager > (line 288). This provides a way to call secured ejbs and also provides a > source for credentials for calling secured web services. > In tomcat, we don't do anything like that: in particular there is no source > of credentials for secured web services. > I think the simplest solution is to, if the app is secured, to add another > valve after the standard tomcat security valve, that sets the default subject > into the ContextManager if none is there already. -- 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: geronimo-web.xml, container-config, container-specific namespaces
David Jencks wrote: It is possible (I think) to do what you want, but I do not recommend it. I would prefer that you use external plans, and write 2 new modules inside configs, to deploy your sample to jetty and to tomcat. Take the geronimo-web.xml out of the app and put it in src/ plan/plan.xml. However, if you wish to defy me :-) you can use the generic schema http://geronimo.apache.org/xml/ns/j2ee/web-1.0 (geronimo- web-1.0.xsd) with sections in a container-config for the jetty and tomcat specific parts. These would use the namespace/schemas e.g. http://geronimo.apache.org/xml/ns/web/jetty/config-1.0 (geronimo- jetty-config-1.0.xsd). I really feel that it is valuable for WADI-enabled apps to port easily between Jetty and Tomcat (and hopefully other)-based containers. I would be much happier with one proprietary dd or plan, than two. So, I am still on course for somehow merging the two. As to whether this dd/plan lives in or outside the deployable - I'm not to worried. I imagine that WADI will ship its demo webapp with the dd inside for self-containedness' sake, but I have no religious views on the subject. A problem with this approach might be that you are including a gbean in the tomcat config that is not needed in the jetty config. I don't understand why this would be there anyway, but I don't think you can have gbeans in the container-config part. Is it possible to adjust the jetty and tomcat clustering configs to be roughly the same and include the element in geronimo-web-1.0.xsd? I think some form of adjustment here will be the sensible way forward. Thanks for the pointers, Jules hope this helps david jencks On Jan 4, 2006, at 10:19 AM, Jules Gosnell wrote: Aaron, David, or anyone in the know :-) Maybe you can help me with this: I have a WADI demo webapp. To get it running with Jetty, I need a WEB-INF/geronimo-web.xml that looks like this: http://geronimo.apache.org/xml/ns/j2ee/web/ jetty-1.0" configId="wadi"> /wadi false org.codehaus.wadi.jetty5.JettyManagermanager> To get it running with Tomcat, I have to have a geronimo-web.xml that looks like this: http://geronimo.apache.org/xml/ns/j2ee/web/ tomcat-1.0" configId="wadi"> /wadi false WADI class="org.apache.geronimo.tomcat.cluster.WADIGBean"/> What I would like, is a single geronimo-web.xml that contains both Jetty and TC configs, merged. Do you know if this is possible, if so, would you mind pointing me in the right direction ? Much appreciated, Jules Aaron Mulder wrote: David J, I thought when you added the separate Tomcat and Jetty namespaces, you were going to remove the container-config section from the generic geronimo-web.xml, but it seems that it's still there. Jeff thinks maybe it's for something like the console, where we want it to work in both Tomcat and Jetty yet we might still require some container-specific extensions (makes sense to me). If we're going to keep the generic geronimo-web.xml and keep the container-config section in it, can we drop the container-specific namespaces? I think you favored the namespaces because if you use a container-specific namespace then any container-specific settings could be validated in XML, but I think that's pretty useless if it only applies if you're willing to force your app to only deploy in one container or the other. (That is to say, if you want your web app to run in either Tomcat or Jetty -- which is probably the normal case, then you can't use a container-specific namespace so it doesn't matter what the benefits of container-specific namespaces are.) The only way I can see the container-specific namespaces being beneficial is if the container-config became an "any" and then we namespaced the content that went within it -- so the overall file always used the generic namespace but then you used a container-specific one for the contents of the container-config element only. Am I missing something? Thanks, Aaron -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/ -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
Re: geronimo-web.xml, container-config, container-specific namespaces
Aaron Mulder wrote: Well... is it possible to make this not specific to WADI? Perhaps make it a generic "clustering manager" tag, and is "just so happens" that the only classes we let you configure so far are the WADI ones? Ideally, we'd put some generic interface in the Geronimo space, and then the WADI ones would implement or extend that, so if we ever wanted to integrate other clustering options we'd leave that door open. Thanks, Aaron This is a good idea but - The choice of WADI class passed in is container specific. For Jetty you use a WADI class that implements the Jetty Session Manager interface, for TC likewise. Jetty and TC Session Managers do not implement a common interface. We could look at defining a third interface - e.g. GeronimoWebSessionManager - but I see no gain in that, since by implementing it, you do not guarantee that your session manager will work in Jetty or TC. It just adds yet more layers of abstraction. WADI will soon be in the incubator and an integral part of Geronimo. If we want to abstract anything between web session managers, I think it should be done in WADI, as it is (Jetty and TC managers both wrap and translate/delegate calls to a single WADI Manager interface). How does that sound ? Jules On 1/4/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Hi, Actually...this is quite simple... Use the generic web. Have a new tag...call it , or whatever. Each of the container's builders can then have a flag set that is passed into its web context. The web context can then set its own implementation...i.e. for Jetty, it then can create and apply its own org.codehaus.wadi.jetty5.JettyManager and for Tomcat it can create and apply its org.codehaus.wadi.tomcat55.TomcatManager. No need for GBeans if WADI is to become a first class citizen. The Tomcat GBean is purely for the ability to declaratively swap out managers. Thus, this will allow for a single ability to set up a generic tag that both containers can understand how to act upon. Jeff David Jencks wrote: It is possible (I think) to do what you want, but I do not recommend it. I would prefer that you use external plans, and write 2 new modules inside configs, to deploy your sample to jetty and to tomcat. Take the geronimo-web.xml out of the app and put it in src/plan/plan.xml. However, if you wish to defy me :-) you can use the generic schema http://geronimo.apache.org/xml/ns/j2ee/web-1.0 (geronimo-web-1.0.xsd) with sections in a container-config for the jetty and tomcat specific parts. These would use the namespace/schemas e.g. http://geronimo.apache.org/xml/ns/web/jetty/config-1.0 (geronimo-jetty-config-1.0.xsd). A problem with this approach might be that you are including a gbean in the tomcat config that is not needed in the jetty config. I don't understand why this would be there anyway, but I don't think you can have gbeans in the container-config part. Is it possible to adjust the jetty and tomcat clustering configs to be roughly the same and include the element in geronimo-web-1.0.xsd? hope this helps david jencks On Jan 4, 2006, at 10:19 AM, Jules Gosnell wrote: Aaron, David, or anyone in the know :-) Maybe you can help me with this: I have a WADI demo webapp. To get it running with Jetty, I need a WEB-INF/geronimo-web.xml that looks like this: http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0"; configId="wadi"> /wadi false org.codehaus.wadi.jetty5.JettyManager To get it running with Tomcat, I have to have a geronimo-web.xml that looks like this: http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0"; configId="wadi"> /wadi false WADI What I would like, is a single geronimo-web.xml that contains both Jetty and TC configs, merged. Do you know if this is possible, if so, would you mind pointing me in the right direction ? Much appreciated, Jules Aaron Mulder wrote: David J, I thought when you added the separate Tomcat and Jetty namespaces, you were going to remove the container-config section from the generic geronimo-web.xml, but it seems that it's still there. Jeff thinks maybe it's for something like the console, where we want it to work in both Tomcat and Jetty yet we might still require some container-specific extensions (makes sense to me). If we're going to keep the generic geronimo-web.xml and keep the container-config section in it, can we drop the container-specific namespaces? I think you favored the namespaces because if you use a container-specific namespace then any container-specific settings could be validated in XML, but I think that's pretty useless if it only applies if you're willing to force your app to only deploy in one container or the other. (That is to say, if you want your web app to run in either Tomcat or Jetty -- which is probably the normal case, then you can't use a container-specific namespace so it doesn't matter what the benefits of container-specific namespaces are.) Th
Re: [wadi-dev] Re: geronimo-web.xml, container-config, container-specific namespaces
After further thought... I imagine it going like this: container checks for the WEB-INF/web.xml/ tag. If it exists, container looks at the e.g. geronimo-web.xml/ tag. The value of this tag could be either an enum (e.g. {WADI,...}), a classname or the name of some existing component (GBean) (any other ideas?) I don't like the enum based solution - it just leads to more code and documentation to ties the key to its value. The classname version assumes a void ctor and a separate instance of the class for each webapp (I think there may be a case for being able to share a session manager across web contexts - but the jury is still out). The GBean version delegates full control over the construction and configuration to Geronimo whilst allowing the possibility of either shared or individual session manager instances. I think that I would prefer this route. Ultimately, I might also like to see an e.g. tag in the geronimo-web.xml as well, allowing the selection of session managers in a non-distributable mode. WADI willl run in this mode, as do other Tomcat session managers that might be selected via this mechanism (I'm not sure whether the standalone mechanism for session manager selection has been exposed for TC or not). Thoughts ? Jules Jules Gosnell wrote: Aaron Mulder wrote: Well... is it possible to make this not specific to WADI? Perhaps make it a generic "clustering manager" tag, and is "just so happens" that the only classes we let you configure so far are the WADI ones? Ideally, we'd put some generic interface in the Geronimo space, and then the WADI ones would implement or extend that, so if we ever wanted to integrate other clustering options we'd leave that door open. Thanks, Aaron This is a good idea but - The choice of WADI class passed in is container specific. For Jetty you use a WADI class that implements the Jetty Session Manager interface, for TC likewise. Jetty and TC Session Managers do not implement a common interface. We could look at defining a third interface - e.g. GeronimoWebSessionManager - but I see no gain in that, since by implementing it, you do not guarantee that your session manager will work in Jetty or TC. It just adds yet more layers of abstraction. WADI will soon be in the incubator and an integral part of Geronimo. If we want to abstract anything between web session managers, I think it should be done in WADI, as it is (Jetty and TC managers both wrap and translate/delegate calls to a single WADI Manager interface). How does that sound ? Jules On 1/4/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Hi, Actually...this is quite simple... Use the generic web. Have a new tag...call it , or whatever. Each of the container's builders can then have a flag set that is passed into its web context. The web context can then set its own implementation...i.e. for Jetty, it then can create and apply its own org.codehaus.wadi.jetty5.JettyManager and for Tomcat it can create and apply its org.codehaus.wadi.tomcat55.TomcatManager. No need for GBeans if WADI is to become a first class citizen. The Tomcat GBean is purely for the ability to declaratively swap out managers. Thus, this will allow for a single ability to set up a generic tag that both containers can understand how to act upon. Jeff David Jencks wrote: It is possible (I think) to do what you want, but I do not recommend it. I would prefer that you use external plans, and write 2 new modules inside configs, to deploy your sample to jetty and to tomcat. Take the geronimo-web.xml out of the app and put it in src/plan/plan.xml. However, if you wish to defy me :-) you can use the generic schema http://geronimo.apache.org/xml/ns/j2ee/web-1.0 (geronimo-web-1.0.xsd) with sections in a container-config for the jetty and tomcat specific parts. These would use the namespace/schemas e.g. http://geronimo.apache.org/xml/ns/web/jetty/config-1.0 (geronimo-jetty-config-1.0.xsd). A problem with this approach might be that you are including a gbean in the tomcat config that is not needed in the jetty config. I don't understand why this would be there anyway, but I don't think you can have gbeans in the container-config part. Is it possible to adjust the jetty and tomcat clustering configs to be roughly the same and include the element in geronimo-web-1.0.xsd? hope this helps david jencks On Jan 4, 2006, at 10:19 AM, Jules Gosnell wrote: Aaron, David, or anyone in the know :-) Maybe you can help me with this: I have a WADI demo webapp. To get it running with Jetty, I need a WEB-INF/geronimo-web.xml that looks like this: http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0"; configId="wadi"> /wadi false org.codehaus.wadi.jetty5.JettyManager To get it running with Tomcat, I have to have a geronimo-web.xml that looks like this: xmlns="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0"; configId="wadi"> /wadi false WADI
Regd OpenEJB
Hi Gianny, I have a question on CMR Consider a Bean A and a bean B in a one to many CMR relationship Here A has 2 fields in the PK say a1 and a2 B has b1 fka1 and fka2 as the pk where fka1 and fka2 are the foreign keys corressponding to the a1 and a2 of A. In the ejbCreate of B when we set fka1 and fka2 won't OpenEJB throw an error saying that they are readonly fields. This will happen even after implementing the logic for the special case where the CompoundPK has 1 field. Is this scenario a valid scenario? If so can we change the check in createCMPFieldAccessors to check for primary key and allow write access to CMR fields if they are parts of Primary Keys? What should be the correct behaviour? Thanks Manu
Re: geronimo-web.xml, container-config, container-specific namespaces
Aaron Mulder wrote: > Well... is it possible to make this not specific to WADI? Perhaps > make it a generic "clustering manager" tag, and is "just so happens" > that the only classes we let you configure so far are the WADI ones? > Ideally, we'd put some generic interface in the Geronimo space, and > then the WADI ones would implement or extend that, so if we ever > wanted to integrate other clustering options we'd leave that door > open. +1 I really think that clustering contents of geronimo-web.xml needs to be moved out of the webapplication. Clustering should be configured once and only once for the whole server - not within each web application (also we have to consider EJB clustering which does not have a webapp). So I really see that we need a new module called "cluster" (or "wadi" if we want to persist with the implementation exposure we have with jetty and tomcat). If the only web container specific part of the configuration is to choose the class type of the session manager, then I think that this could almost be hard coded in the jetty and tomcat modules - when they see a distributable tag, they look for a cluster/wadi gbean and instantiate a specific session manager that is required to work with it. If there is other web app specific configuration, then it can be left in a geronimo-web.xml, but hopefully as a non container specific nature. cheers
Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]
Sorry guys but -1 I've just had a report of a security issue in Jetty that reveals the contents of WEB-INF on win32 platforms.Happy f*ing new year! I have a fix and will be making a release very shortly. To avoid any other issues, I will probably roll back the other changes in HEAD so only this fix will go in. But if it really is too late to change the jetty version, then -0 regards
Re: geronimo-web.xml, container-config, container-specific namespaces
Greg Wilkins wrote: Aaron Mulder wrote: Well... is it possible to make this not specific to WADI? Perhaps make it a generic "clustering manager" tag, and is "just so happens" that the only classes we let you configure so far are the WADI ones? Ideally, we'd put some generic interface in the Geronimo space, and then the WADI ones would implement or extend that, so if we ever wanted to integrate other clustering options we'd leave that door open. +1 I really think that clustering contents of geronimo-web.xml needs to be moved out of the webapplication. Clustering should be configured once and only once for the whole server - not within each web application (also we have to consider EJB clustering which does not have a webapp). So I really see that we need a new module called "cluster" (or "wadi" if we want to persist with the implementation exposure we have with jetty and tomcat). If the only web container specific part of the configuration is to choose the class type of the session manager, then I think that this could almost be hard coded in the jetty and tomcat modules - when they see a distributable tag, they look for a cluster/wadi gbean and instantiate a specific session manager that is required to work with it. If there is other web app specific configuration, then it can be left in a geronimo-web.xml, but hopefully as a non container specific nature. cheers We are having a discussion about this on wadi-dev at the moment. There are two approaches - per-app and per-server. Setting up clustering in the geronimo-web.xml corresponds to the per-app approach. Perhaps we could have an e.g. default-geronimo-web.xml in the server somewhere that sets up a server wide configuration. For the per-server model that you advocate, we need some way of allowing webapps to 'own' their own session manager instance, whilst sharing components between these session managers, such as distribution medium etc. WADI has initially been very focussed on the per-app approach, as this is currently the only way to shoe-horn it into the various containers that it supports, so further thought is needed here. I suggest that Geronimo will want to support both approaches and that we come up with a framework that can do this, whilst pursuing the immediate goal of a per-app solution and then later on pushing towards a per-server based one. Check out my other posting on this thread that advocates a top-level-gbean approach, using the geronimo-web.xml to hook it into the web-app context. Perhaps a SessionManagerFactoryGBean could be used on a per-server basis to create individual SessionManagers (for each app) that can then share further server-wide resources ? Jules -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
Re: geronimo-web.xml, container-config, container-specific namespaces
Greg Wilkins wrote: > Aaron Mulder wrote: >> Well... is it possible to make this not specific to WADI? Perhaps >> make it a generic "clustering manager" tag, and is "just so happens" >> that the only classes we let you configure so far are the WADI ones? >> Ideally, we'd put some generic interface in the Geronimo space, and >> then the WADI ones would implement or extend that, so if we ever >> wanted to integrate other clustering options we'd leave that door >> open. > > +1 > > I really think that clustering contents of geronimo-web.xml needs to > be moved out of the webapplication. Clustering should be configured once > and only once for the whole server - not within each web application (also > we have to consider EJB clustering which does not have a webapp). I don't agree on this point. You should be able to specify certain web apps that need clustering and others that do not. IMHO, you should be able to cluster the components that you want, and not turn it on for the entire server. The Tomcat clustering works this way today. I can turn on clustering at the Engine, host, or context level. > > So I really see that we need a new module called "cluster" (or "wadi" if > we want to persist with the implementation exposure we have with > jetty and tomcat). > > If the only web container specific part of the configuration is to > choose the class type of the session manager, then I think that this could > almost be hard coded in the jetty and tomcat modules - when they see > a distributable tag, they look for a cluster/wadi gbean and instantiate > a specific session manager that is required to work with it. > > If there is other web app specific configuration, then it can be > left in a geronimo-web.xml, but hopefully as a non container specific > nature. > > cheers > > >
[jira] Created: (GERONIMO-1419) javax.mail.internet.InternetHeaders has some non implemented features
javax.mail.internet.InternetHeaders has some non implemented features - Key: GERONIMO-1419 URL: http://issues.apache.org/jira/browse/GERONIMO-1419 Project: Geronimo Type: Bug Components: specs Reporter: Guillaume Nodet Attachments: GERONIMO-1419.patch Some methods throw a UnsupportedOperationException -- 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-1419) javax.mail.internet.InternetHeaders has some non implemented features
[ http://issues.apache.org/jira/browse/GERONIMO-1419?page=all ] Guillaume Nodet updated GERONIMO-1419: -- Attachment: GERONIMO-1419.patch Patch for non implemented methods in javax.mail.internet.InternetHeaders > javax.mail.internet.InternetHeaders has some non implemented features > - > > Key: GERONIMO-1419 > URL: http://issues.apache.org/jira/browse/GERONIMO-1419 > Project: Geronimo > Type: Bug > Components: specs > Reporter: Guillaume Nodet > Attachments: GERONIMO-1419.patch > > Some methods throw a UnsupportedOperationException -- 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: geronimo-web.xml, container-config, container-specific namespaces
In my personal experience, any machine in a cluster is fully in a cluster -- I haven't seen something like 10 machines running 1 clustered app and then each running something else on the side. However, it is kind of nice in WebLogic that you can deploy to either a cluster or a single machine. I would lean toward that kind of approach. You set up clustering at the server level, and then each application can either be deployed to individual servers or to the cluster, but if you don't set up clustering at the server level, there's no cluster to deploy to and you have to deploy to individual servers. (There's plumbing in our deployer so it could support that kind of approach.) Aaron On 1/5/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > > > Greg Wilkins wrote: > > Aaron Mulder wrote: > >> Well... is it possible to make this not specific to WADI? Perhaps > >> make it a generic "clustering manager" tag, and is "just so happens" > >> that the only classes we let you configure so far are the WADI ones? > >> Ideally, we'd put some generic interface in the Geronimo space, and > >> then the WADI ones would implement or extend that, so if we ever > >> wanted to integrate other clustering options we'd leave that door > >> open. > > > > +1 > > > > I really think that clustering contents of geronimo-web.xml needs to > > be moved out of the webapplication. Clustering should be configured once > > and only once for the whole server - not within each web application (also > > we have to consider EJB clustering which does not have a webapp). > > I don't agree on this point. You should be able to specify certain web > apps that need clustering and others that do not. IMHO, you should be > able to cluster the components that you want, and not turn it on for the > entire server. The Tomcat clustering works this way today. I can turn > on clustering at the Engine, host, or context level. > > > > > So I really see that we need a new module called "cluster" (or "wadi" if > > we want to persist with the implementation exposure we have with > > jetty and tomcat). > > > > If the only web container specific part of the configuration is to > > choose the class type of the session manager, then I think that this could > > almost be hard coded in the jetty and tomcat modules - when they see > > a distributable tag, they look for a cluster/wadi gbean and instantiate > > a specific session manager that is required to work with it. > > > > If there is other web app specific configuration, then it can be > > left in a geronimo-web.xml, but hopefully as a non container specific > > nature. > > > > cheers > > > > > > >
Re: geronimo-web.xml, container-config, container-specific namespaces
Aaron Mulder wrote: > In my personal experience, any machine in a cluster is fully in a > cluster -- I haven't seen something like 10 machines running 1 > clustered app and then each running something else on the side. I can't agree...I may want to cluster my app, but I surely do not want to cluster the console. I think there are various use cases that can be applied here. > > However, it is kind of nice in WebLogic that you can deploy to either > a cluster or a single machine. I would lean toward that kind of > approach. You set up clustering at the server level, and then each > application can either be deployed to individual servers or to the > cluster, but if you don't set up clustering at the server level, > there's no cluster to deploy to and you have to deploy to individual > servers. (There's plumbing in our deployer so it could support that > kind of approach.) > > Aaron > > On 1/5/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> >> Greg Wilkins wrote: >>> Aaron Mulder wrote: Well... is it possible to make this not specific to WADI? Perhaps make it a generic "clustering manager" tag, and is "just so happens" that the only classes we let you configure so far are the WADI ones? Ideally, we'd put some generic interface in the Geronimo space, and then the WADI ones would implement or extend that, so if we ever wanted to integrate other clustering options we'd leave that door open. >>> +1 >>> >>> I really think that clustering contents of geronimo-web.xml needs to >>> be moved out of the webapplication. Clustering should be configured once >>> and only once for the whole server - not within each web application (also >>> we have to consider EJB clustering which does not have a webapp). >> I don't agree on this point. You should be able to specify certain web >> apps that need clustering and others that do not. IMHO, you should be >> able to cluster the components that you want, and not turn it on for the >> entire server. The Tomcat clustering works this way today. I can turn >> on clustering at the Engine, host, or context level. >> >>> So I really see that we need a new module called "cluster" (or "wadi" if >>> we want to persist with the implementation exposure we have with >>> jetty and tomcat). >>> >>> If the only web container specific part of the configuration is to >>> choose the class type of the session manager, then I think that this could >>> almost be hard coded in the jetty and tomcat modules - when they see >>> a distributable tag, they look for a cluster/wadi gbean and instantiate >>> a specific session manager that is required to work with it. >>> >>> If there is other web app specific configuration, then it can be >>> left in a geronimo-web.xml, but hopefully as a non container specific >>> nature. >>> >>> cheers >>> >>> >>>
Re: [wadi-dev] Re: [Geronimo] Clustering
Hmm, again we have stopped the discussion :). Lets get it started again. So can we all come to some agreement (with more discussion) on which direction we might be taking !! Like merging ActiveCluster and WADI or getting best of both worlds ? And also if we can define expectations/requirments for what we like for the next possible release (1.01 or whatever) in terms of clustering would give folks like me more direction as to where we should concentrate on? If we decide on a direction maybe a few of us can start on a few prototypes and see what works best for Geronimo. Regards, Rajith Attapattu. On 1/5/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote: -Original Message-From: Jules Gosnell [mailto: [EMAIL PROTECTED]]Sent: Monday, December 19, 2005 9:55 AMTo: [EMAIL PROTECTED]Cc: wadi-dev@incubator.apache.org ; dev@geronimo.apache.orgSubject: Re: [wadi-dev] Re: [Geronimo] ClusteringJames Strachan wrote:>> On 19 Dec 2005, at 14:14, Jules Gosnell wrote: >>> James Strachan wrote:> On 19 Dec 2005, at 11:53, Jules Gosnell wrote:>>> , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code should literally be a few lines. Clients using clusters should not suddenly find themselves sucking down e.g. the whole of activemq, just to do a once off autodiscovery. Early versions of WADI had its own autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of >>> ActiveCluster which doesn't use ActiveMQ - its just a simple API.>> Sure - but I'm talking about the EJB-client side - where we just>> want to throw across as thin a line as possible, in order to haul a >> decent strength cable back. An EJB client would not need the>> ActiveCluster API (I'm not thinking in terms of making EJB clients>> fully fledged cluster members), but simply a way of locating the >> cluster and requesting a membership snapshot of it.>>> Thats exactly what the ActiveCluster API is for :). Though by all> means come up with another API if you can think of a better way of > doing it.>>> This could be done by just broadcasting a query packet at a well>> known multicast address and waiting for the first well-formedresponse.>>> Sure - an *implementation* of ActiveCluster API could do exactly that. >???well, maybe I'm thinking of the wrong piece of activecluster then ?any piece of code could broadcast a packet... which piece ofactivecluster's API are you suggesting here ?we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster.can you be more specific ?Jules> James> ---> http://radio.weblogs.com/0112098/-- "Open Source is a self-assembling organism. You dangle a piece ofstring into a super-saturated solution and a whole operating-systemcrystallises out around it."/** * Jules Gosnell* Partner* Core Developers Network (Europe)**www.coredevelopers.net** Open Source Training & Support.**/
Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]
Greg, I was wrapping up the release last night and was releasing it today based on the prior feedback. Can you provide some more details on the exposure? My preference would be to release G 1.0 as is and fix this in 1.0.1. I need your expert opinion of the exposure WRT to security. There will always be something left to fix this will delay releasing about 1 week to allow for a new review of the code, re-certification, etc. I see a few options at this point. 1. Continue with the release despite this information. 2. Hold the release until this can be fixed (which then also begs the question of moving to the more recent Tomcat version with their fix for 0 content length on POST requests). This will delay the release for at least one week. 3. Ship Geronimo with Tomcat and get 1.0 out the door. We ship with both Tomcat and Jetty for 1.0.1 with this security fix inclued. The security hole you've outlined sounds serious but I was wondering if its a specific set of implementations that could be documented (ie. is this something that someone just found and its a rather obscure config?) Other input welcome. I'm going to complete getting the release ready but defer punching the button until this afternoon (about 1500 PT). Matt Greg Wilkins wrote: Sorry guys but -1 I've just had a report of a security issue in Jetty that reveals the contents of WEB-INF on win32 platforms.Happy f*ing new year! I have a fix and will be making a release very shortly. To avoid any other issues, I will probably roll back the other changes in HEAD so only this fix will go in. But if it really is too late to change the jetty version, then -0 regards
[jira] Created: (GERONIMO-1420) HTTP Status 500 message should refer to geronimo logs
HTTP Status 500 message should refer to geronimo logs - Key: GERONIMO-1420 URL: http://issues.apache.org/jira/browse/GERONIMO-1420 Project: Geronimo Type: Bug Versions: 1.1 Environment: All Reporter: anita kulshreshtha Priority: Trivial When an exception trace is produced by a web app, the message refers to Apache Tomcat/5.5.12 logs. This might be a hard coded message given by tomcat. See if it can be easily changed. HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception java.lang.NullPointerException org.apache.geronimo.stats.JSR77Servlet.doGet(JSR77Servlet.java:78) javax.servlet.http.HttpServlet.service(HttpServlet.java:595) javax.servlet.http.HttpServlet.service(HttpServlet.java:688) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.12 logs. -- 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
Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's my understading that we're going for JEE 5. I think that our re-arch of security should go into that as well. How do we want to stage this effort in terms of SVN organization? When should we cut a 2.0 development branch? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvWPm1xC6qnMLUpYRAmQWAJ0eCHtNjhMH/IO4+LtNR3sUaLTmNgCfZ0YU aTEL53hKe+hA9qF54wt3yWI= =UMhP -END PGP SIGNATURE-
Re: Geronimo 2.0
+1...I really like this idea. Alan D. Cabrera wrote: > It's my understading that we're going for JEE 5. I think that our > re-arch of security should go into that as well. > > How do we want to stage this effort in terms of SVN organization? When > should we cut a 2.0 development branch? > > > Regards, > Alan >
Can we get the Geronimo IRC archive working again?
Does anybody know who initially setup the IRC archive and/or how to get it back again? It looks like somebody with id "bevinbot" set it up ... similar enough to make me wonder if it was Blevins but different enough so that I can't be sure. I'd be glad to help get this working again if I can get some pointers. It's been down for nearly 2 months now and I really miss it. Joe -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Commit of r366236
Jan, Per the commit of r366236... -1 on including Axiom. That is just for the web app. We should not be including that in the container. Also, you can use the standard ActiveMQ..there is no need to use the WADI version. The WADI version was due to M2 POMs being incorrect and it broke the WADI builds. They are identical to 3.2.1. Jeff Index: project.xml === --- project.xml (revision 366235) +++ project.xml (working copy) @@ -190,6 +190,9 @@ concurrent concurrent ${concurrent_version} + + true + @@ -197,6 +200,9 @@ regexp ${regexp_version} http://jakarta.apache.org/regexp + + true + @@ -241,6 +247,22 @@ +commons-collections +commons-collections +${commons_collections_version} + + true + + + +commons-primitives +commons-primitives +${commons_primitives_version} + + true + + + springframework spring ${wadi_spring_version} @@ -250,6 +272,14 @@ +backport-util-concurrent +backport-util-concurrent +${backport_util_concurrent_version} + + true + + + activecluster activecluster ${wadi_activecluster_version} @@ -258,6 +288,23 @@ +activemq +activemq +${wadi_activemq_version} + + true + + + +axion +axion +${wadi_axion_version} + + true + + + + wadi wadi-core ${wadi_version}
Re: Can we get the Geronimo IRC archive working again?
Joe Bohn schrieb: > I'd be glad to help get this working again if > I can get some pointers. It's been down for nearly 2 months now and I > really miss it. > > Joe > Maybe it would be even possible to register the Geronimo project at ... * The CIA Open Source Notification System -> http://cia.navi.cx/ * A lisppaste bot instance -> http://common-lisp.net/project/lisppaste/ * At -> http://meme.b9.com/ -- Mit freundlichen Gruessen / With kind regards DAn.I.El S. Haischt Spammers, please please send any mail to: Daniel S. Haischt <[EMAIL PROTECTED]> Want a complete signature??? Type at a shell prompt: $ > finger -l [EMAIL PROTECTED]
Re: Building 1.0 release candidate from source - URL for svn checkout
For the moment these are identical so it really doesn't matter. Once 1.0 is official then you would use the tag to get back to level that is released as 1.0. I imagine that the branch will be used for maintenance on 1.0 with tags created for specific fixpacks. Joe Vamsavardhana Reddy wrote: Hi, Which URL should be used with svn to checkout the source for building 1.0 release candidate? Is it https://svn.apache.org/repos/asf/geronimo/branches/1.0/ or https://svn.apache.org/repos/asf/geronimo/tags/1.0.0/ or something else? Thanks, Vamsi -- Joe Bohn [EMAIL PROTECTED] "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Building 1.0 release candidate from source - URL for svn checkout
Vamsavardhana, It should be built from the 1.0.0 tag (the 2nd url you had below), as the 1.0 branch will soon contain changes for 1.0.1. John Vamsavardhana Reddy wrote: Hi, Which URL should be used with svn to checkout the source for building 1.0 release candidate? Is it https://svn.apache.org/repos/asf/geronimo/branches/1.0/ or https://svn.apache.org/repos/asf/geronimo/tags/1.0.0/ or something else? Thanks, Vamsi
1.0 Build failure on WinXP
I've been trying to build 1.0 for a while now on winXP and I always get a failure preparing the CRLF endings (actually I get this failure about 90% of the time and it works the other 10%). assemble:package-assembly: [echo] Preparing CRLF line endings in text based files for zip distribution BUILD FAILED File.. C:\geronimo1.0\maven.xml Element... maven:reactor Line.. 63 Column -1 Unable to obtain goal [multiproject:install-callback] -- C:\Documents and Settings\Administrator\.maven\cache\geronimo-assembly-plugin-1.0.2\plugin.jelly:285:-1 : java.io.FileNotFoundException: C:\geronimo1.0\assemblies\j2ee-jetty-server\target\geronimo-1.0\config-store\21\war\index.html (Access is denied) Total time : 26 minutes 17 seconds Finished at : Thursday, January 5, 2006 12:39:55 PM EST I've been ignoring this because I typically run right off of the assemblies that are created ... but it bothers me that I can't get a clean 1.0 build on Windows as we are about to release. The configuration in "21" appears to be the demo application and it doesn't include an index.html (hence the failure). I'm not altogether sure why the CRLF code thinks there should be an index.html to convert. One other curious thing I noticed is that there are 32 configurations in config-store for the jetty image but only 31 for tomcat. Anybody know offhand what the difference is and why? Thanks, Joe -- Joe Bohn [EMAIL PROTECTED] "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Geronimo Installation Document Section
Hi Jason, how is the installation doc coming, do you need any help on the confluence side? I saw what you started to work on the "Getting the source code" section, I would suggest to keep this task simple. We do not want to _scare_ the users with way too complicated commands and parameters, all at once. There are basically four steps to get the source and build Geronimo, so I would focus on those first. 1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/1.0.0/ 2.- cd 3.- maven m:fresh-checkout 4.- maven new Then, the next time you want to build you just do an update 1.- cd 2.- maven m:update 3.- maven m:fresh-checkout 4.- maven new (BTW, all the steps should be validated and make sure they are up-to-date) Once you explained the basics then you can go more in detail with all the other options for retrieving the source code and building Geronimo. It would also be nice to include common building errors, how to identify them, probable causes and solutions. Again, this is just a suggestion. What you think about this approach? As for update preference, I think is best to update as you go so everybody can test your instructions and provide early comments that will make corrections (if any) easier. Cheers! Hernan Jason Lenhart wrote: Hi, I am starting on the Installation section of the docs - I have been running around like a maniac doing stuff (mostly holiday things) - so I am a bit slow to produce. But I am setting aside some time each day to contribute more and more to the docs. If you start to see me go off base - please feel free to call me out :-D Also - is the preference to complete a section and then update? I started and updated but it is not complete. Thanks, Jason __ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: Geronimo Installation Document Section
- sachin On Jan 5, 2006, at 4:16 PM, Hernan Cunico wrote: Hi Jason, how is the installation doc coming, do you need any help on the confluence side? I saw what you started to work on the "Getting the source code" section, I would suggest to keep this task simple. We do not want to _scare_ the users with way too complicated commands and parameters, all at once. There are basically four steps to get the source and build Geronimo, so I would focus on those first. 1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/ 1.0.0/ 2.- cd 3.- maven m:fresh-checkout 4.- maven new Then, the next time you want to build you just do an update 1.- cd 2.- maven m:update 3.- maven m:fresh-checkout Take out #3 4.- maven new add -o (BTW, all the steps should be validated and make sure they are up- to-date) Once you explained the basics then you can go more in detail with all the other options for retrieving the source code and building Geronimo. It would also be nice to include common building errors, how to identify them, probable causes and solutions. Again, this is just a suggestion. What you think about this approach? As for update preference, I think is best to update as you go so everybody can test your instructions and provide early comments that will make corrections (if any) easier. Cheers! Hernan Jason Lenhart wrote: Hi, I am starting on the Installation section of the docs - I have been running around like a maniac doing stuff (mostly holiday things) - so I am a bit slow to produce. But I am setting aside some time each day to contribute more and more to the docs. If you start to see me go off base - please feel free to call me out :-D Also - is the preference to complete a section and then update? I started and updated but it is not complete. Thanks, Jason __ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
[jira] Created: (GERONIMO-1421) DB portlet failure in Tomcat only
DB portlet failure in Tomcat only - Key: GERONIMO-1421 URL: http://issues.apache.org/jira/browse/GERONIMO-1421 Project: Geronimo Type: Bug Components: console, Tomcat Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1 - create a new database pool using the DB portlet - select the "Derby Embedded" type - pick the derby or derby-client JAR - give it a new or existing database name - add ;create=true to the end of the generated URL - click test This procedure works in the Jetty build but does not work in the Tomcat build. In Tomcat, it just redirects to the main screen for that portlet without any error message. The database is actually created (visible in the DB Manager portlet). This does not happen if you remove ;create=true from the URL and use an existing database. -- 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: Geronimo Installation Document Section
On my machine, if I don't do a fresh-checkout the build fails. In fact it always fails the first attempt and the second round works as long as I do the fresh-checkout. Any idea why this is happening? Cheers! Hernan Sachin Patel wrote: - sachin On Jan 5, 2006, at 4:16 PM, Hernan Cunico wrote: Hi Jason, how is the installation doc coming, do you need any help on the confluence side? I saw what you started to work on the "Getting the source code" section, I would suggest to keep this task simple. We do not want to _scare_ the users with way too complicated commands and parameters, all at once. There are basically four steps to get the source and build Geronimo, so I would focus on those first. 1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/ 1.0.0/ 2.- cd 3.- maven m:fresh-checkout 4.- maven new Then, the next time you want to build you just do an update 1.- cd 2.- maven m:update 3.- maven m:fresh-checkout Take out #3 4.- maven new add -o (BTW, all the steps should be validated and make sure they are up- to-date) Once you explained the basics then you can go more in detail with all the other options for retrieving the source code and building Geronimo. It would also be nice to include common building errors, how to identify them, probable causes and solutions. Again, this is just a suggestion. What you think about this approach? As for update preference, I think is best to update as you go so everybody can test your instructions and provide early comments that will make corrections (if any) easier. Cheers! Hernan Jason Lenhart wrote: Hi, I am starting on the Installation section of the docs - I have been running around like a maniac doing stuff (mostly holiday things) - so I am a bit slow to produce. But I am setting aside some time each day to contribute more and more to the docs. If you start to see me go off base - please feel free to call me out :-D Also - is the preference to complete a section and then update? I started and updated but it is not complete. Thanks, Jason __ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: Geronimo 2.0
2006/1/5, Alan D. Cabrera <[EMAIL PROTECTED]>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > It's my understading that we're going for JEE 5. I think that our > re-arch of security should go into that as well. > > How do we want to stage this effort in terms of SVN organization? When > should we cut a 2.0 development branch? Hi Alan, I think there's no point holding it any longer. Since the 1.0 release is on its own branch, we can safely change all of the build artefacts to 2.0-SNAPSHOT. > Alan Jacek
Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]
After chatting on IM, it does appear that it is too late to change the jetty version, so I retract my -1 and make it a -0. The 1.0 release can go out with the windows security problem - I don't think many will be rushing it into production. The Jetty 5.1.10 release is available and the can be used to replace the jar if security is paramount. Some text for the release notes: There is a security issue with the Jetty 5.1.9 used by geronimo 1.0, which allows a crafted URL to access the contents of a WEB-INF directory if the server is running on a windows platform. This issue is fixed in Jetty 5.1.10 and the 5.1.9 jar in geronimo 1.0 can be replaced with the jar from 5.1.10. It is not recommended that Geronimo-jetty 1.0 be used on to serve a non-open web application from a windows platform. cheers Matt Hogstrom wrote: > Greg, > > I was wrapping up the release last night and was releasing it today > based on the prior feedback. Can you provide some more details on the > exposure? My preference would be to release G 1.0 as is and fix this in > 1.0.1. I need your expert opinion of the exposure WRT to security. > > There will always be something left to fix this will delay releasing > about 1 week to allow for a new review of the code, re-certification, etc. > > I see a few options at this point. > > 1. Continue with the release despite this information. > > 2. Hold the release until this can be fixed (which then also begs the > question of moving to the more recent Tomcat version with their fix for > 0 content length on POST requests). This will delay the release for at > least one week. > > 3. Ship Geronimo with Tomcat and get 1.0 out the door. We ship with > both Tomcat and Jetty for 1.0.1 with this security fix inclued. > > The security hole you've outlined sounds serious but I was wondering if > its a specific set of implementations that could be documented (ie. is > this something that someone just found and its a rather obscure config?) > > Other input welcome. I'm going to complete getting the release ready > but defer punching the button until this afternoon (about 1500 PT). > > Matt > > Greg Wilkins wrote: > >> Sorry guys but >> >> -1 >> >> I've just had a report of a security issue in Jetty that reveals the >> contents of WEB-INF on win32 platforms.Happy f*ing new year! >> >> I have a fix and will be making a release very shortly. To avoid any >> other issues, I will probably roll back the other changes in HEAD so >> only this fix will go in. >> >> But if it really is too late to change the jetty version, then -0 >> >> regards >> >> >> >
Re: Can we get the Geronimo IRC archive working again?
If there are no objections I can register the Geronimo project with ... * http://meme.b9.com/ - That's a channel logger with a search interface. * lisppaste - that's a pastbot with a corresponding web interface. * CIA - That's an open source tracking system. which tracks the project's progress. Tho - requires to install a little shell script on the SVN server that will be executed on each commit. Daniel S. Haischt schrieb: > Joe Bohn schrieb: > >>I'd be glad to help get this working again if >>I can get some pointers. It's been down for nearly 2 months now and I >>really miss it. >> >>Joe >> > > > Maybe it would be even possible to register the Geronimo project at ... > > * The CIA Open Source Notification System >-> http://cia.navi.cx/ > > * A lisppaste bot instance >-> http://common-lisp.net/project/lisppaste/ > > * At -> http://meme.b9.com/ > -- Mit freundlichen Gruessen / With kind regards DAn.I.El S. Haischt Spammers, please please send any mail to: Daniel S. Haischt <[EMAIL PROTECTED]> Want a complete signature??? Type at a shell prompt: $ > finger -l [EMAIL PROTECTED]
Re: Geronimo 2.0
On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > It's my understading that we're going for JEE 5. I think that our > re-arch of security should go into that as well. Agreed. > How do we want to stage this effort in terms of SVN organization? When > should we cut a 2.0 development branch? I suppose that the JEE 5 work would be best suited to a 2.0 branch. That means that there is a potential to have to do a lot of double work. What I mean to say is that any new innovations being committed to the HEAD will need to be refactored and committed to the 2.0 branch. And this work will increase more with the addition of more branches (e.g., 1.1, 1.2, etc.). Bruce -- perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Re: Geronimo Installation Document Section
You need to do the fresh-checkout the first time you get the source so that you get the OpenEJB code (from CVS). AFAIK, you shouldn't need to do a fresh-checkout again because an m:update will update both svn and OpenEJB CVS files. Not sure why you would need to do a fresh-checkout a second time for the second round to work. John Hernan Cunico wrote: On my machine, if I don't do a fresh-checkout the build fails. In fact it always fails the first attempt and the second round works as long as I do the fresh-checkout. Any idea why this is happening? Cheers! Hernan Sachin Patel wrote: - sachin On Jan 5, 2006, at 4:16 PM, Hernan Cunico wrote: Hi Jason, how is the installation doc coming, do you need any help on the confluence side? I saw what you started to work on the "Getting the source code" section, I would suggest to keep this task simple. We do not want to _scare_ the users with way too complicated commands and parameters, all at once. There are basically four steps to get the source and build Geronimo, so I would focus on those first. 1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/ 1.0.0/ 2.- cd 3.- maven m:fresh-checkout 4.- maven new Then, the next time you want to build you just do an update 1.- cd 2.- maven m:update 3.- maven m:fresh-checkout Take out #3 4.- maven new add -o (BTW, all the steps should be validated and make sure they are up- to-date) Once you explained the basics then you can go more in detail with all the other options for retrieving the source code and building Geronimo. It would also be nice to include common building errors, how to identify them, probable causes and solutions. Again, this is just a suggestion. What you think about this approach? As for update preference, I think is best to update as you go so everybody can test your instructions and provide early comments that will make corrections (if any) easier. Cheers! Hernan Jason Lenhart wrote: Hi, I am starting on the Installation section of the docs - I have been running around like a maniac doing stuff (mostly holiday things) - so I am a bit slow to produce. But I am setting aside some time each day to contribute more and more to the docs. If you start to see me go off base - please feel free to call me out :-D Also - is the preference to complete a section and then update? I started and updated but it is not complete. Thanks, Jason __ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Snyder wrote, On 1/5/2006 3:43 PM: > On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > >>It's my understading that we're going for JEE 5. I think that our >>re-arch of security should go into that as well. > > > Agreed. > > >>How do we want to stage this effort in terms of SVN organization? When >>should we cut a 2.0 development branch? > > > I suppose that the JEE 5 work would be best suited to a 2.0 branch. > That means that there is a potential to have to do a lot of double > work. What I mean to say is that any new innovations being committed > to the HEAD will need to be refactored and committed to the 2.0 > branch. And this work will increase more with the addition of more > branches (e.g., 1.1, 1.2, etc.). You touched on the concern that I had. I'm thinking that once we cut this, there will be no further work on 1.x, because everyone will want to work on 2.x. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvba11xC6qnMLUpYRAuAEAJ9c0uQDLeGgIzcqqR/iKv2l99QC5wCdGhVB foYWLFogfXXWxoMY/OEXtI8= =zGE8 -END PGP SIGNATURE-
Re: Geronimo 2.0
On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >>How do we want to stage this effort in terms of SVN organization? When > >>should we cut a 2.0 development branch? > > > > > > I suppose that the JEE 5 work would be best suited to a 2.0 branch. > > That means that there is a potential to have to do a lot of double > > work. What I mean to say is that any new innovations being committed > > to the HEAD will need to be refactored and committed to the 2.0 > > branch. And this work will increase more with the addition of more > > branches (e.g., 1.1, 1.2, etc.). > > You touched on the concern that I had. I'm thinking that once we cut > this, there will be no further work on 1.x, because everyone will want > to work on 2.x. Then we should probably consider making a decision that the HEAD should contain 2.x work only. If any fixes need to be done to the 1.x code then proper branching and tagging should occur to facilitate that work. Bruce -- perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Snyder wrote, On 1/5/2006 4:26 PM: > On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > How do we want to stage this effort in terms of SVN organization? When should we cut a 2.0 development branch? >>> >>> >>>I suppose that the JEE 5 work would be best suited to a 2.0 branch. >>>That means that there is a potential to have to do a lot of double >>>work. What I mean to say is that any new innovations being committed >>>to the HEAD will need to be refactored and committed to the 2.0 >>>branch. And this work will increase more with the addition of more >>>branches (e.g., 1.1, 1.2, etc.). >> >>You touched on the concern that I had. I'm thinking that once we cut >>this, there will be no further work on 1.x, because everyone will want >>to work on 2.x. > > > Then we should probably consider making a decision that the HEAD > should contain 2.x work only. If any fixes need to be done to the 1.x > code then proper branching and tagging should occur to facilitate that > work. Good point. What do others think? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvbmY1xC6qnMLUpYRAsEZAJ4hKUKXBCTxkTQfPMXGOr3w1LswAQCbBtpt 0ThTQUdCzTdCaaapV71OgZ8= =L4zh -END PGP SIGNATURE-
[jira] Created: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds Key: GERONIMO-1422 URL: http://issues.apache.org/jira/browse/GERONIMO-1422 Project: Geronimo Type: Bug Components: ActiveMQ Versions: 1.0 Environment: Solaris 10 x86 under VMWare player 1.01 Java 1.4.2_10 tomcat build of geronimo Reporter: John Sisson Fix For: 1.1 Attachments: geronimo_shutdown_stdout.txt Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. I will attach a capture of stdout also including a thread dump to this issue. -- 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-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
[ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ] John Sisson updated GERONIMO-1422: -- Attachment: geronimo_shutdown_stdout.txt > Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect > endpoints to broker every 30 seconds > > > Key: GERONIMO-1422 > URL: http://issues.apache.org/jira/browse/GERONIMO-1422 > Project: Geronimo > Type: Bug > Components: ActiveMQ > Versions: 1.0 > Environment: Solaris 10 x86 under VMWare player 1.01 > Java 1.4.2_10 > tomcat build of geronimo > Reporter: John Sisson > Fix For: 1.1 > Attachments: geronimo_shutdown_stdout.txt > > Can anyone reproduce this problem on other platforms? > If I start the tomcat build of the release candidate and then shut it down > once the startup has completed it shuts down almost cleanly: > Server shutdown begun > 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on > http-0.0.0.0-8443 > 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on > http-0.0.0.0-8080 > 11:25:49,001 INFO [StandardContext] Container > org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not > been started > Server shutdown completed > I have shutdown issues If I do the following: > * start the tomcat build of release candidate using geronimo.sh run --long > * connect to the daytrader web app > * populate the daytrader database via the daytrader configuration page > * log into daytrader and view account, portfolio etc. > * press ctrl-C in the window that geronimo was started in to shut it down. > * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. > I will attach a capture of stdout also including a thread dump to this issue. -- 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-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
[ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ] John Sisson updated GERONIMO-1422: -- Fix Version: 1.1 Version: 1.0 > Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect > endpoints to broker every 30 seconds > > > Key: GERONIMO-1422 > URL: http://issues.apache.org/jira/browse/GERONIMO-1422 > Project: Geronimo > Type: Bug > Components: ActiveMQ > Versions: 1.0 > Environment: Solaris 10 x86 under VMWare player 1.01 > Java 1.4.2_10 > tomcat build of geronimo > Reporter: John Sisson > Fix For: 1.1 > Attachments: geronimo_shutdown_stdout.txt > > Can anyone reproduce this problem on other platforms? > If I start the tomcat build of the release candidate and then shut it down > once the startup has completed it shuts down almost cleanly: > Server shutdown begun > 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on > http-0.0.0.0-8443 > 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on > http-0.0.0.0-8080 > 11:25:49,001 INFO [StandardContext] Container > org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not > been started > Server shutdown completed > I have shutdown issues If I do the following: > * start the tomcat build of release candidate using geronimo.sh run --long > * connect to the daytrader web app > * populate the daytrader database via the daytrader configuration page > * log into daytrader and view account, portfolio etc. > * press ctrl-C in the window that geronimo was started in to shut it down. > * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. > I will attach a capture of stdout also including a thread dump to this issue. -- 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
Shutdown problems encountered on 1.0 RC
I have encountered some Geronimo shutdown issues with ActiveMQ on the 1.0 release candidate on Solaris 10 x86 under VMWare. Can anyone else reproduce this issue (see GERONIMO-1422 for details) on other OSes?
RELEASE-NOTES-1.0.txt
Is the slash after the word deploy in the file RELEASE-NOTES-1.0.txt intended? * Hot Deploy by copying your deployment artifact to the deploy/ directory -- perl -e 'print unpack(u,"62V5N\"FME;G\!E
[jira] Updated: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
[ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ] anita kulshreshtha updated GERONIMO-1422: - Attachment: shutdown.txt I am seeing the same on win XP when - * start using java -jar * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader with uid:0 . > * press ctrl-C in the window that geronimo was started in to shut it down. > Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect > endpoints to broker every 30 seconds > > > Key: GERONIMO-1422 > URL: http://issues.apache.org/jira/browse/GERONIMO-1422 > Project: Geronimo > Type: Bug > Components: ActiveMQ > Versions: 1.0 > Environment: Solaris 10 x86 under VMWare player 1.01 > Java 1.4.2_10 > tomcat build of geronimo > Reporter: John Sisson > Fix For: 1.1 > Attachments: geronimo_shutdown_stdout.txt, shutdown.txt > > Can anyone reproduce this problem on other platforms? > If I start the tomcat build of the release candidate and then shut it down > once the startup has completed it shuts down almost cleanly: > Server shutdown begun > 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on > http-0.0.0.0-8443 > 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on > http-0.0.0.0-8080 > 11:25:49,001 INFO [StandardContext] Container > org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not > been started > Server shutdown completed > I have shutdown issues If I do the following: > * start the tomcat build of release candidate using geronimo.sh run --long > * connect to the daytrader web app > * populate the daytrader database via the daytrader configuration page > * log into daytrader and view account, portfolio etc. > * press ctrl-C in the window that geronimo was started in to shut it down. > * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. > I will attach a capture of stdout also including a thread dump to this issue. -- 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: svn commit: r366389 - in /geronimo/site: docs/downloads.html xdocs/downloads.xml
We should mention in the download information that the installer isn't available in this release and will be available in the upcoming 1.0.1 release. Thanks, John
Re: Geronimo 2.0
Bruce Snyder wrote: On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: How do we want to stage this effort in terms of SVN organization? When should we cut a 2.0 development branch? I suppose that the JEE 5 work would be best suited to a 2.0 branch. That means that there is a potential to have to do a lot of double work. What I mean to say is that any new innovations being committed to the HEAD will need to be refactored and committed to the 2.0 branch. And this work will increase more with the addition of more branches (e.g., 1.1, 1.2, etc.). You touched on the concern that I had. I'm thinking that once we cut this, there will be no further work on 1.x, because everyone will want to work on 2.x. Then we should probably consider making a decision that the HEAD should contain 2.x work only. If any fixes need to be done to the 1.x code then proper branching and tagging should occur to facilitate that work. I agree we don't want too many branches. Will fixes for the 1.0.1 release (hopefully we can get out in a few weeks) be committed to the 1.0 branch and then we create another tag for the 1.0.1 release? My thoughts.. Do we have any guesstimates on when we would have JEE 5 development completed? How long it will be before we can deliver a release with some innovations in it, since we previously agreed we want to release frequently? If this is going to be a while then we should discuss the work that is planned for the near future and whether there are enhancements that can be delivered in a releases before JEE 5, and if so, how that could be managed. Could some of the planned enhancements impact the stability of head development and therefore should be done in a branch? E.G. would we have stability problems doing JEE 5 development, re-arch of security, maven 1 to maven 2 migration, xbean support, corba impl etc. all in head? John Bruce -- perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
ANNOUNCE Geronimo Version 1.0 Available for Download
The Apache Geronimo team is proud to announce the availability of Geronimo Version 1.0 for immediate download. Please visit http://geronimo.apache.org/downloads.html. The release has passed all J2EE 1.4 Certification Tests. In addition, many thanks to our community and volunteers that have tested Geronimo on many operating systems including Linux, Windows, MacOS and zLinux as well as many hardware platforms. Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for Java Business Integration (JBI), Jetty or Tomcat Web container deployment options, a complete Web-enabled management console based on Java Portlets, full integration with the Eclipse Web Tools Project, and integration of Apache Derby and the Apache Directory Server. Included in this e-mail are relevant sections from the RELEASE-NOTES which can be found in the distributions that are available for download. For up to the minute Release Notes and information you can check the Geronimo home page at http://geronimo.apache.org. === Release Notes -- Apache Geronimo -- Version 1.0 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://wiki.apache.org/geronimo System Requirements --- You need a platform that supports the Sun JDK 1.4.2. CORBA support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08 or a higher 1.4.2_* release). Most testing has been done on Linux, Mac OS X, and Windows. Installing & Starting Geronimo -- To install, simply unpack the .zip (Windows) or tar.gz (Unix) file containing Geronimo. Documentation is included in the docs directory in your unpacked server. If you wish to modify the default ports that Geronimo will use, edit the file var/config/config.xml in your Geronimo directory. 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 1.4.2 JDK/JRE prior to executing the command. Here is an example: export JAVA_HOME=/directory_to_the_JRE/ bin/geronimo.sh 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 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 admin console and deployment is system/manager. To change this edit the var/security/users.properties and var/security/groups.properties files. Future Road Map at a Glance --- http://issues.apache.org/jira/browse/GERONIMO? report=com.atlassian.jira.plugin.system.project:roadmap-panel (the above URL must be all on one line) Late Release News (not in RELEASE-NOTES-1.0.txt in build) - Just as the Geronimo Release was being prepared a report was made about a potential security issue when using the Jetty Web Conatiner. The issue was noted on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to access the contents of a WEB-INF directory if the server is running on a Windows platform. This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo 1.0.1 which will be available in the near future. Significant Changes Since the M5 Release * the ConfigID format has been updated in anticipatation of future enhancements. Application plans that include configIds of configurations included in Geronimo M5 and earlier will require modifications. See the Wiki at http://wiki.apache.org/geronimo for more information. * More functionality and new look and feel for the Administrative Console (http://localhost:8080/console/) * Added HTTP session clustering to the Tomcat configuration included with Geronimo * Hot Deploy by copying your deployment artifact to the deploy/ directory * Ability to run the deploy tool from a machine other than the application server (remote deployment) * Packages that represented experimental, pre-release or obsolete versions were removed. * Clustering - Tomcat support for clustering is available in this release. - WADI has been included as a technology preview for both Jetty and Tomcat. See http://wadi.codehaus.org for additional infor
Re: ANNOUNCE Geronimo Version 1.0 Available for Download
Congrats -- dims On 1/5/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > The Apache Geronimo team is proud to announce the availability of Geronimo > Version 1.0 for immediate download. Please visit > http://geronimo.apache.org/downloads.html. > > The release has passed all J2EE 1.4 Certification Tests. In addition, many > thanks to our community and volunteers that have tested Geronimo on many > operating systems including Linux, Windows, MacOS and zLinux as well as many > hardware platforms. > > Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for > Java > Business Integration (JBI), Jetty or Tomcat Web container deployment options, > a > complete Web-enabled management console based on Java Portlets, full > integration > with the Eclipse Web Tools Project, and integration of Apache Derby and the > Apache Directory Server. > > Included in this e-mail are relevant sections from the RELEASE-NOTES which can > be found in the distributions that are available for download. For up to the > minute Release Notes and information you can check the Geronimo home page at > http://geronimo.apache.org. > > === > > Release Notes -- Apache Geronimo -- Version 1.0 > > 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://wiki.apache.org/geronimo > > > System Requirements > --- > You need a platform that supports the Sun JDK 1.4.2. CORBA > support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08 > or a higher 1.4.2_* release). > > Most testing has been done on Linux, Mac OS X, and Windows. > > > Installing & Starting Geronimo > -- > To install, simply unpack the .zip (Windows) or tar.gz (Unix) file > containing Geronimo. > > Documentation is included in the docs directory in your unpacked server. > > If you wish to modify the default ports that > Geronimo will use, edit the file var/config/config.xml in your > Geronimo directory. > > 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 1.4.2 JDK/JRE > prior to executing the command. Here is an example: > > export JAVA_HOME=/directory_to_the_JRE/ > bin/geronimo.sh > > 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 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 admin console and > deployment is system/manager. To change this edit the > var/security/users.properties and var/security/groups.properties > files. > > Future Road Map at a Glance > --- > http://issues.apache.org/jira/browse/GERONIMO? >report=com.atlassian.jira.plugin.system.project:roadmap-panel > >(the above URL must be all on one line) > > > Late Release News (not in RELEASE-NOTES-1.0.txt in build) > - > Just as the Geronimo Release was being prepared a report was made about a > potential security issue when using the Jetty Web Conatiner. The issue was > noted > on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to > access the > contents of a WEB-INF directory if the server is running on a Windows > platform. > This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo 1.0.1 > which > will > be available in the near future. > > > Significant Changes Since the M5 Release > > * the ConfigID format has been updated in anticipatation of future > enhancements. Application plans that include configIds of > configurations included in Geronimo M5 and earlier will require > modifications. See the Wiki at http://wiki.apache.org/geronimo > for more information. > * More functionality and new look and feel for the Administrative > Console (http://localhost:8080/console/) > * Added HTTP session clustering to the Tomcat configuration > included with Geronimo > * Hot Deploy by copying your deployment artifact to the deploy/ > directory > * Ability to run the deploy tool from a machine other than the > application server (remote deployment) > * Pac
Re: ANNOUNCE Geronimo Version 1.0 Available for Download
Matt Hogstrom wrote: > The Apache Geronimo team is proud to announce the availability of > Geronimo Version 1.0 for immediate download. Please visit > http://geronimo.apache.org/downloads.html. CONGRATULATIONS Cheers, Erin
Re: ANNOUNCE Geronimo Version 1.0 Available for Download
Great work to the team...especially Matt for taking a beating getting us here. This was a long hard roadand important milestone. Special thanks to *everyone* in the community for helping to test this and find the hidden nasties. Jeff Matt Hogstrom wrote: > The Apache Geronimo team is proud to announce the availability of > Geronimo Version 1.0 for immediate download. Please visit > http://geronimo.apache.org/downloads.html. > > The release has passed all J2EE 1.4 Certification Tests. In addition, > many thanks to our community and volunteers that have tested Geronimo on > many operating systems including Linux, Windows, MacOS and zLinux as > well as many hardware platforms. > > Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support > for Java Business Integration (JBI), Jetty or Tomcat Web container > deployment options, a complete Web-enabled management console based on > Java Portlets, full integration with the Eclipse Web Tools Project, and > integration of Apache Derby and the Apache Directory Server. > > Included in this e-mail are relevant sections from the RELEASE-NOTES > which can be found in the distributions that are available for > download. For up to the minute Release Notes and information you can > check the Geronimo home page at http://geronimo.apache.org. > > === > > Release Notes -- Apache Geronimo -- Version 1.0 > > 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://wiki.apache.org/geronimo > > > System Requirements > --- > You need a platform that supports the Sun JDK 1.4.2. CORBA > support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08 > or a higher 1.4.2_* release). > > Most testing has been done on Linux, Mac OS X, and Windows. > > > Installing & Starting Geronimo > -- > To install, simply unpack the .zip (Windows) or tar.gz (Unix) file > containing Geronimo. > > Documentation is included in the docs directory in your unpacked server. > > If you wish to modify the default ports that > Geronimo will use, edit the file var/config/config.xml in your > Geronimo directory. > > 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 1.4.2 JDK/JRE > prior to executing the command. Here is an example: > > export JAVA_HOME=/directory_to_the_JRE/ > bin/geronimo.sh > > 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 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 admin console and > deployment is system/manager. To change this edit the > var/security/users.properties and var/security/groups.properties > files. > > Future Road Map at a Glance > --- > http://issues.apache.org/jira/browse/GERONIMO? > report=com.atlassian.jira.plugin.system.project:roadmap-panel > > (the above URL must be all on one line) > > > Late Release News (not in RELEASE-NOTES-1.0.txt in build) > - > Just as the Geronimo Release was being prepared a report was made about a > potential security issue when using the Jetty Web Conatiner. The issue > was noted > on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to > access the > contents of a WEB-INF directory if the server is running on a Windows > platform. > This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo > 1.0.1 which will > be available in the near future. > > > Significant Changes Since the M5 Release > > * the ConfigID format has been updated in anticipatation of future >enhancements. Application plans that include configIds of >configurations included in Geronimo M5 and earlier will require >modifications. See the Wiki at http://wiki.apache.org/geronimo >for more information. > * More functionality and new look and feel for the Administrative >Console (http://localhost:8080/console/) > * Added HTTP session clustering to the Tomcat configuration >included with Geronimo > * Hot Deploy by
Re: ANNOUNCE Geronimo Version 1.0 Available for Download
Awesome work guys. This is a great accomplishment! - Dan Matt Hogstrom wrote: The Apache Geronimo team is proud to announce the availability of Geronimo Version 1.0 for immediate download. Please visit http://geronimo.apache.org/downloads.html. The release has passed all J2EE 1.4 Certification Tests. In addition, many thanks to our community and volunteers that have tested Geronimo on many operating systems including Linux, Windows, MacOS and zLinux as well as many hardware platforms. Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for Java Business Integration (JBI), Jetty or Tomcat Web container deployment options, a complete Web-enabled management console based on Java Portlets, full integration with the Eclipse Web Tools Project, and integration of Apache Derby and the Apache Directory Server. Included in this e-mail are relevant sections from the RELEASE-NOTES which can be found in the distributions that are available for download. For up to the minute Release Notes and information you can check the Geronimo home page at http://geronimo.apache.org. === Release Notes -- Apache Geronimo -- Version 1.0 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://wiki.apache.org/geronimo System Requirements --- You need a platform that supports the Sun JDK 1.4.2. CORBA support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08 or a higher 1.4.2_* release). Most testing has been done on Linux, Mac OS X, and Windows. Installing & Starting Geronimo -- To install, simply unpack the .zip (Windows) or tar.gz (Unix) file containing Geronimo. Documentation is included in the docs directory in your unpacked server. If you wish to modify the default ports that Geronimo will use, edit the file var/config/config.xml in your Geronimo directory. 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 1.4.2 JDK/JRE prior to executing the command. Here is an example: export JAVA_HOME=/directory_to_the_JRE/ bin/geronimo.sh 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 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 admin console and deployment is system/manager. To change this edit the var/security/users.properties and var/security/groups.properties files. Future Road Map at a Glance --- http://issues.apache.org/jira/browse/GERONIMO? report=com.atlassian.jira.plugin.system.project:roadmap-panel (the above URL must be all on one line) Late Release News (not in RELEASE-NOTES-1.0.txt in build) - Just as the Geronimo Release was being prepared a report was made about a potential security issue when using the Jetty Web Conatiner. The issue was noted on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to access the contents of a WEB-INF directory if the server is running on a Windows platform. This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo 1.0.1 which will be available in the near future. Significant Changes Since the M5 Release * the ConfigID format has been updated in anticipatation of future enhancements. Application plans that include configIds of configurations included in Geronimo M5 and earlier will require modifications. See the Wiki at http://wiki.apache.org/geronimo for more information. * More functionality and new look and feel for the Administrative Console (http://localhost:8080/console/) * Added HTTP session clustering to the Tomcat configuration included with Geronimo * Hot Deploy by copying your deployment artifact to the deploy/ directory * Ability to run the deploy tool from a machine other than the application server (remote deployment) * Packages that represented experimental, pre-release or obsolete versions were removed. * Clustering - Tomcat support for clustering is available in this release. - WADI has been included as a technology preview for
RE: ANNOUNCE Geronimo Version 1.0 Available for Download
Congrats and nice work to all!! -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Thursday, January 05, 2006 6:18 PM To: dev@geronimo.apache.org; user@geronimo.apache.org; [EMAIL PROTECTED] Subject: ANNOUNCE Geronimo Version 1.0 Available for Download The Apache Geronimo team is proud to announce the availability of Geronimo Version 1.0 for immediate download. Please visit http://geronimo.apache.org/downloads.html. The release has passed all J2EE 1.4 Certification Tests. In addition, many thanks to our community and volunteers that have tested Geronimo on many operating systems including Linux, Windows, MacOS and zLinux as well as many hardware platforms. Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for Java Business Integration (JBI), Jetty or Tomcat Web container deployment options, a complete Web-enabled management console based on Java Portlets, full integration with the Eclipse Web Tools Project, and integration of Apache Derby and the Apache Directory Server. Included in this e-mail are relevant sections from the RELEASE-NOTES which can be found in the distributions that are available for download. For up to the minute Release Notes and information you can check the Geronimo home page at http://geronimo.apache.org. === Release Notes -- Apache Geronimo -- Version 1.0 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://wiki.apache.org/geronimo System Requirements --- You need a platform that supports the Sun JDK 1.4.2. CORBA support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08 or a higher 1.4.2_* release). Most testing has been done on Linux, Mac OS X, and Windows. Installing & Starting Geronimo -- To install, simply unpack the .zip (Windows) or tar.gz (Unix) file containing Geronimo. Documentation is included in the docs directory in your unpacked server. If you wish to modify the default ports that Geronimo will use, edit the file var/config/config.xml in your Geronimo directory. 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 1.4.2 JDK/JRE prior to executing the command. Here is an example: export JAVA_HOME=/directory_to_the_JRE/ bin/geronimo.sh 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 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 admin console and deployment is system/manager. To change this edit the var/security/users.properties and var/security/groups.properties files. Future Road Map at a Glance --- http://issues.apache.org/jira/browse/GERONIMO? report=com.atlassian.jira.plugin.system.project:roadmap-panel (the above URL must be all on one line) Late Release News (not in RELEASE-NOTES-1.0.txt in build) - Just as the Geronimo Release was being prepared a report was made about a potential security issue when using the Jetty Web Conatiner. The issue was noted on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to access the contents of a WEB-INF directory if the server is running on a Windows platform. This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo 1.0.1 which will be available in the near future. Significant Changes Since the M5 Release * the ConfigID format has been updated in anticipatation of future enhancements. Application plans that include configIds of configurations included in Geronimo M5 and earlier will require modifications. See the Wiki at http://wiki.apache.org/geronimo for more information. * More functionality and new look and feel for the Administrative Console (http://localhost:8080/console/) * Added HTTP session clustering to the Tomcat configuration included with Geronimo * Hot Deploy by copying your deployment artifact to the deploy/ directory * Ability to run the deploy tool from a machine other than the application server (remote deployment) * Packages that r
Re: ANNOUNCE Geronimo Version 1.0 Available for Download
really good news, but the release notes link is broken. On 1/6/06, Christopher Chan <[EMAIL PROTECTED]> wrote: > Congrats and nice work to all!! > > -Original Message- > From: Matt Hogstrom [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 05, 2006 6:18 PM > To: dev@geronimo.apache.org; user@geronimo.apache.org; [EMAIL PROTECTED] > Subject: ANNOUNCE Geronimo Version 1.0 Available for Download > > The Apache Geronimo team is proud to announce the availability of Geronimo > Version 1.0 for immediate download. Please visit > http://geronimo.apache.org/downloads.html. > > The release has passed all J2EE 1.4 Certification Tests. In addition, many > thanks to our community and volunteers that have tested Geronimo on many > operating systems including Linux, Windows, MacOS and zLinux as well as many > > hardware platforms. > > Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for > Java > Business Integration (JBI), Jetty or Tomcat Web container deployment > options, a > complete Web-enabled management console based on Java Portlets, full > integration > with the Eclipse Web Tools Project, and integration of Apache Derby and the > Apache Directory Server. > > Included in this e-mail are relevant sections from the RELEASE-NOTES which > can > be found in the distributions that are available for download. For up to > the > minute Release Notes and information you can check the Geronimo home page at > > http://geronimo.apache.org. > > === > > Release Notes -- Apache Geronimo -- Version 1.0 > > 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://wiki.apache.org/geronimo > > > System Requirements > --- > You need a platform that supports the Sun JDK 1.4.2. CORBA > support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08 > or a higher 1.4.2_* release). > > Most testing has been done on Linux, Mac OS X, and Windows. > > > Installing & Starting Geronimo > -- > To install, simply unpack the .zip (Windows) or tar.gz (Unix) file > containing Geronimo. > > Documentation is included in the docs directory in your unpacked server. > > If you wish to modify the default ports that > Geronimo will use, edit the file var/config/config.xml in your > Geronimo directory. > > 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 1.4.2 JDK/JRE > prior to executing the command. Here is an example: > > export JAVA_HOME=/directory_to_the_JRE/ > bin/geronimo.sh > > 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 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 admin console and > deployment is system/manager. To change this edit the > var/security/users.properties and var/security/groups.properties > files. > > Future Road Map at a Glance > --- > http://issues.apache.org/jira/browse/GERONIMO? >report=com.atlassian.jira.plugin.system.project:roadmap-panel > >(the above URL must be all on one line) > > > Late Release News (not in RELEASE-NOTES-1.0.txt in build) > - > Just as the Geronimo Release was being prepared a report was made about a > potential security issue when using the Jetty Web Conatiner. The issue was > noted > on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to > access the > contents of a WEB-INF directory if the server is running on a Windows > platform. > This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo 1.0.1 > which > will > be available in the near future. > > > Significant Changes Since the M5 Release > > * the ConfigID format has been updated in anticipatation of future > enhancements. Application plans that include configIds of > configurations included in Geronimo M5 and earlier will require > modifications. See the Wiki at http://wiki.apache.org/geronimo > for more information. > * More functionality and new look and feel for the Administrative > Console
Re: ANNOUNCE Geronimo Version 1.0 Available for Download
Are you sure you weren't redirected to a mirror that hasn't synced yet with the new release? In my case the suggested mirror site didn't have the file, but the other mirror sites did. Hopefully it will fix itself soon. John Ken Perl wrote: really good news, but the release notes link is broken. On 1/6/06, Christopher Chan <[EMAIL PROTECTED]> wrote: Congrats and nice work to all!! -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Thursday, January 05, 2006 6:18 PM To: dev@geronimo.apache.org; user@geronimo.apache.org; [EMAIL PROTECTED] Subject: ANNOUNCE Geronimo Version 1.0 Available for Download The Apache Geronimo team is proud to announce the availability of Geronimo Version 1.0 for immediate download. Please visit http://geronimo.apache.org/downloads.html. The release has passed all J2EE 1.4 Certification Tests. In addition, many thanks to our community and volunteers that have tested Geronimo on many operating systems including Linux, Windows, MacOS and zLinux as well as many hardware platforms. Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for Java Business Integration (JBI), Jetty or Tomcat Web container deployment options, a complete Web-enabled management console based on Java Portlets, full integration with the Eclipse Web Tools Project, and integration of Apache Derby and the Apache Directory Server. Included in this e-mail are relevant sections from the RELEASE-NOTES which can be found in the distributions that are available for download. For up to the minute Release Notes and information you can check the Geronimo home page at http://geronimo.apache.org. === Release Notes -- Apache Geronimo -- Version 1.0 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://wiki.apache.org/geronimo System Requirements --- You need a platform that supports the Sun JDK 1.4.2. CORBA support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08 or a higher 1.4.2_* release). Most testing has been done on Linux, Mac OS X, and Windows. Installing & Starting Geronimo -- To install, simply unpack the .zip (Windows) or tar.gz (Unix) file containing Geronimo. Documentation is included in the docs directory in your unpacked server. If you wish to modify the default ports that Geronimo will use, edit the file var/config/config.xml in your Geronimo directory. 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 1.4.2 JDK/JRE prior to executing the command. Here is an example: export JAVA_HOME=/directory_to_the_JRE/ bin/geronimo.sh 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 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 admin console and deployment is system/manager. To change this edit the var/security/users.properties and var/security/groups.properties files. Future Road Map at a Glance --- http://issues.apache.org/jira/browse/GERONIMO? report=com.atlassian.jira.plugin.system.project:roadmap-panel (the above URL must be all on one line) Late Release News (not in RELEASE-NOTES-1.0.txt in build) - Just as the Geronimo Release was being prepared a report was made about a potential security issue when using the Jetty Web Conatiner. The issue was noted on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to access the contents of a WEB-INF directory if the server is running on a Windows platform. This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo 1.0.1 which will be available in the near future. Significant Changes Since the M5 Release * the ConfigID format has been updated in anticipatation of future enhancements. Application plans that include configIds of configurations included in Geronimo M5 and earlier will require modifications. See the Wiki at http://wiki.apache.org/geronimo for more information. * More functionality and new look and feel for the Administrat