Corrupted Geronimo jars in Apache CVS Repository?
Hi, I created a sample test app to see how to transform a Maven1-based project into Maven2-based one and found that http://cvs.apache.org/repository contained incomplete jars of our libraries although their publish dates were correct. For example, http://cvs.apache.org/repository/geronimo/jars/geronimo-core-1.1-SNAPSHOT.jar is published on 17-Feb-2006 14:02 and its size is 19K whereas the one I use (built locally during the build) is over 30K. The missing class that made me spot it was org.apache.geronimo.proxy.ProxyContainer that I incidentally used in one of my unit tests to ensure a proper migration (what a lucky man I am! ;)) Noone could've come across it because it's very likely that the build order overrides Geronimo jars downloaded earlier and the ones necessary are built later in the process. I can't explain it, otherwise. The issue came to the surface during Maven2 build when the repository is defined as legacy. repository idapache-cvs/id nameApache CVS Repository/name urlhttp://cvs.apache.org/repository/url layoutlegacy/layout /repository What can I do to address the issue? Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Corrupted Geronimo jars in Apache CVS Repository?
On Feb 18, 2006, at 6:32 AM, Jacek Laskowski wrote: Hi, I created a sample test app to see how to transform a Maven1-based project into Maven2-based one and found that http://cvs.apache.org/repository contained incomplete jars of our libraries although their publish dates were correct. For example, http://cvs.apache.org/repository/geronimo/jars/ geronimo-core-1.1-SNAPSHOT.jar is published on 17-Feb-2006 14:02 and its size is 19K whereas the one I use (built locally during the build) is over 30K. The missing class that made me spot it was org.apache.geronimo.proxy.ProxyContainer that I incidentally used in one of my unit tests to ensure a proper migration (what a lucky man I am! ;)) Noone could've come across it because it's very likely that the build order overrides Geronimo jars downloaded earlier and the ones necessary are built later in the process. I can't explain it, otherwise. The issue came to the surface during Maven2 build when the repository is defined as legacy. repository idapache-cvs/id nameApache CVS Repository/name urlhttp://cvs.apache.org/repository/url layoutlegacy/layout /repository What can I do to address the issue? Run 'svn up'? I think you'll find the following change of interest -- http://svn.apache.org/viewcvs?rev=378162view=rev ProxyContainer is no longer... My geronimo-core is 19k. Depending on how files are written out to the maven repo, there is the possibility that a bad file could be rsynced from GBuild into the Apache repo. However, I'm confident this is not one of those cases... --kevan
Re: Corrupted Geronimo jars in Apache CVS Repository? - sorry
2006/2/18, Kevan Miller [EMAIL PROTECTED]: Run 'svn up'? Duh! Nope. I'm doing it now after having read the log of Dave's commit. What scared me was that I could've used other classes to depend on, but I'd used the one that just got removed. I think Dave knew that I'd be using it and did it on purpose :) I think I have to double the thinking time before I do anything today ;) Thanks Kevan! --kevan Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Geronimo Web Site update
On 2/17/06, Hernan Cunico [EMAIL PROTECTED] wrote: I updated the Geronimo Web site, fixed some links and added Covalent Technologies to the *Geronimo News* and *Powered By* sections. I attached to the JIRA 1611 the entire directory structure (just like in the repo) so you can download it and review it locally. https://issues.apache.org/jira/browse/GERONIMO-1611 Thanks for your patience, Hernan. This will be addressed soon enough. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: Reducing the size of the minimal-tomcat-server footprint
David Jencks wrote: +---xerces | \---jars | xercesImpl-2.6.2.jar | xmlParserAPIs-2.2.1.jar ... I need to figure out how these are getting included Those are also duped in the endorsed directory, but I think it may be very difficult to get rid of these right now. I think we'd have do delete xerces by hand. I believe these are getting pulled in as dependencies of j2ee-system which are also copied into the endorsed dir. Preventing them from getting copied into the repo won't work :-), but deleting them later might be ok. We might remove everything in lib from the repo. This will probably break Tomcat is you remove these. The Digester needs these XML libs.
Re: Geronimo Web Site update
Hi Bruce, reading the note again I think it reads a bit dry. What I was thinking was that with the diff updated alone there was no way to easily see those updates. I thought it would be easier updating the whole structure (specially with the diff/update issues you found), it's just that never put it in writing :) I hope you guys like the updates and we can have this new site up and running soon :) Cheers! Hernan Bruce Snyder wrote: On 2/17/06, Hernan Cunico [EMAIL PROTECTED] wrote: I updated the Geronimo Web site, fixed some links and added Covalent Technologies to the *Geronimo News* and *Powered By* sections. I attached to the JIRA 1611 the entire directory structure (just like in the repo) so you can download it and review it locally. https://issues.apache.org/jira/browse/GERONIMO-1611 Thanks for your patience, Hernan. This will be addressed soon enough. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: Reducing the size of the minimal-tomcat-server footprint
On Feb 18, 2006, at 7:33 AM, Jeff Genender wrote: David Jencks wrote: +---xerces | \---jars | xercesImpl-2.6.2.jar | xmlParserAPIs-2.2.1.jar ... I need to figure out how these are getting included Those are also duped in the endorsed directory, but I think it may be very difficult to get rid of these right now. I think we'd have do delete xerces by hand. I believe these are getting pulled in as dependencies of j2ee-system which are also copied into the endorsed dir. Preventing them from getting copied into the repo won't work :-), but deleting them later might be ok. We might remove everything in lib from the repo. This will probably break Tomcat is you remove these. The Digester needs these XML libs. Doesn't it need them in the classpath or in the endorsed directory rather than specifically in the repo? right now we have 2 copies of these and probably everything in lib. I at least am proprosing removing only the copy in the repo. thanks david jencks
[jira] Updated: (GERONIMO-1632) Test
[ http://issues.apache.org/jira/browse/GERONIMO-1632?page=all ] Alan Cabrera updated GERONIMO-1632: --- Regression Bug: [Regression] Test Key: GERONIMO-1632 URL: http://issues.apache.org/jira/browse/GERONIMO-1632 Project: Geronimo Type: Bug Reporter: Alan Cabrera Assignee: Alan Cabrera Test -- 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-1632) Test
[ http://issues.apache.org/jira/browse/GERONIMO-1632?page=all ] Alan Cabrera closed GERONIMO-1632: -- Resolution: Fixed Test Key: GERONIMO-1632 URL: http://issues.apache.org/jira/browse/GERONIMO-1632 Project: Geronimo Type: Bug Reporter: Alan Cabrera Assignee: Alan Cabrera Test -- 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: Reducing the size of the minimal-tomcat-server footprint
Why remove them form the repository? Shouldn't we / can't we just delete the lib directory and change the manifest to point to those libs in the repository instead of in the lib directory? Thanks, Aaron On 2/18/06, David Jencks [EMAIL PROTECTED] wrote: On Feb 18, 2006, at 7:33 AM, Jeff Genender wrote: David Jencks wrote: +---xerces | \---jars | xercesImpl-2.6.2.jar | xmlParserAPIs-2.2.1.jar ... I need to figure out how these are getting included Those are also duped in the endorsed directory, but I think it may be very difficult to get rid of these right now. I think we'd have do delete xerces by hand. I believe these are getting pulled in as dependencies of j2ee-system which are also copied into the endorsed dir. Preventing them from getting copied into the repo won't work :-), but deleting them later might be ok. We might remove everything in lib from the repo. This will probably break Tomcat is you remove these. The Digester needs these XML libs. Doesn't it need them in the classpath or in the endorsed directory rather than specifically in the repo? right now we have 2 copies of these and probably everything in lib. I at least am proprosing removing only the copy in the repo. thanks david jencks
[jira] Commented: (GERONIMO-1638) Multiple servers sharing the same repo and config store
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12366943 ] Gianny Damour commented on GERONIMO-1638: - The second solution has been implemented. When starting G, it is now possible to specify one of these two system properties: * org.apache.geronimo.server.name: name of the server to be started. If server1 is specified, then G will use the directory geronimo installation dir/server1; or * org.apache.geronimo.server.dir: directory of the server to be started. This can be either a relative or an absolute path. For instance, if ./server1 is specified, then G will use the directory geronimo installation dir/server1. Multiple servers sharing the same repo and config store --- Key: GERONIMO-1638 URL: http://issues.apache.org/jira/browse/GERONIMO-1638 Project: Geronimo Type: New Feature Components: usability Versions: 1.0 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 1.1 David J. sent to the dev mailing list: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are located outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to relocate. I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like resolveVar and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the var trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now var. Several people have suggested putting an additional config-store into var for private use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks -- 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: Multiple servers sharing the same repo and config store
Hi, The second solution has been implemented. When starting G, it is now possible to specify one of these two system properties: * org.apache.geronimo.server.name: name of the server to be started. If server1 is specified, then G will use the directory geronimo installation dir/server1; or * org.apache.geronimo.server.dir: directory of the server to be started. This can be either a relative or an absolute path. For instance, if ./server1 is specified, then G will use the directory geronimo installation dir/server1. I still need to provide a patch for an AMQ GBean, JournalPersistenceAdapterGBean, in order to resolve its directory attribute based on the server directory - will do that during the day. Thanks, Gianny David Jencks wrote: On Feb 12, 2006, at 9:17 AM, Vincent Massol wrote: Hi David and everyone, Any progress on this? not yet, sorry. it is pretty easy, but I am tied up in the configid branch right now. david jencks Thanks -Vincent -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 08:23 To: dev@geronimo.apache.org Subject: Multiple servers sharing the same repo and config store Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are located outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to relocate. I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like resolveVar and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the var trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now var. Several people have suggested putting an additional config-store into var for private use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
[jira] Commented: (GERONIMO-1035) tomcat integration should wrap each servlet indiviudally
[ http://issues.apache.org/jira/browse/GERONIMO-1035?page=comments#action_12366950 ] Jeff Genender commented on GERONIMO-1035: - Hi Anita. Cool code...and a lot of it looks good. But a few questions ... could you please explain where you shut off the web.xml parsing from Tomcat? It would appear that you are adding the servlets as well as Tomcat, so you would have double the servlet based objects created. I did not see where the Digester was shut off or where you grabbed the servlet creation instead of Tomcat. If you could show me where this is done, I can proceed forward in the testing of this code and integrating it. tomcat integration should wrap each servlet indiviudally Key: GERONIMO-1035 URL: http://issues.apache.org/jira/browse/GERONIMO-1035 Project: Geronimo Type: New Feature Components: Tomcat Versions: 1.0-M5 Environment: All Reporter: Anita Kulshreshtha Assignee: Jeff Genender Fix For: 1.1 Attachments: geronimo-stats-1.1-SNAPSHOT.war, management.patch, stats.zip, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat.patch, tomcat.patch TomcatModuleBuilder should wrap each servlet specified in the deployment descriptor individually. This is needed by JSR-77 and for gathering tomcat internal statistics. -- 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
