Re: svn commit: r1358803 - in /geronimo/server/branches/2.2/plugins/dojo: dojo-jetty/pom.xml dojo-tomcat/pom.xml
Sure. But, as far as I knew, the portlets were using the 1.4.x version of Dojo. I did update that from 1.4.2 to 1.4.3 - they should have kept that compatible. But I will check to make sure that all of the monitor pages still work. Jay On 07/08/2012 11:24 PM, Shawn Jiang wrote: Hi Jay, Could you please help to make sure the portlets that are using dojo can work flawlessly after the upgrading ? you know, dojo was not doing a good job on backward-compatibility. On Mon, Jul 9, 2012 at 2:09 AM, ja...@apache.org wrote: Author: jaydm Date: Sun Jul 8 18:09:46 2012 New Revision: 1358803 URL: http://svn.apache.org/viewvc?rev=1358803view=rev Log: Upgrading the version of Dojo to 1.7.2 Modified: geronimo/server/branches/2.2/plugins/dojo/dojo-jetty/pom.xml geronimo/server/branches/2.2/plugins/dojo/dojo-tomcat/pom.xml Modified: geronimo/server/branches/2.2/plugins/dojo/dojo-jetty/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.2/plugins/dojo/dojo-jetty/pom.xml?rev=1358803r1=1358802r2=1358803view=diff == --- geronimo/server/branches/2.2/plugins/dojo/dojo-jetty/pom.xml (original) +++ geronimo/server/branches/2.2/plugins/dojo/dojo-jetty/pom.xml Sun Jul 8 18:09:46 2012 @@ -43,7 +43,7 @@ dependency groupIdorg.dojotoolkit/groupId artifactIddojo-war/artifactId -version1.6.1/version +version1.7.2/version typewar/type scopeprovided/scope /dependency @@ -78,7 +78,7 @@ module groupIdorg.dojotoolkit/groupId artifactIddojo-war/artifactId -version1.4.2/version +version1.4.3/version typewar/type /module Modified: geronimo/server/branches/2.2/plugins/dojo/dojo-tomcat/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.2/plugins/dojo/dojo-tomcat/pom.xml?rev=1358803r1=1358802r2=1358803view=diff == --- geronimo/server/branches/2.2/plugins/dojo/dojo-tomcat/pom.xml (original) +++ geronimo/server/branches/2.2/plugins/dojo/dojo-tomcat/pom.xml Sun Jul 8 18:09:46 2012 @@ -43,7 +43,7 @@ dependency groupIdorg.dojotoolkit/groupId artifactIddojo-war/artifactId -version1.6.1/version +version1.7.2/version typewar/type scopeprovided/scope /dependency @@ -78,7 +78,7 @@ module groupIdorg.dojotoolkit/groupId artifactIddojo-war/artifactId -version1.4.2/version +version1.4.3/version typewar/type /module
OpenEJB version to use for G2.2.2
Hey All, I just took a look at OpenEJB's 3.1.x source tags and they stop at 3.1.4. Geronimo 2.2.x is looking for 3.1.5-SNAPSHOT - but it looks like there will never be a 3.1.5 final. Does anyone know what version has the fixes we were using in 3.1.5-SNAPSHOT and would be backward compatible? I could just go ahead and try 3.2 but that feels like a big jump. Jay
Re: Some history releases gone?
Hey Forrest, The download links for the older versions are supposed to have been updated to point to the archives (http://archive.apache.org/dist/geronimo/). Just for the purpose of cleanup of the dist folder. They all still exist. I am actually surprised at how many are still available on the regular download location. Jay On 12/28/2011 09:20 PM, Forrest Xia wrote: I am doing release for G 2.1.8, I found lots of history releases are gone from the apache dist folder, that is, users won't be able to download a history release from our web site. Anyone know the story about it? -- Thanks! Regards, Forrest
Re: [VOTE] Release Geronimo 2.1.8 RC2
+1 Jay On 12/21/2011 12:05 AM, Forrest Xia wrote: Hi folks, A release candidate for Geronimo 2.1.8 has been created and staged. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.8/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-377/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-377/org/apache/geronimo/geronimo/2.1.8/geronimo-2.1.8-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-377/org/apache/geronimo/geronimo/2.1.8/geronimo-2.1.8-source-release.zip A tck execution against 2.1.8 tag is ongoing, and will be finished around 16 hours later. I will update the status here. The vote will be open for 72 hours. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) -- Thanks! Regards, Forrest
Re: [ANNOUNCE] Welcome Trygve Hardersen as a new Geronimo committer
Congratulations and welcome! Jay On 12/08/2011 10:18 AM, Kevan Miller wrote: Everyone, In recognition of his contributions to the Geronimo project, the Geronimo PMC recently invited Trygve Hardersen to become a committer on our project. We are pleased to announce that he has accepted our invitation. Please join us in congratulating Trygve. Welcome! --kevan
Re: Geronimo redeploy issue.
Hello Ranjan,
The one hint I would offer is to stop the server using either the
console or the shutdown script. Simply killing the java process can
leave the server in an unstable state.
Jay
On 12/05/2011 11:16 PM, ranbaab wrote:
Hi,
Our exploded web application is extracted in the deploy folder of geronimo
during the time of installation.
The application is install and launch the UI successfully.
After stopping the server, if I manually update any jsp or any file from the
deployed application, the server got hang after restart.
-
The geronimo.log does not give any clue, the server got hang at
2011-12-01 14:42:46,199 INFO [DirectoryMonitor] At startup, found
/geronimo/deploy/ourApplication with deploy time 1322730003272 and file time
1322729818000
2011-12-01 14:42:50,423 INFO [DirectoryHotDeployer] *Redeploying
ourApplication*
And the console output is
Listening on Ports:
8009 0.0.0.0 Tomcat Connector AJP TomcatAJPConnector
0.0.0.0 JMX Remoting Connector
40080 0.0.0.0 Tomcat Connector HTTP BIO TomcatWebConnector
40099 0.0.0.0 RMI Naming
40443 0.0.0.0 Tomcat Connector HTTPS BIO TomcatWebSSLConnector
Started Application Modules:
WAR: ourapplication/xyz/application/war
WAR: org.apache.geronimo.configs/remote-deploy-tomcat/2.2.1/car
Web Applications:
/ourApplication
/remote-deploy
Geronimo Application Server started
-
In geronimo-web.xml, version is not a numeric
sys:versionapplication/sys:version
I am wondering whether the time stamp change of the file is causing the
issue.
According to my knowledge, the hot deploy should take care this scenerio.
The geronimo server is stop by using kill -9 PID.
Even I download the source code and try to build it, but due to some issue,
I am not able to build it.
The application got stuck in the file
org.apache.geronimo.deployment.hot.DirectoryHotDeployer method fileUpdated
public String fileUpdated(File file, String configId) {
log.info(*Redeploying + file.getName())*;
DeploymentManager mgr = null;
I would really appreciate if some one throw some light about this issue.
Thanks,
Ranjan
--
View this message in context:
http://apache-geronimo.328035.n3.nabble.com/Geronimo-redeploy-issue-tp3563502p3563502.html
Sent from the Development mailing list archive at Nabble.com.
Re: Fwd: Accepting proposals regarding early git adoption
Is the idea for this to abandon SVN and move completely over to git? Or is it just to add git as a way for folks to manage their local copies of the source? Jay On 11/29/2011 03:22 PM, Kevan Miller wrote: Forwarding (with permission), in case there's interest within Geronimo community. --kevan Begin forwarded message: From: Joe Schaeferjoe_schae...@yahoo.com Subject: Accepting proposals regarding early git adoption Date: November 28, 2011 8:28:17 AM EST To: Apache Infrastructureinfrastruct...@apache.org Reply-To: Joe Schaeferjoe_schae...@yahoo.com While many of you are aware of the ongoing experiment/alpha test with git hosting for CouchDB, you may not be aware of the recent members@ discussion about git @ Apache, the result of which is to solicit proposals here for projects interested in adopting git now, rather than after the testing phase is over. Any such projects you participate in should write a brief and civil proposal as to why we should select you for further git testing. Proposals should include statements of interest in assisting with the git hosting codebase and associated jira issues from named individuals on the project. We'll allow the remainder of the week to collect proposals before deciding on who gets to go next.
Re: Welcome Shenghao Fang as a new Geronimo committer
Congratulations Michael and welcome! Jay On 08/18/2011 09:18 AM, Shawn Jiang wrote: I'd like to welcome Shenghao Fang on aboard, as he recently accepted the Geronimo PMC invitation to become a committer. His account was just created , so you should start seeing some commits from him soon. -- Shawn
[jira] [Commented] (GERONIMO-5743) ServletContext.getRealPath() returns null
[ https://issues.apache.org/jira/browse/GERONIMO-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085915#comment-13085915 ] Jay D. McHugh commented on GERONIMO-5743: - Is this happening for Tomcat or Jetty (or both)? And, is it returning null when you do not send it a parameter - or when there is a parameter passed in too? ServletContext.getRealPath() returns null - Key: GERONIMO-5743 URL: https://issues.apache.org/jira/browse/GERONIMO-5743 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 3.0-M1 Reporter: Jarek Gawor Assignee: Ivan Fix For: 3.0 In 3.0 M1 and trunk, ServletContext.getRealPath() returns null. In previous versions of Geronimo a real path was returned. Returning null is ok from specification point of view but it breaks compatibility for applications. It also looks like there are a number of web applications that rely on the getRealPath() to return a non-null value. One such application is Nexus web app. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5743) ServletContext.getRealPath() returns null
[ https://issues.apache.org/jira/browse/GERONIMO-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-5743: Comment: was deleted (was: Is this happening for Tomcat or Jetty (or both)? And, is it returning null when you do not send it a parameter - or when there is a parameter passed in too?) ServletContext.getRealPath() returns null - Key: GERONIMO-5743 URL: https://issues.apache.org/jira/browse/GERONIMO-5743 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 3.0-M1 Reporter: Jarek Gawor Assignee: Ivan Fix For: 3.0 In 3.0 M1 and trunk, ServletContext.getRealPath() returns null. In previous versions of Geronimo a real path was returned. Returning null is ok from specification point of view but it breaks compatibility for applications. It also looks like there are a number of web applications that rely on the getRealPath() to return a non-null value. One such application is Nexus web app. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Geronimo 2.2.1
Hey Johannes, I built my app against G 2.1 using the eclipse plugin - then deployed it on G 2.2. Are you specifically calling for versions of your dependencies? Have you tried building as if you were going to deploy to a 2.1 server and then deployed onto 2.2? Jay On 12/09/2010 08:14 AM, Johannes Weberhofer wrote: Hi Trygve, I don't think the JETTY-1308 is related, because I've worked with the tomcat version. And only the left-hand menu was not visible. I can no longer reproduce the problem, I have tried with new installation etc. As I'm currently not able to build and test our software-product for the new version, here is my +0 for the vote. I've tested + building + unpacking and installation + running the system + install a datasource + execute some statements on the MySQL server Johannes Am 09.12.10 14:23, schrieb Trygve Sanne Hardersen: Hi Maybe JETTY-1308 is related to the AJP problems? Not sure, but seems to me like Jetty 7.2.1 is affected. Jetty 7.2.2 with a fix from r2589 has been tagged, but AFAICT it's not available in the central Maven repo yet. Trygve On Thu, Dec 9, 2010 at 10:58 AM, Johannes Weberhofer jweberho...@weberhofer.at mailto:jweberho...@weberhofer.at wrote: Ok. So I can not rebuild my application for the moment? I get: org.apache.geronimo.kernel.repository.MissingDependencyException: Missing dependency: org.apache.geronimo.javamail/geronimo-javamail_1.4_mail/1.7/jar Am 09.12.10 10:51, schrieb Shawn Jiang: Dev tool depends on server artifacts. We have to do the dev tools release after the server release. On Thu, Dec 9, 2010 at 5:44 PM, Johannes Weberhofer jweberho...@weberhofer.at mailto:jweberho...@weberhofer.at wrote: Strange; It's working suddenly - I don't know, what has changed. I'd like to deploy an application, now. As I must re-compile it: Is there any pre-built Eclipse plug-in for 2.2.1 available, as the link http://people.apache.org/dist/geronimo/eclipse/unstable/updates on http://geronimo.apache.org/development-tools.html seems to be incorrect... Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna
Re: [VOTE] Release Geronimo 2.2.1
When I build and start the Tomcat JavaEE server I do not have the database pools menu choice. I am looking under 'services'. Did it move? As confirmation I am double checking the prebuilt bin on the staging site. Please do not call the vote until I have a chance to confirm whether this is a problem or not. Thanks, Jay On 12/03/2010 09:20 PM, Shawn Jiang wrote: Hi all, A release candidate for Geronimo 2.2.1 has been created and staged. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.2.1/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-048 The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-048/org/apache/geronimo/geronimo/2.2.1/geronimo-2.2.1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-048/org/apache/geronimo/geronimo/2.2.1/geronimo-2.2.1-source-release.zip The vote will be open for the 72-hour minimum. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why)
Re: [VOTE] Release Geronimo 2.2.1
+1 False alarm - I must have done something wrong in starting the server. Everything looks good (locally built and downloaded). Built and started. Updated repository, deployed and tested real custom application. Jay On 12/08/2010 12:13 PM, Jay D. McHugh wrote: When I build and start the Tomcat JavaEE server I do not have the database pools menu choice. I am looking under 'services'. Did it move? As confirmation I am double checking the prebuilt bin on the staging site. Please do not call the vote until I have a chance to confirm whether this is a problem or not. Thanks, Jay On 12/03/2010 09:20 PM, Shawn Jiang wrote: Hi all, A release candidate for Geronimo 2.2.1 has been created and staged. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.2.1/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-048 The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-048/org/apache/geronimo/geronimo/2.2.1/geronimo-2.2.1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-048/org/apache/geronimo/geronimo/2.2.1/geronimo-2.2.1-source-release.zip The vote will be open for the 72-hour minimum. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why)
Re: [VOTE] Release Geronimo 2.2.1
When I built from source, the menu initially showed up collapsed. Is that what you are seeing? Jay On 12/08/2010 05:20 PM, Johannes Weberhofer wrote: Strange - I could compile+start the packages without problems, but in both -javaee5 (tomcat and jetty) packages I do not have any menu at the left hand /console/portal/ interface. Best regards, Johannes Am 08.12.10 19:13, schrieb Jay D. McHugh: When I build and start the Tomcat JavaEE server I do not have the database pools menu choice. I am looking under 'services'. Did it move? As confirmation I am double checking the prebuilt bin on the staging site. Please do not call the vote until I have a chance to confirm whether this is a problem or not. Thanks, Jay On 12/03/2010 09:20 PM, Shawn Jiang wrote: Hi all, A release candidate for Geronimo 2.2.1 has been created and staged. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.2.1/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-048 The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-048/org/apache/geronimo/geronimo/2.2.1/geronimo-2.2.1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-048/org/apache/geronimo/geronimo/2.2.1/geronimo-2.2.1-source-release.zip The vote will be open for the 72-hour minimum. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why)
Re: Welcome Janet Hong Fang Han as a new committer
Congratulations Janet! Jay On 10/20/2010 08:11 PM, Ivan wrote: I would like to welcome Janet aboard, as she recently accepted the Geronimo PMC invitation to become a committer. Her account was just created this morning (hanhongfang), so you should start seeing some commits from her soon. -- Ivan
Re: List moderators
I'll help moderate too. Jay On 09/22/2010 01:03 PM, Kevan Miller wrote: On Sep 21, 2010, at 10:41 AM, Vescovi, Matteo wrote: Hi, How can I contact the dev@geronimo.apache.org mailing list administrator? I tried dev-ow...@geronimo.apache.org as instructed by ezmlm, but I received no reply. All, dev-owner@ is a pseudonym for the moderators of the dev@ mailing list. Our moderators for dev@ and user@ are a bit dated. I've been added as a moderator. However, would be good to have one or two more active moderators. Any PMC volunteers to help moderate? I've been moderator for a day or so. Looks like there is a moderate amount of spam involved. I'd estimate 4-8 spam emails a day. --kevan
Re: [ANNOUNCE] Welcome Xuan Dai Delos as a new Geronimo PMC member
Congratulations! Jay On 09/07/2010 02:32 PM, Donald Woods wrote: Please join us in congratulating Delos as a new member of the Geronimo PMC. In addition to all his work on GEP and Samples, Delos also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratulation Delos !!! The Apache Geronimo PMC
Re: [ANNOUNCE] Welcome Ming Xai Forrest as a new Geronimo PMC member
Congratulations! Jay On 09/07/2010 02:34 PM, Donald Woods wrote: Please join us in congratulating Forrest as a new member of the Geronimo PMC. In addition to all his work on Samples, Forrest also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratulation Forrest !!! The Apache Geronimo PMC
Re: [ANNOUNCE] Welcome Rex Wang as a new member of the Geronimo PMC
Congratulations! Jay On 09/07/2010 08:44 AM, 王广哲 wrote: Congratulations to Rex!!! 2010/9/7 Rick McGuire rick...@gmail.com mailto:rick...@gmail.com Please join us in congratulating as a new member of the Geronimo PMC. In addition to serving as a release manager for the Geronimo 2.1.5 server release, Rex also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratuatlons Rex !!! The Apache Geronimo PMC
Re: [ANNOUNCE] Welcome Ming Xai Forrest as a new Geronimo PMC member
Congratulations! Jay On 09/07/2010 02:34 PM, Donald Woods wrote: Please join us in congratulating Forrest as a new member of the Geronimo PMC. In addition to all his work on Samples, Forrest also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratulation Forrest !!! The Apache Geronimo PMC
Re: [VOTE] Release Geronimo 2.1.6 - second attempt.
+1 (pending TCK) Jay On 06/23/2010 04:24 AM, Rick McGuire wrote: A release candidate for Geronimo 2.1.6 has been created and staged. This version is the same as the previous release candidate except for an upgrade to the spring framework dependency. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.6 The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-008 The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.zip The distribution artifacts have been copied to a second staging repository for your convenience: http://people.apache.org/~rickmcguire/staging-repo/2.1.6/ We have to verify the binaries pass the tck, so the vote may be open for longer than the 72-hour minimum. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Rick
Re: [VOTE] Release Geronimo 2.1.6
+1 Built and started. Thanks Rick! Jay On 06/18/2010 11:31 AM, Rick McGuire wrote: A release candidate for Geronimo 2.1.6 has been created and staged. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.6/ https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.5/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-001/ https://repository.apache.org/content/repositories/orgapachegeronimo-005/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-001/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/geronimo/2.1.5/geronimo-2.1.5-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-001/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/geronimo/2.1.5/geronimo-2.1.5-source-release.zip The distribution artifacts have been copied to a second staging repository for your convenience: http://people.apache.org/~rickmcguire/staging-repo/2.1.6/ We have to verify the binaries pass the tck, so the vote may be open for longer than the 72-hour minimum. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Rick
[jira] Commented: (GERONIMO-4130) Unable to preserve comments from plan.xml into config.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869772#action_12869772 ] Jay D. McHugh commented on GERONIMO-4130: - This ticket has two parts. The original issue was enabling and disabling services. The issue of comments came up because that used to be the way to accomplish enabling and disabling services. I think that the issue of enabling and disabling services is already handled by the 'load' attribute of the 'module' entities. If I am mistaken about using the load attribute to control whether a particular module starts or not then this ticket is valid. And we need to make sure that there is a simple and straight forward way to determine which modules are started (we also need to make sure that the title of this ticket is changed to reflect the actual problem). If the load attribute does control which modules actually start, then the use of comments in the config.xml file is a completely separate issue. And, it should get it's own (new) ticket. Here is a discussion of how comments are being handled in the config.xml and why. If anyone thinks that it would be worthwhile to handle 'true XML comments' then we should open a new ticket to track that. There is a problem with using 'real' comments. And that problem is that the tools that are being used to parse the XML files completely ignore them. So, whenever one of these files are parsed and then recreated - the comment would be lost. That is why the comment tag was used in the first place. Comments are normally 'for human consumption' only. We needed to put them into the actual XML data in order to tell the parser that they really are a part of the data and not just fluff for people to read. The config.xml file is read in during server start up and recreated from scratch during shutdown. Real XML style comments (and their location within the file) do not appear to be maintained by the parser/builder. We would need to make our own XML parser that internally converted the comments into XML data and a new XML builder that would re-convert that special comment data back into actual comments. Sorry that it took so long for me to realize that I was answering a different problem than the real issue. Lin, Have I finally seen the problem that you were trying to bring up (modifying which services start)? Do you still think that there is a problem with how comments are being handled? Jay Unable to preserve comments from plan.xml into config.xml - Key: GERONIMO-4130 URL: https://issues.apache.org/jira/browse/GERONIMO-4130 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: car-maven-plugin Affects Versions: 2.1.x, 2.2 Reporter: Lin Sun Fix For: 2.2.1, Wish List I got a user asking me how to turn off tomcat access log. It was easy in previous releases, as we could provide comment in config.xml and tell the users to To disable accesslogging uncomment the following section However, with our new config.xml, we don't preserve any comments, which makes hard for users to config things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Congrats Donald Woods! New ASF Member
Wow! Congratulations Donald! Jay On 05/02/2010 08:28 AM, Kevan Miller wrote: Wanted to let the Geronimo community know that Donald Woods is a new member of the ASF. The ASF membership elected Donald in recognition of his many contributions to Geronimo, OpenJPA, and Incubator projects. Congrats to Donald on this well deserved achievement! --kevan
Re: [VOTE] Release Geronimo 2.1.5 (1st try)
+1 pending TCK Built fine and my live app installs fine and works. Jay Rex Wang wrote: Dear All, I have managed to use maven-release-plugin to make a 2.1.5 release candidate The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.5/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-005/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/geronimo/2.1.5/geronimo-2.1.5-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/geronimo/2.1.5/geronimo-2.1.5-source-release.zip We have to verify the binaries pass the tck, so open the vote for more than the minimum 72 hours. -- Lei Wang (Rex) rwonly AT apache.org http://apache.org
[jira] Commented: (GERONIMO-5216) CLONE -getContextRoot() returns forward slash rather than empty string for apps deployed to root context
[ https://issues.apache.org/jira/browse/GERONIMO-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851427#action_12851427 ] Jay D. McHugh commented on GERONIMO-5216: - Hey Matthias, It looks like this must be a problem with how the tag library is processing the c:url tag. I will try to take a look as soon as I have some time. Jay CLONE -getContextRoot() returns forward slash rather than empty string for apps deployed to root context Key: GERONIMO-5216 URL: https://issues.apache.org/jira/browse/GERONIMO-5216 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.2 Reporter: Matthias Koch Assignee: Jay D. McHugh An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Ashish Jain - Geronimo's newest committer
Congratulations Ashish! Jay Jason Warner wrote: Congrats, Ashish! ~Jason Warner On Sun, Mar 14, 2010 at 4:44 PM, Joe Bohn joe.b...@earthlink.net mailto:joe.b...@earthlink.net wrote: All, Please join me in welcoming Ashish Jain as the newest committer on the Apache Geronimo project. The Geronimo PMC is excited that Ashish has accepted our invitation. Congratulations Ashish and keep up the good work! Joe
Re: Welcome Forrest Ming Xia as a new committer
Congratulations Forrest! Jay Kevan Miller wrote: Congrats Forrest! --kevan On Mar 8, 2010, at 8:54 PM, Ivan wrote: I would like to welcome Forrest aboard, as he recently accepted the Geronimo PMC invitation to become a committer. His account (xiaming) was just created, so you should start seeing some commits from him soon. -- Ivan
Re: [VOTE] Release geronimo-atinject_1.0_spec-1.0-beta - RC2
+1 Jay Donald Woods wrote: To support the upcoming OpenWebBeans milestone release and as a prereq to the geronimo-jcdi_1.0_spec-1.0-beta release, I would like to release a Beta of the Inject Spec API. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-006/ Source tag: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-atinject_1.0_spec-1.0-beta/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Donald
Re: [VOTE] Release geronimo-el_2.2_spec-1.0-beta - RC2
+1 Jay Donald Woods wrote: To support the upcoming OpenWebBeans milestone release and as a prereq for the geronimo-jcdi_1.0_spec-1.0-beta release, I would like to release a Beta of the EL 2.2 Spec API. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-007/ Source tag: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-el_2.2_spec-1.0-beta/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Donald
Re: [VOTE] Release geronimo-interceptor_1.1_spec-1.0.0-beta
+1 Jay Donald Woods wrote: To support the upcoming OpenWebBeans milestone release, I would like to release a Beta of the Interceptor Spec API. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-073/ Source tag: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-interceptor_1.1_spec-1.0.0-beta Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Donald
Re: [VOTE]- Geronimo Samples 2.2
+1 Built fine and passed RAT. Jay Delos wrote: Hi All, Forrest and I work together and prepared a release candidate of Geronimo Samples 2.2 for your review and vote. This is the second independent release of samples for Geronimo. Besides some bug fixes, in this release, there are two new samples added: 1. DataCDInfo -- demo a popular web application framework Struts1 in geronimo. User can use it as a struts1 app template to start their own development. In the same time, it also demos how to use JPA with a JTA underlying. Compared with daytrader, this sample is simpler to understand; Of cause, this sample also includes some code to demo security annotations usage. 2. csa-activemq -- demo how to use car-maven-plugin to build a custom server assembly. This sample assembles geronimo integrated ActiveMQ modules(including the new geronimo plugin activemq-webconsole), so that user can use it as standalone JMS server with user-friendly web interfaces to manage JMS objects. We did some testing on the built artifacts and everything seems well. For most of samples, they can be installed on either Geronimo 2.2 or Geronimo 2.1.4. All of the samples are available for installation as plugins on Geronimo 2.2. We have created a plugin catalog for your convenience. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-060/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-2.2/ Repository for plugin install: http://geronimo.apache.org/plugins/samples-2.2/ When the release vote is approved, the maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. Vote will be open for 72 hours until Jan. 27, 2010. [ ] +1 Release Geronimo Samples 2.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo Samples 2.2 (please provide rationale) Thanks very much for Forrest's great work! -- Best Regards, Delos
Re: [VOTE]- Geronimo Eclipse Plugins 2.2 - RC3 (3rd try)
+1 Jay Delos wrote: Hi everyone, Please review and vote on the release of the Geronimo Eclipse Plugin 2.2 *RC3*. Compared to RC2, RC3 contains source code packages, checksum and signature files for you to review. You can verify the integrity of the files with KEYS from http://www.apache.org/dist/geronimo/KEYS The source code packages are here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2-source-release.tar.gz http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2-source-release.zip The deployable binary zip file is here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2.0-deployable.zip The update site binary zip file is here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2.0-updatesite.zip The current svn location is here (revision number 897748): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.2 The future svn location will be here (when approved): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.2 If you would like to review and/or comment on the release notes, they are here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/PLUGIN_RELEASE-NOTES-2.2.0.txt There is a rudimentary set of install instructions available at the URL below that will hopefully describe the necessary prereq(s) and steps required to install and run the GEP: http://cwiki.apache.org/GMOxDOC22/how-to-install-geronimo-eclipse-plugin.html In an effort to get more people to review and vote I'd recommend going through this quick but useful tutorial demonstrating some of the capabilities of the GEP: http://cwiki.apache.org/GMOxDOC22/5-minute-tutorial-on-enterprise-application-development-with-eclipse-and-geronimo.html Finally, I've created a Staging Site that can be used to test the update manager functions (i.e., p2 in Ganymede or Galileo) of Eclipse for downloading the GEP itself. This is also documented in the instructions, but you must use the staging site created for this vote at: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/updates/ Please let me know if there are any questions and/or problems. The vote is open for 72 hours. [ ] +1 Release Geronimo Eclipse Plugin 2.2 [ ] +0 No opinion [ ] -1 Don't release Geronimo Eclipse Plugin 2.2 Thanks in advance! -- Best Regards, Delos
Re: [VOTE] Release geronimo-validation_1.0_spec-1.0
+1 Built successfully and verified that rat:check passes. Jay Donald Woods wrote: Hi, I'd like to release v1.0 of the Bean Validation Spec API, now that we have it passing the Bean Validation 1.0 TCK signature tests. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-065/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-validation_1.0_spec-1.0/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Donald
Re: [VOTE] Release geronimo-jpa_2.0_spec-1.0 (2nd try)
+1 Jay Donald Woods wrote: Hi, I'd like to release v1.0 of the JPA 2.0 Spec API, now that we have OpenJPA trunk and our API passing the JPA2 TCK. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-036/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_2.0_spec-1.0/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Donald
Re: [VOTE - 2nd try] Vote for release GEP 2.2 - RC2
+1 It seems to be working for me. Thanks again to everyone who works on this. Jay Delos wrote: Hi everyone, Please review and vote on the release of the Geronimo Eclipse Plugin 2.2 *RC2*. The deployable zip file is here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC2/staging_site/geronimo-eclipse-plugin-2.2.0-deployable.zip The update site zip file is here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC2/staging_site/geronimo-eclipse-plugin-2.2.0-updatesite.zip The current svn location is here (revision number 897748): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.2 The future svn location will be here (when approved): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.2 If you would like to review and/or comment on the release notes, they are here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC2/staging_site/PLUGIN_RELEASE-NOTES-2.2.0.txt There is a rudimentary set of install instructions available at the URL below that will hopefully describe the necessary prereq(s) and steps required to install and run the GEP: http://cwiki.apache.org/GMOxDOC22/how-to-install-geronimo-eclipse-plugin.html In an effort to get more people to review and vote I'd recommend going through this quick but useful tutorial demonstrating some of the capabilities of the GEP: http://cwiki.apache.org/GMOxDOC22/5-minute-tutorial-on-enterprise-application-development-with-eclipse-and-geronimo.html Finally, I've created a Staging Site that can be used to test the update manager functions (i.e., p2 in Ganymede or Galileo) of Eclipse for downloading the GEP itself. This is also documented in the instructions, but you must use the staging site created for this vote at: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC2/staging_site/updates/ Please let me know if there are any questions and/or problems. The vote is open for 72 hours and will conclude on Thuresday (Jan 14,2010) at 10:00 AM ET. [ ] +1 Release Geronimo Eclipse Plugin 2.2 [ ] +0 No opinion [ ] -1 Don't release Geronimo Eclipse Plugin 2.2 Thanks in advance! -- Best Regards, Delos
Re: [Discussion] How about upgrade Dojo version to 1.4.0 for Geronimo 3.0?
I asked on the Dojo mailing list to see if someone was going to deploy a current version (1.4.0) out to a public repo - but since 12/15/09 there has not been any response. Maybe if someone else asked too... Jay Rex Wang wrote: So far I can not find dojo 1.4.x in any public repo? However, i am agree for this update in 3.0 once it done. In G2.2, the portlets using dojo1.3.2 are ejb portlet and debug view portlets, some portlets may need rewrite or remove in G3.0, such as classloaders, ldap... So it is OK to make these changes and lib update all in one step. -Rex 2010/1/6 Delos dait...@gmail.com mailto:dait...@gmail.com As I know, some new widgets are added and most of the widgets from old version are kept. I agree with Shawn, we can verify the pages once admin console in G 3.0 is ready. Thanks! 2010/1/6 Shawn Jiang genspr...@gmail.com mailto:genspr...@gmail.com Agree , we should test the functions that were using old dojo to see if they are still working after upgrading to dojo 1.4.0. On Wed, Jan 6, 2010 at 2:54 PM, Ivan xhh...@gmail.com mailto:xhh...@gmail.com wrote: Is the new version compatable with the old one ? If yes, I think we could upgrade it. 2010/1/6 Delos dait...@gmail.com mailto:dait...@gmail.com Hi, Dojo 1.4.0 has released on Dec.15. How about upgrade Dojo version to 1.4.0 for Geronimo 3.0? Some new Widgets are provided, such as EnhancedDataGrid; meanswhile a lot of refactoring work makes it faster than before. BTW, for you to feel the improvement of Dojo 1.4.0, I have uploaded a demo of pluto 2.0 and Dojo 1.4.0 here https://svn.apache.org/repos/asf/geronimo/sandbox/delos/portlet+dojo/portlet-dojo1.4.0-demo.zip. Steps to run demo 1. Extract the zip 2. launch bin/startup.sh or bin/startup.bat 3. visit http://localhost:8080/pluto/portal/BundlePage“, you will see a portlet showing OSGI bundles with dojo 1.4.0 widgets Upgrade to Dojo 1.4.0, any comments? Thanks! -- Best Regards, Delos -- Ivan -- Shawn -- Best Regards, Delos -- Lei Wang (Rex) rwonly AT apache.org http://apache.org
Re: [VOTE] geronimo 2.2 release (2nd try)
+1 I built the server from the source tar and was able to deploy and run my app (includes EJBs, JPA, messaging, JSPs). Jay David Jencks wrote: I've managed to come up with a 2nd 2.2 release candidate built using the maven-release-plugin. This includes Kevan;s fixes of source headers and a warning removal. See the jira issues here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220styleName=Htmlversion=12312965 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220styleName=Htmlversion=12312965 Staged to https://repository.apache.org/content/repositories/orgapachegeronimo-043/ https://repository.apache.org/content/repositories/orgapachegeronimo-024 The main artifacts up for vote are the source release archives https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-024/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-024/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.zip If you vote you should at least examine these and make sure something plausible builds from them. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Many thanks david jencks
Google Wave
Hello all, I just got a Google Wave account and it made me think about how this new technology might get incorporated into Apache culture. I know that right now - everything should occur on list. And, the ability to go back to the list to see what discussions and decisions were made is important (both to keep decision making and to me personally - my mail archive is insanely large). But once Google Wave makes it out of its preview stage (and once Apache develops its own wave server) then the question of what wave conversations are appropriate/inappropriate for will surely come up. So, I thought it might be worthwhile for us to start considering this (and thought that I might find out if anyone is using wave yet). My own opinion would be that wave conversations should not be used for any of the functions that are currently being handled on public lists. I think that it may be acceptable for waves to be used for functions that are currently handled on private lists - as long as the final conversation was captured and posted to the private list for archiving purposes. But using wave as a replacement for IRC would probably be unacceptable (unless someone developed an IRC gadget) because people have to be invited to the conversion (and can be excluded from parts of it). Any thoughts anyone? Jay
Re: osgi trunk
I have been trying to figure out exactly what an OSGi based application server meant. And how it would be implemented by Geronimo and how it would be implemented by other server developers. It seems (please correct me if I am wrong) that we are trying to put Geronimo into an OSGi container. But, as far as I can tell, other server developers are OSGi'ifying their servers by putting an OSGi container into them. The direction that we are going seems like it will result in a superior and far more flexible server that will allow for live updating of components and all of the other good things that OSGi provides for. But, we seem to be alone in having this direction. So, I think that we may end up being trailblazers in this. Does anyone have a better understanding of what we are doing (or is my assessment basically correct)? Or, corrections to what I think the other server developers (JBoss, Glassfish, etc) are doing? Jay David Jencks wrote: I have the sandbox osgi framework working enough to start the geronimo plugins, so I'm planning to move this work into trunk so we can all pitch in more easily on getting the rest of geronimo running on osgi. There's one legal issue to take care of first, since I copied in some plexus code that is not clearly available under asl2. The code appears to have been derived from ant, so I'm going to see if we can get the same results by importing or using ant code. I think that Donald is planning to make a branch off of trunk for a convenient place to try out jpa2 stuff at least until we have the equivalent working under osgi. If you have any concerns about this please speak up! thanks david jencks
Re: Could not build Geronimo server from SVN branch 2.2
Hello,
It looks like the automated build has been failing since 11/7 on that
artifact (com.envoisolutions.sxc).
So - I think that it has somehow become corrupted in the maven
repositories. If anyone had a local version that was 'good', then they
would be able to build 2.2.
If they were starting from scratch (like yourself) or cleared their
local repo - then they would start getting errors.
We will try to see if we can find a good copy of the artifacts (or to
have a good copy reloaded into the repos).
Sorry for the trouble. Hopefully, we will be able to get things
straightened out soon (for you and us as well).
Jay
Fei LI wrote:
Hi,
Another failed day to build Geronimo server from SVN branch 2.2.
My OS is Windows XP.
Today I tried:
Jsdk 1.6.0_16
Jsdk 1.5.0_22
Maven 2.2.1
Maven 2.0.10
Donald woods helped me to try shorter folder like c:\g22; c:\m2repo, did
not work.
He also asked me to delete some troubled files and did not work too.
So far, I tried 2.1.4, 2.2 and trunk and no one works.
Anybody ever clean your repo and build from nothing just kie me? Try!
Please!!! Tell me how to build then.
Thanks
Fei Li
See my error:
[INFO] [enforcer:enforce {execution: default}]
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[INFO] [plugin:descriptor]
[INFO] Using 'UTF-8' encoding to read mojo metadata.
[INFO] Applying mojo extractor for language: java
[WARNING] org.apache.geronimo.mavenplugins.car.ArchiveCarMojo#jarArchiver:
[WARNING] The syntax
[WARNING] @parameter expression=${component.role#roleHint}
[WARNING] is deprecated, please use
[WARNING] @component role=role roleHint=roleHint
[WARNING] instead.
[INFO] Mojo extractor for language: java found 10 mojo descriptors.
[INFO] Applying mojo extractor for language: bsh
[INFO] Mojo extractor for language: bsh found 0 mojo descriptors.
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[INFO] [remote-resources:process {execution: default}]
[WARNING] Attempting to build MavenProject instance for Artifact
(com.envoisolutions.sxc:sxc-runtime:0.7.2) of type: jar; constructing
POM artifact instead.
[WARNING] Invalid project model for artifact
[sxc-runtime:com.envoisolutions.sxc:0.7.2]. It will be ignored by the
remote resources Mojo.
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
C:\g22\framework\buildsupport\car-maven-plugin\src\main\filtered-resources
[INFO] Copying 3 resources
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[INFO] [compiler:compile]
[INFO] Compiling 20 source files to
C:\g22\framework\buildsupport\car-maven-plugin\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
error: error reading
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.jar;
error in opening zip file
error: error reading
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.jar;
error in opening zip file
Re: Could not build Geronimo server from SVN branch 2.2
Here is what they problem is - they moved that artifact.
In its place is the following html file (rather than a pom)
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title301 Moved Permanently/title
/headbody
h1Moved Permanently/h1
pThe document has moved a
href=http://download.java.net/maven/1/com.envoisolutions.sxc/poms/sxc-runtime-0.7.2.pom;here/a./p
hr
addressApache Server at maven-repository.dev.java.net Port 443/address
/body/html
So that is why it isn't working anymore.
Jay
Jay D. McHugh wrote:
Hello,
It looks like the automated build has been failing since 11/7 on that
artifact (com.envoisolutions.sxc).
So - I think that it has somehow become corrupted in the maven
repositories. If anyone had a local version that was 'good', then they
would be able to build 2.2.
If they were starting from scratch (like yourself) or cleared their
local repo - then they would start getting errors.
We will try to see if we can find a good copy of the artifacts (or to
have a good copy reloaded into the repos).
Sorry for the trouble. Hopefully, we will be able to get things
straightened out soon (for you and us as well).
Jay
Fei LI wrote:
Hi,
Another failed day to build Geronimo server from SVN branch 2.2.
My OS is Windows XP.
Today I tried:
Jsdk 1.6.0_16
Jsdk 1.5.0_22
Maven 2.2.1
Maven 2.0.10
Donald woods helped me to try shorter folder like c:\g22; c:\m2repo, did
not work.
He also asked me to delete some troubled files and did not work too.
So far, I tried 2.1.4, 2.2 and trunk and no one works.
Anybody ever clean your repo and build from nothing just kie me? Try!
Please!!! Tell me how to build then.
Thanks
Fei Li
See my error:
[INFO] [enforcer:enforce {execution: default}]
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[INFO] [plugin:descriptor]
[INFO] Using 'UTF-8' encoding to read mojo metadata.
[INFO] Applying mojo extractor for language: java
[WARNING] org.apache.geronimo.mavenplugins.car.ArchiveCarMojo#jarArchiver:
[WARNING] The syntax
[WARNING] @parameter expression=${component.role#roleHint}
[WARNING] is deprecated, please use
[WARNING] @component role=role roleHint=roleHint
[WARNING] instead.
[INFO] Mojo extractor for language: java found 10 mojo descriptors.
[INFO] Applying mojo extractor for language: bsh
[INFO] Mojo extractor for language: bsh found 0 mojo descriptors.
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[INFO] [remote-resources:process {execution: default}]
[WARNING] Attempting to build MavenProject instance for Artifact
(com.envoisolutions.sxc:sxc-runtime:0.7.2) of type: jar; constructing
POM artifact instead.
[WARNING] Invalid project model for artifact
[sxc-runtime:com.envoisolutions.sxc:0.7.2]. It will be ignored by the
remote resources Mojo.
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
C:\g22\framework\buildsupport\car-maven-plugin\src\main\filtered-resources
[INFO] Copying 3 resources
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[WARNING] POM for 'com.envoisolutions.sxc:sxc-runtime:pom:0.7.2:compile'
is invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for p
roject com.envoisolutions.sxc:sxc-runtime at
C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.pom
[INFO] [compiler:compile]
[INFO] Compiling 20 source files to
C:\g22\framework\buildsupport\car-maven-plugin\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO
Re: Geronimo Blog
I would like access too. id: jaydm email: jaydm (at) apache (dot) org Thanks, Jay Kevan Miller wrote: All, A new Geronimo community blog has been created at http://blogs.apache.org/geronimo/ If you'd like the ability to post to the blog, reply to this email. At the moment, access is limited to Geronimo committers. If this policy changes, I'll let everyone know... --kevan
Re: October Board report
Last chance everyone, The board report needs to be sent in by Monday. So, if there is anything notable that was missed - please add it! Thanks, Jay Jay D. McHugh wrote: Hello again everyone, I have made a couple of additional changes to the report. Please take a look (especially to the sections on the sandbox and specifications) to make sure I haven't said anything that isn't correct. And remember - the changes should really be made before the 16th. So make your changes/additions soon. Thanks, Jay Jay D. McHugh wrote: Hello all, Every three months I resolve that I should keep a running tally of the important events in Geronimo so that it will be easier to make the quarterly reports. I'm still making the same resolution. But, here is a start to the report for October. There are a few items that are not yet resolved: Will there be a 2.2 release this quarter? Will the Blueprint sandbox get contributed to Aries? etc... So not everything can be nailed down now. But if there are any areas that are completely missing, please add them. http://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2009-10+-+October Thanks, Jay
Re: October Board report
Hello again everyone, I have made a couple of additional changes to the report. Please take a look (especially to the sections on the sandbox and specifications) to make sure I haven't said anything that isn't correct. And remember - the changes should really be made before the 16th. So make your changes/additions soon. Thanks, Jay Jay D. McHugh wrote: Hello all, Every three months I resolve that I should keep a running tally of the important events in Geronimo so that it will be easier to make the quarterly reports. I'm still making the same resolution. But, here is a start to the report for October. There are a few items that are not yet resolved: Will there be a 2.2 release this quarter? Will the Blueprint sandbox get contributed to Aries? etc... So not everything can be nailed down now. But if there are any areas that are completely missing, please add them. http://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2009-10+-+October Thanks, Jay
[jira] Commented: (GERONIMO-3832) Timers created using the Timer Services are not dropeed when the associated ejb module is stopped or undeployed.
[ https://issues.apache.org/jira/browse/GERONIMO-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761715#action_12761715 ] Jay D. McHugh commented on GERONIMO-3832: - Antonio - Could you please double check that this is still a problem on either 2.1.4 or trunk (or both)? I would suspect that it was quietly fixed without updating this ticket. Timers created using the Timer Services are not dropeed when the associated ejb module is stopped or undeployed. Key: GERONIMO-3832 URL: https://issues.apache.org/jira/browse/GERONIMO-3832 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0.2, 2.1.1 Environment: windows 2000, jdk 1.5.0 Reporter: Antonio Muñoz Priority: Minor When a periodic timer is scheduled using the geronimo timer service, the ejbtimeout method is called properly every time the period is reached. The problems comes when our ejb module is stopped or undeployed because the ejbtimeout is tried to be called again and again every time the period is reached even when the ejb module is already stopped. The logical solution should be stopping every timer associated to the ejb module is being stopped or undeployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4901) Shutting down Geronimo destroys pending Timers
Shutting down Geronimo destroys pending Timers -- Key: GERONIMO-4901 URL: https://issues.apache.org/jira/browse/GERONIMO-4901 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Environment: Geronimo 2.1.4 Reporter: Jay D. McHugh Here is what SEEMS to be happening: Shutting down and bringing Geronimo back up seems to be effectively undeploying everything, then redeploying it. So, pending Timers are being destroyed. This may not be the actual cause of this - Based upon the log entries during shutdown and restart. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4901) Shutting down Geronimo destroys pending Timers
[ https://issues.apache.org/jira/browse/GERONIMO-4901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761772#action_12761772 ] Jay D. McHugh commented on GERONIMO-4901: - Here is a portion of the geronimo.log file that seems to show my app being disassembled during shutdown and reconstituted during startup: (Using current 2.1.5 snapshot as of 10/02/2009) During shutdown: 2009-10-02 18:01:56,810 INFO [startup] Undeploying app: /opt/geronimo-tomcat6-javaee5-2.1.5-SNAPSHOT/var/temp/geronimo-deploymentUtil4824243862298920212.jar 2009-10-02 18:01:56,835 INFO [startup] Undeploying app: /opt/geronimo-tomcat6-javaee5-2.1.5-SNAPSHOT/var/temp/geronimo-deploymentUtil1436047464632244742.jar 2009-10-02 18:02:02,120 INFO [startup] Undeploying app: /usr/src/mavenRepository/org/apache/geronimo/plugins/geronimo-mejb/2.1.5-SNAPSHOT/geronimo-mejb-2.1.5-SNAPSHOT.jar 2009-10-02 18:02:02,163 INFO [remote] Received stop signal While coming back up - after starting all of the Geronimo services: 2009-10-02 18:10:54,602 INFO [startup] Assembling app: /opt/geronimo-tomcat6-javaee5-2.1.5-SNAPSHOT/var/temp/geronimo-deploymentUtil4824243862298920212.jar 2009-10-02 18:10:58,546 INFO [startup] Jndi(name=ComponentClassBeanLocal) -- Ejb(deployment-id=palmBeans.jar/ComponentClassBean) 2009-10-02 18:10:58,547 INFO [startup] Jndi(name=VClean7Local) -- Ejb(deployment-id=palmBeans.jar/VClean7) 2009-10-02 18:10:58,547 INFO [startup] Jndi(name=GenericComponentBeanLocal) -- Ejb(deployment-id=palmBeans.jar/GenericComponentBean) 2009-10-02 18:10:58,547 INFO [startup] Jndi(name=VClean2Local) -- Ejb(deployment-id=palmBeans.jar/VClean2) 2009-10-02 18:10:58,547 INFO [startup] Jndi(name=ESDBeanLocal) -- Ejb(deployment-id=palmBeans.jar/ESDBean) .. Shutting down Geronimo destroys pending Timers -- Key: GERONIMO-4901 URL: https://issues.apache.org/jira/browse/GERONIMO-4901 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Environment: Geronimo 2.1.4 Reporter: Jay D. McHugh Here is what SEEMS to be happening: Shutting down and bringing Geronimo back up seems to be effectively undeploying everything, then redeploying it. So, pending Timers are being destroyed. This may not be the actual cause of this - Based upon the log entries during shutdown and restart. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Donate blueprint to Aries podling (2nd try)
+1 Jay Guillaume Nodet wrote: The Aries podling has just been accepted (see http://incubator.apache.org/aries/) and would be a much better place for the blueprint implementation that has been developped in Geronimo. This vote is mainly for donating the code to the Aries project and maintain it there. [ ] +1 Donate the blueprint implementation to Aries [ ] -1 Do not The vote will be opened for 72 hours. Here's my +1
October Board report
Hello all, Every three months I resolve that I should keep a running tally of the important events in Geronimo so that it will be easier to make the quarterly reports. I'm still making the same resolution. But, here is a start to the report for October. There are a few items that are not yet resolved: Will there be a 2.2 release this quarter? Will the Blueprint sandbox get contributed to Aries? etc... So not everything can be nailed down now. But if there are any areas that are completely missing, please add them. http://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2009-10+-+October Thanks, Jay
Re: [DISCUSS] Donate Blueprint implementation to Aries podling
Makes sense to me too. Jay Guillaume Nodet wrote: Some time ago, a few Geronimo committers have started an implementation of the OSGi Blueprint Services spec, which is basically an OSGi standardized version of Spring-DM (the next version of Spring-DM being the RI of this spec). The code was developed at Geronimo mostly because the people that were interested in doing so were all Geronimo committers, so it was way easier to set that up inside Geronimo. However, the piece of code does not really fit well in Geronimo, as it has nothing to do with JEE. A few days ago, a podling named Aries has been proposed to the incubator. You'll find the proposal at http://wiki.apache.org/incubator/AriesProposal. Aries would be a much more natural home for the blueprint code currently in Geronimo. Thoughts / questions / remarks ?
Re: OSGI progress
So it sounds like I can't put off learning OSGi anymore :) Does anyone have suggested resources (books, websites, or tutorials) that they found useful? Thanks in advance, Jay David Jencks wrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks
Re: Welcome Delos Xuan Dai as a new committer
Congratulations! Jay Kevan Miller wrote: On Jul 20, 2009, at 11:42 AM, Donald Woods wrote: I would like to welcome Delos aboard, as he recently accepted the Geronimo PMC invitation to become a committer. His account was created last week (delos), so you should start seeing some commits from him as soon as we finish granting him karma. Congrats Delos! You should be all set, karma-wise. Look forward to your contributions! --kevan
Re: [Discuss] ApacheCon '09 Geronimo Track: Content
This sounds like a good mix to me. And, even though the agenda for #1 doesn't 'officially' include all of the new features in 2.2 - that doesn't mean that questions couldn't be taken and answered later. If we ran through a list of the new features at the beginning of the session, then that could pique peoples interest to follow up later. Jay Kevan Miller wrote: On Jul 22, 2009, at 6:58 PM, David Jencks wrote: I think this is a good division of topics. I wonder if it would be more interesting to cover the various clustering stuff we have in 2.2 rather than the security stuff. I've talked about security a couple of times before and it has a little bit of documentation but I don't think anyone has ever pulled together all the clustering stuff... wadi jetty/tomcat/ejb ejb client failover farm management how to set up a web load balancer. I'm good with that. Session 1: Apache Geronimo 2.2 Speakers: David Jencks and Vamsavardhana Reddy Chillakuru This talk will provide an overview of the Geronimo 2.2 release. Along with providing an overview of the new features found in 2.2, the talk will also discuss Geronimo Custom Assemblies and Application Security. Geronimo makes it easy to assemble a custom server around your applications, including only those features needed to run your apps. We'll see how to use maven to integrate this into your build process. This session will also discuss the clustering options available with Geronimo and configuring load-balancing and failover of web applications using mod_jk Apache HTTP Server. After completing this session, the audience will be familiar with the clustering and farming features provided by Geronimo, running multiple instances of Geronimo server from the same installation, preparing their applications for deployment on the cluster and know how to configure Geronimo clusters to suit their needs. Session 2: OSGi Blueprint Container Specification and Geronimo Speaker: Jarek Gawor This talk will provide a general overview of the Blueprint Container Specification and demonstrate some of its core features using Geronimo's Blueprint Container implementation. The talk will also describe some more advanced features of the Geronimo implementation such as Configuration Admin Service support and custom namespace handlers. Future plans will be discussed as well as how the Blueprint Container might be used and integrated within the existing Geronimo Kernel. Session 3: Apache Geronimo 3.0: OSGi and Java EE6 Speakers: David Jencks and Donald Woods This talk will provide a preview of the new features in Apache Geronimo 3.0. Including the OSGi support with the Geronimo kernel. We'll also discuss the new Java EE 6 features: Web Profiles, JPA 2.0, Servlet 3.0, EJB 3.1, etc. We'll also include demonstration of current functionality and discuss development outlook. --kevan
[jira] Commented: (GERONIMO-4723) Replace our dojo repackaging with the released dojo-war
[ https://issues.apache.org/jira/browse/GERONIMO-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12730511#action_12730511 ] Jay D. McHugh commented on GERONIMO-4723: - (I accidentally put the wrong Jira number in the commit comment) Sendingplugins/dojo/dojo-jetty/pom.xml Sendingplugins/dojo/dojo-jetty/src/main/history/dependencies.xml Sendingplugins/dojo/dojo-tomcat/pom.xml Sendingplugins/dojo/dojo-tomcat/src/main/history/dependencies.xml Sendingplugins/dojo/pom.xml Transmitting file data . Committed revision 793687. Replace our dojo repackaging with the released dojo-war --- Key: GERONIMO-4723 URL: https://issues.apache.org/jira/browse/GERONIMO-4723 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: web Affects Versions: 2.2 Reporter: David Jencks Attachments: GERONIMO-2723.patch dojo has a dojo-war that looks pretty similar to our repacked dojo war. I can't quite tell if it works. Maybe someone who understands what dojo does could try it? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Which dojo?
Hey David, I'm starting to take a look at it today. They have a 1.3.1 version out - any objections to me switching the patch to use it? Jay David Jencks wrote: On Jul 1, 2009, at 10:18 PM, Rex Wang wrote: Yep, the current portlet dev is really complicated, but there will be a huge work to do if we decide to switch pluto to other framework like JSF... not sure how much for Pluto2. And I think we don't have enough time for the migration before G2.2 release.. I agree. But we need to fix the private repo issue now. is anyone looking at my patch or my patch updated to the latest dojo release? Since I don't see problems I'm tempted to apply it. Then we can try to figure out something for the 0.4.3 legacy dojo. thanks david jencks -Rex 2009/7/2 David Jencks david_jen...@yahoo.com mailto:david_jen...@yahoo.com If we're going to rewrite bits of the portal, we should consider moving to pluto 2. IIUC there are a bunch of features in portlet 2 spec that may make our portlets simpler. I also think we should investigate frameworks such as jsf or even wicket or something because the current portlet code is ridiculously complicated for what it does. There must be a more sensible way to write a web app. thanks david jencks On Jul 1, 2009, at 9:41 AM, Joseph Leong wrote: So unfortunately what happened between Dojo 0.4.3- Mostly anything newer especially 1.3.1 is that they had the idea to classify their libraries to Dijit (Widgets) and other subsections. As such, the porting effort is not small. I believe the debug-views portlets and such still depend on 0.4.3. At this point in time, my opinion would be to not try and migrate any 0.4.3 dependent code. There has been so much change between the dojo versions that it would be probably simpler and cleaner to just rewrite these portlets. I think it'd be a good choice to get rid of the old Dojo libraries once and for all as they add a bit to the geronimo footprint size.. not to mention there are a lot more features in the latest Dojo release that can probably accomplish what you wanted to in the older versions. Thanks, Joseph Leong On Wed, Jul 1, 2009 at 12:10 PM, David Jencks david_jen...@yahoo.com mailto:david_jen...@yahoo.com wrote: On Jul 1, 2009, at 1:14 AM, Ivan wrote: I think the one is what need, no samples and testcases are included. But I found 1.3.1 is released, why not use the newest one ? Newer would be better if we can get it to work. I set this up a few days ago and forgot the details... I think that I saw some problem and wasn't sure what was causing it and tried changing to an earlier dojo version. I didn't actually have any reason to think the problem was caused by dojo so very likely the more recent release should work. And for the legacy dojo 0.4.3, how shall we handle it ? Like tomcat, maitaine a our own repo ? Ideally I think we would migrate our code to up-to-date dojo. Unfortunately I have no idea how hard that would be. Does anyone? If we can't, I think there is some release of some 0.4.3 dojo, perhaps we can investigate using or repackaging it. There's also dwr but I think working on one dependency at a time will be less confusing. thanks david jencks 2009/7/1 David Jencks david_jen...@yahoo.com mailto:david_jen...@yahoo.com In my attempt to remove our svn repo I found that dojo releases a dojo-war that looks pretty similar to our repacked dojo war. I can make the build work with the substitution but I don't know enough about dojo to know if/what it breaks. Is there anyone who understands our use of dojo well enough to take a look and see if this replacement is plausible? I recall some discussion in the distant past about not including all of dojo... I'm not sure if this is still a concern, but if the released dojo-war works and is too big we can use maven to come up with a smaller war. See https://issues.apache.org/jira/browse/GERONIMO-4723 for my patch. thanks david jencks -- Ivan
Re: [VOTE] genesis 2.0 and geronimo-jaspic_1.0_spec 1.0
+1 Jay David Jencks wrote: This is a vote on two bits: genesis 2.0, a new build system foundation based on great work by Jason Dillon and the new apache 6 pom and assembly plugin bits. geronimo-jaspic_1.0_spec 1.0 a new spec jar for the jsr 196 jaspic spec. This passes the jaspic signature test and with appropriate bits of jetty 7 passes the shared and servlet profile of the jaspic tck. The jar type stuff is staged at https://repository.apache.org/content/repositories/geronimo-staging-009/ In particular the source archives (which this vote is actually on) are at https://repository.apache.org/content/repositories/geronimo-staging-009/org/apache/geronimo/genesis/genesis/2.0/genesis-2.0-source-release.tar.gz https://repository.apache.org/content/repositories/geronimo-staging-009/org/apache/geronimo/genesis/genesis/2.0/genesis-2.0-source-release.zip and https://repository.apache.org/content/repositories/geronimo-staging-009/org/apache/geronimo/specs/geronimo-jaspic_1.0_spec/1.0/geronimo-jaspic_1.0_spec-1.0-source-release.tar.gz https://repository.apache.org/content/repositories/geronimo-staging-009/org/apache/geronimo/specs/geronimo-jaspic_1.0_spec/1.0/geronimo-jaspic_1.0_spec-1.0-source-release.zip with the signatures in the obvious place next to them. The sites are staged at http://people.apache.org/~djencks/staging-site/ in particular http://people.apache.org/~djencks/staging-site/maven/genesis/2.0/ http://people.apache.org/~djencks/staging-site/maven/specs/geronimo-jaspic_1.0_spec/1.0/ the jar type stuff is using the new apache nexus instance which works great! [ ] +1 About time, yes yes yes [ ] 0 Apathy [ ] -1 No thanks because Please vote! Thanks to Jason Dillon for setting up most of the new genesis 2.0 system and to Brian Fox for getting the nexus setup working for us! thanks david jencks
[jira] Commented: (GERONIMO-4130) Unable to preserve comments from plan.xml into config.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715948#action_12715948 ] Jay D. McHugh commented on GERONIMO-4130: - I just checked 2.1.5 to see if the comment function was still working. And it is. Is it not working in 2.2? The way to put in comments is to wrap them in a comment element. example commentThis will be preserved/comment You should be able to add a comment element at any level of the config. Unable to preserve comments from plan.xml into config.xml - Key: GERONIMO-4130 URL: https://issues.apache.org/jira/browse/GERONIMO-4130 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: car-maven-plugin Affects Versions: 2.1.x, 2.2 Reporter: Lin Sun Fix For: Wish List I got a user asking me how to turn off tomcat access log. It was easy in previous releases, as we could provide comment in config.xml and tell the users to To disable accesslogging uncomment the following section However, with our new config.xml, we don't preserve any comments, which makes hard for users to config things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Release Geronimo Server 2.1.4 RC1
I was hoping that most people would be leaning that way. Jay Joe Bohn wrote: Thanks Jay for continuing to test the release and dig into this issue. My comments are inline with Donalds. I would recommend pursuing the specifics more with the OpenJPA team. For Geronimo 2.1.4 I think we need to ship this as is (assuming tck continues to pass) and possibly pull a new OpenJPA into a 2.1.5 release. Joe Jay D. McHugh wrote: Hey again all, I think that this may caused by my rather extreme entity relationships and the use of OpenJPA's proprietary @ElementJoinColumn annotation. I have the following relationship structure: project - projectDetail (project 1-M projectDetail using @EJC) - component (projectDetail 1-1 component) - componentAttribute (component 1-M componentAttribute using @EJC) - attribute (componentAttribute 1-1 attribute) - compAttribValue (componentAttribute 1-1 compAttribValue) - componentClass (component 1-1 componentClass) - classAttrib (componentClass 1-M classAttrib using @EJC) - attribute (classAttrib 1- attribute) And I am basically trying to clone a project entity. I have debugging code that says it is creating and attaching all of the necessary details (which it is) containing the appropriate components (which it is not). I am only getting the first projectDetail persisted to the database fully. All subsequent are not getting their components created. I will try to create a test that has a similarly complicated entity relationship but uses only JPA standard links. If that works - how should we handle it? If the assembly passes TCK, and the problem is only related to the use of an OpenJPA proprietary annotation, should we just issue a note that the use of that annotation may cause problems? Jay Joe Bohn wrote: Hi Jay, Yes, please do let us know. I'm nearly done generating a new set of images and will start the vote again shortly. However, as the previous comments indicate, the images themselves are not functionally different than what you are using ... just adding in a missing license header and removing some unnecessary text in the README.txt file. Thanks, Joe Jay D. McHugh wrote: Hey all, I know that this vote is cancelled, but I tried my real app on 2.1.4 RC1 and some JPA entities are not working the way they used to on 2.1.3. I am trying to figure out if I have been taking advantage of a bug that has since been corrected - or if a problem snuck into JPA. I will let you all know as soon as I figure out which is the case. Jay Joe Bohn wrote: Message created for any discussion of the pending Geronimo 2.1.4 RC1 currently up for vote. Thanks, Joe
Re: [VOTE] Release Geronimo Server 2.1.4 RC2
+1 Jay Joe Bohn wrote: All, I've prepared a second release candidate (RC2) of Geronimo Server 2.1.4 for your review and vote. The only differences from rc1 are: - addition of a missing license header in plugins/console/console-filter/src/main/resources/XSRF.js - removal of an extraneous (TBD) in README.txt The source for rc2 is Rev758842 from the following svn branch: https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.4/ When the release vote is approved, I will svn mv the code to: https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.4/ An archive of this source code can be found here: http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-2.1.4-src.tar.gz OR http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-2.1.4-src.zip http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/ contains the 10 server binary distributions to be released (framework, tomcat/jetty, Java EE/Minimal, tar/zip) as well as the RELEASE_NOTES, README, NOTICE, LICENSE, DISCLAIMER, and source code archives for the release. These extra txt files were included so that they could be leveraged by GEP if necessary (they are also included in the assembly images). For your convenience, here are pointers to the urls for the distributions in zip format: http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-jetty6-javaee5-2.1.4-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-jetty6-minimal-2.1.4-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-tomcat6-javaee5-2.1.4-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-tomcat6-minimal-2.1.4-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-framework-2.1.4-bin.zip The maven artifacts for the release can be found here: http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.4-rc2/ When the release vote is approved, these maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. [ ] +1 Release Geronimo Server 2.1.4 [ ] 0 No opinion [ ] -1 Do not release Geronimo Server 2.1.4 (please provide rationale) The voting will be open for 72 hours or until sufficient input has been received and the tck results have been verified. Thanks, Joe
Re: [DISCUSS] Release Geronimo Server 2.1.4 RC1
I tried to create a simplified test case. But it worked like a charm - So, I must have been taking advantage of a bug that has been corrected. I will try to sort out my entity relations to figure out what I am doing wrong. Jay Donald Woods wrote: If you can create a stand-alone junit testcase that recreates the problem, then you can open a issue against OpenJPA 1.2.1 in their JIRA - https://issues.apache.org/jira/browse/OPENJPA Given this level passed the Geronimo JEE5 TCK runs and the OpenJPA team's own internal testing, I would be against holding up the Geronimo 2.1.4 release for another OpenJPA release, as we need to get this release out ASAP for some other included fixes. -Donald Jay D. McHugh wrote: Hey again all, I think that this may caused by my rather extreme entity relationships and the use of OpenJPA's proprietary @ElementJoinColumn annotation. I have the following relationship structure: project - projectDetail (project 1-M projectDetail using @EJC) - component (projectDetail 1-1 component) - componentAttribute (component 1-M componentAttribute using @EJC) - attribute (componentAttribute 1-1 attribute) - compAttribValue (componentAttribute 1-1 compAttribValue) - componentClass (component 1-1 componentClass) - classAttrib (componentClass 1-M classAttrib using @EJC) - attribute (classAttrib 1- attribute) And I am basically trying to clone a project entity. I have debugging code that says it is creating and attaching all of the necessary details (which it is) containing the appropriate components (which it is not). I am only getting the first projectDetail persisted to the database fully. All subsequent are not getting their components created. I will try to create a test that has a similarly complicated entity relationship but uses only JPA standard links. If that works - how should we handle it? If the assembly passes TCK, and the problem is only related to the use of an OpenJPA proprietary annotation, should we just issue a note that the use of that annotation may cause problems? Jay Joe Bohn wrote: Hi Jay, Yes, please do let us know. I'm nearly done generating a new set of images and will start the vote again shortly. However, as the previous comments indicate, the images themselves are not functionally different than what you are using ... just adding in a missing license header and removing some unnecessary text in the README.txt file. Thanks, Joe Jay D. McHugh wrote: Hey all, I know that this vote is cancelled, but I tried my real app on 2.1.4 RC1 and some JPA entities are not working the way they used to on 2.1.3. I am trying to figure out if I have been taking advantage of a bug that has since been corrected - or if a problem snuck into JPA. I will let you all know as soon as I figure out which is the case. Jay Joe Bohn wrote: Message created for any discussion of the pending Geronimo 2.1.4 RC1 currently up for vote. Thanks, Joe
Re: [DISCUSS] Release Geronimo Server 2.1.4 RC1
Hey all, I know that this vote is cancelled, but I tried my real app on 2.1.4 RC1 and some JPA entities are not working the way they used to on 2.1.3. I am trying to figure out if I have been taking advantage of a bug that has since been corrected - or if a problem snuck into JPA. I will let you all know as soon as I figure out which is the case. Jay Joe Bohn wrote: Message created for any discussion of the pending Geronimo 2.1.4 RC1 currently up for vote. Thanks, Joe
Re: [DISCUSS] Release Geronimo Server 2.1.4 RC1
Hey again all, I think that this may caused by my rather extreme entity relationships and the use of OpenJPA's proprietary @ElementJoinColumn annotation. I have the following relationship structure: project - projectDetail (project 1-M projectDetail using @EJC) - component (projectDetail 1-1 component) - componentAttribute (component 1-M componentAttribute using @EJC) - attribute (componentAttribute 1-1 attribute) - compAttribValue (componentAttribute 1-1 compAttribValue) - componentClass (component 1-1 componentClass) - classAttrib (componentClass 1-M classAttrib using @EJC) - attribute (classAttrib 1- attribute) And I am basically trying to clone a project entity. I have debugging code that says it is creating and attaching all of the necessary details (which it is) containing the appropriate components (which it is not). I am only getting the first projectDetail persisted to the database fully. All subsequent are not getting their components created. I will try to create a test that has a similarly complicated entity relationship but uses only JPA standard links. If that works - how should we handle it? If the assembly passes TCK, and the problem is only related to the use of an OpenJPA proprietary annotation, should we just issue a note that the use of that annotation may cause problems? Jay Joe Bohn wrote: Hi Jay, Yes, please do let us know. I'm nearly done generating a new set of images and will start the vote again shortly. However, as the previous comments indicate, the images themselves are not functionally different than what you are using ... just adding in a missing license header and removing some unnecessary text in the README.txt file. Thanks, Joe Jay D. McHugh wrote: Hey all, I know that this vote is cancelled, but I tried my real app on 2.1.4 RC1 and some JPA entities are not working the way they used to on 2.1.3. I am trying to figure out if I have been taking advantage of a bug that has since been corrected - or if a problem snuck into JPA. I will let you all know as soon as I figure out which is the case. Jay Joe Bohn wrote: Message created for any discussion of the pending Geronimo 2.1.4 RC1 currently up for vote. Thanks, Joe
Re: Welcome ivan Hai Hong Xu as a new committer
Congratulations! Jay Donald Woods wrote: I would like to welcome Ivan aboard, as he recently accepted the Geronimo PMC invitation to become a committer. His account was just created this morning (xuhaihong), so you should start seeing some commits from him soon. -Donald
Re: [VOTE] Release Geronimo txmanager version 2.1.2
+1 Jay Lin Sun wrote: Hi, This is a vote for the geronimo txmanager version 2.1.2 release. The following changes are included for the txmanager 2.1.2 release: GERONIMO-4393 - Duplicate Xid with multiple JVMs on single host - default impl needs some 'random' entropy GERONIMO-4438 - TransactionSynchronizationRegistry.getTransactionKey should return null when transaction is not associated with the current thread GERONIMO-4448 - TransactionManager resume method should only resume valid transaction GERONIMO-4461 - Improve exception during transaction manager one phase commit GERONIMO-4466 - Improve exception during transaction manager commit when there are multiple XAResources GERONIMO-4471 - improve heuristic exception handling in rollback when txmanager.commit is called GERONIMO-4449 - Transaction.rollback method also calls beforeCompletion GERONIMO-4478 - enhance exception handling during transaction rollback GERONIMO-4482 - a few improvements on XAExceptions during enlist resource, prepare, commit, rollback update to use slf4j license/notice update Staging repo: http://people.apache.org/~linsun/staging-repo/txmanager/ Staging site: http://people.apache.org/~linsun/staging-repo/txmanager/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks Lin
Re: [VOTE] Release javamail spec (1.6) and javamail provider (1.7)
+1 Jay Joe Bohn wrote: This is a vote for a combined release of the javamail spec and the javamail provider (+ the uber jar). The provider changes have dependencies on the spec changes, so these need to be released at the same time. Geronimo will need the updated uber jar for the Geronimo 2.1.4 and 2.2 releases. The components up for release are: geronimo-javamail_1.4_spec-1.6 geronimo-javamail_1.4-1.7 geronimo-javamail_1.4_provider-1.7 geronimo-javamail_1.4_mail-1.7(uber jar containing spec+providers) The following changes are included for the javamail spec: - GERONIMO-4307 Base64DecoderStream return int value between -128 and +127, should be between +0 and +255 - GERONIMO-4339 Calling MimeMessage#setRecipients with empty array causes ArrayOutOfBoundsException Patch provided by Andreas Velthen - GERONIMO-4340 MimePartDataSource incorrectly assumes that MimeMessages are never transfer encoded - GERONIMO-4341 javax.mail.NoSuchProviderException: Unable to locate provider for protocol: pop3 - GERONIMO-4342 MimeMessage#writeTo doesn't flush the encoder stream - Parse content types with parameters containing escaped characters. (GERONIMO-4421) The following changes are included for the javamail provider: - GERONIMO-4290 pop3s: java.lang.IllegalArgumentException: hostname can't be null - GERONIMO-4294 mail.pop3s.socketFactory.class is ignored - GERONIMO-4341 javax.mail.NoSuchProviderException: Unable to locate provider for protocol: pop3 - GERONIMO-4344 IMAPMessage#updateHeader updates header with wrong value - GERONIMO-4372 Wrong DEFAULT_IMAP_PORT in the Geronimo JavaMail 1.4 provider - fixed transport class name for smtps (GERONIMO-4476) - Can't read anything in if input is not set - tie down maven-shade-plugin version - IMAPMessage loadContent() and writeTo() fixes. Test code based on patch from Andreas Veithen (GERONIMO-4352) - added tests for pop3 store - same as for imap - add LICENSE and NOTICE files - update spec version in preparation for release Staging repos: http://people.apache.org/~jbohn/staging-repo/specs/geronimo-javamail_1.4_spec/ http://people.apache.org/~jbohn/staging-repo/javamail/ The svn locations are here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.4_spec-1.6 https://svn.apache.org/repos/asf/geronimo/javamail/tags/geronimo-javamail_1.4-1.7 Staging sites: http://people.apache.org/~jbohn/staging-site/specs/geronimo-javamail_1.4_spec/1.6/ http://people.apache.org/~jbohn/staging-site/javamail/1.7/ The vote is open for 72 hours and or until sufficient votes are received [ ] +1 Release the javamail spec and provider [ ] +0 No opinion [ ] -1 Don't release the javamail spec and provider Thanks, Joe
Re: [VOTE] Release gshell 1.0-alpha2
+1 Jay Guillaume Nodet wrote: I've uploaded a release of gshell 1.0-alpha2. The staging repo is available at: http://people.apache.org/~gnodet/staging/gshell-1.0-alpha2 The svn tag is: https://svn.apache.org/repos/asf/geronimo/gshell/tags/gshell-1.0-alpha-2/ Please review and vote ! [ ] +1 Release gshell-1.0-alpha2 [ ] -1 Do not
Re: [DISCUSS] Geronimo 2.0.3 release
Hello all, I did some work on trying to get a 2.0.3 release that would: a) build - sucess! b) pass the TCK - Massive failure (over 5000 tests) So, considering that we have a 2.1.x and 2.2.x codestream in progress with JEE6 breathing down our necks - I have been officially pushed into the 'we should probably just document what it takes to upgrade' group. Are there any folks who truly need to stay on 2.0? Or would it be reasonable to make a pronouncement that the 2.0.x codestream is no longer going to be maintained - even for bug fixes and security issues? Thoughts/comments? (I'll start documenting the libraries/jars that have changed or been removed - we will need that regardless) Jay Joe Bohn wrote: I guess I should resolve this discussion on if we should release 2.0.3 that I started. Thank you both Jay and Donald for your responses. I'm not completely opposed to a 2.0.3 release. I was just wondering aloud if it was the best use of our resources and if it conveyed the right message to our users. I was also wondering a little if it might create more problems for our users than it solves. You know the drill ... upgrade from one maintenance release to another only to discover yet another issue that then forces you to a new version like 2.1.* because it isn't resolved in the current maintenance stream. If it weren't for the security issues I would see no value in a 2.0.3 release. Anyway, I am certainly not planning to stand in the way of a 2.0.3 release. I'll even do my part to validate the images and help where I can. However, my gut still tells me that we might creating more problems than we are solving. But since I'm the only one that feels that way I'm not too worried (I've been wrong plenty of times before ;-) ). It sounds like we still need to document what is necessary to move from 2.0.* to 2.1.* in any case. I guess the first step might be adding the libraries that are no longer included in 2.1.* into the list in the wiki under http://cwiki.apache.org/GMOxDOC21/what-changed-in-21.html. Does anybody have a complete list of these libraries? We'll probably still need more specific documentation to make it clear what a user might have to do when moving from 2.0.* to 2.1.*. Perhaps another page somewhere (similar to those under Migrating to Apache Geronimo)? Joe Donald Woods wrote: I think releasing 2.0.3 is in the best interest of the community, given the security fixes that it contains. It also gives us a way to announce to our users that this will be the last 2.0.x release (which we never really did for 1.1.x) and that they should start moving to 2.1.x or 2.2 for any new projects. -Donald Joe Bohn wrote: I apologize for not raising this question on the earlier thread. I'm wondering if it is a good idea to release a 2.0.3 at this point in time. We've had several releases of 2.1.x (four) and we'll hopefully release 2.2 in the not too distant future. I'm a little concerned that releasing a 2.0.3 now will just encourage people to continue on the 2.0.* base rather than taking the plunge and moving up to 2.1.*. It's been a year since we released 2.0.2 and in addition to the security fixes there have been a lot of other fixes/enhancements in the 2.1 branch. What are the big stumbling blocks that prevent a user from moving from 2.0.2 to 2.1.3 to resolve the security concerns? Rather than releasing 2.0.3, should we maybe consider a greater focus on ensuring there is a smooth migration path from 2.0.2 to 2.1.3? Once we have clearly identified any issues and ensured that we have adequate directions we could notify the user community that there will be no further 2.0.* releases and encourage them to move to 2.1.3. It might actually be easier for us to release 2.0.3 in the short term, but sooner or later users will have to address the migration issues ... so I'm just wondering if it might be a better use of our time to address those migration issues now. Joe Jay D. McHugh wrote: The 2.0.x brach got sidelined by an intermittent ConcurrentModificationException during stress testing. But, recently there were a number of security issues found that apply to 2.0.2. So, I think it's time to start the discussion for a Geronimo 2.0.3 release (It actually already was started). Server fixes/enhancements are listed on the Release Status page (work in progress)- http://cwiki.apache.org/GMOxPMGT/geronimo-203-release-status.html Details on included security fixes in dependent components are listed on the Security page - http://geronimo.apache.org/20x-security-report.html I have already begun moving issues into 2.0.4 - Does anyone have additional fixes they would like to include in 2.0.3 before we cut the branch and start the release process? If I have moved an issue that you want to work on (And you have time to work on it right away) move it back onto a 2.0.3 fix and assign it to yourself. Jay
Re: Time for Geronimo 2.1.4 release?
All of the 2.0.3 build issues are fixed. I will try building 2.0.3 with XBeans 3.5 now and let you all know what happens. If it will build, then I might take a look to see whether I can figure out what changes are necessary for OpenEJB 3.0.1 to use XBeans 3.5 too. Jay Jay D. McHugh wrote: The problem is with the version of ASM that is brought in when using a higher version of XBeans. OpenEJB is using a method that has been removed: org.objectweb.asm.ClassReader.accept And Geronimo (already - not counting XBeans 3.5) is using classes that have been removed: LinkResolver UniqueDefaultLinkResolver Jay Joe Bohn wrote: Thanks for the info Jay and for doing some more digging. I don't really have a strong desire to push everything to xBean 3.5. I was just trying to eliminate the use of multiple xBean versions as this could potentially cause problems (and confusion) for our users. It looks like we originally moved up to xBean 3.5 (actually 3.5-SNAPSHOT) to resolve a jca context issue (Geronimo-4375). However, it looks like it was soon discovered that there were issues with the OpenEJB, ASM and xBean versions in G. As a result ... we ended up reverting back to an older ASM and xBean 3.3 for finder and reflect while keeping the newer xbean-naming 3.5 so that the original issue was still resolved. That seems to be working and is perhaps the best approach. I was just concerned about using the various xBean versions in our Geronimo 2.1.4 server. Perhaps using the various xBean versions is still the best thing to do here. I didn't realize that there were core issues in OpenEJB attempting to use anything greater than 3.4.1. Thanks, Joe Jay D. McHugh wrote: Hey everyone, If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think that we'll need to chip in to resolve the problems that pop up when you use a version greater than 3.4.1. That was the highest version (available at the time) that could be used in the OpenEJB 3.0 branch without causing errors. I'll try switching to XBeans 3.5 (after the build I am in the middle of finishes) and let you all know if it goes through cleanly. My feeling is that it won't though. Also, I have been trying to get a 'final' Geronimo 2.0.x release put together and will need OpenEJB 3.0.1 for that (3.0 no longer builds because the artifacts for XBeans changed groupIds). Jay Joe Bohn wrote: I was relaying the information second-hand ... so it's very possible I got it wrong. It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can convince OpenEJB 3.0.x to xBean 3.5 we can then make the references consistent in our 2.1 branch. Thanks, Joe Donald Woods wrote: I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. Maybe you're thinking about OpenEJB? -Donald Joe Bohn wrote: I agree we should get a 2.1.4 release out ... and you certainly have my vote for release manager! The only thing I would add to the list is to get our xBean references to a consistent versions. I noticed this as I was updating branches/2.1 and trunk to pull in the newly released xBean 3.5. In branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) and 3.5 dependencies (naming). I've been told that this was due to OpenJPA dependencies on 3.3. Now that we are pulling in a new OpenJPA release we will hopefully be able to update everything to use xBean 3.5. Joe Jarek Gawor wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
Re: Time for Geronimo 2.1.4 release?
Jarek, I got spoiled by having the integration tests automatically run on 2.2. I had hoped that the tests were broken before I started - but unfortunately, it really was me that broke them. I will find and fix the problem. Thanks for alerting me to it. Jay Jarek Gawor wrote: Jay, Please run all tests including the integration tests before committing. Looks like deployment of some apps is failing after the recent changes, for example see: http://people.apache.org/builds/geronimo/server/binaries/2.0/20090204/logs-0200-tomcat/test.log Jarek On Wed, Feb 4, 2009 at 9:55 AM, Jay D. McHugh jaydmch...@gmail.com wrote: All of the 2.0.3 build issues are fixed. I will try building 2.0.3 with XBeans 3.5 now and let you all know what happens. If it will build, then I might take a look to see whether I can figure out what changes are necessary for OpenEJB 3.0.1 to use XBeans 3.5 too. Jay Jay D. McHugh wrote: The problem is with the version of ASM that is brought in when using a higher version of XBeans. OpenEJB is using a method that has been removed: org.objectweb.asm.ClassReader.accept And Geronimo (already - not counting XBeans 3.5) is using classes that have been removed: LinkResolver UniqueDefaultLinkResolver Jay Joe Bohn wrote: Thanks for the info Jay and for doing some more digging. I don't really have a strong desire to push everything to xBean 3.5. I was just trying to eliminate the use of multiple xBean versions as this could potentially cause problems (and confusion) for our users. It looks like we originally moved up to xBean 3.5 (actually 3.5-SNAPSHOT) to resolve a jca context issue (Geronimo-4375). However, it looks like it was soon discovered that there were issues with the OpenEJB, ASM and xBean versions in G. As a result ... we ended up reverting back to an older ASM and xBean 3.3 for finder and reflect while keeping the newer xbean-naming 3.5 so that the original issue was still resolved. That seems to be working and is perhaps the best approach. I was just concerned about using the various xBean versions in our Geronimo 2.1.4 server. Perhaps using the various xBean versions is still the best thing to do here. I didn't realize that there were core issues in OpenEJB attempting to use anything greater than 3.4.1. Thanks, Joe Jay D. McHugh wrote: Hey everyone, If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think that we'll need to chip in to resolve the problems that pop up when you use a version greater than 3.4.1. That was the highest version (available at the time) that could be used in the OpenEJB 3.0 branch without causing errors. I'll try switching to XBeans 3.5 (after the build I am in the middle of finishes) and let you all know if it goes through cleanly. My feeling is that it won't though. Also, I have been trying to get a 'final' Geronimo 2.0.x release put together and will need OpenEJB 3.0.1 for that (3.0 no longer builds because the artifacts for XBeans changed groupIds). Jay Joe Bohn wrote: I was relaying the information second-hand ... so it's very possible I got it wrong. It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can convince OpenEJB 3.0.x to xBean 3.5 we can then make the references consistent in our 2.1 branch. Thanks, Joe Donald Woods wrote: I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. Maybe you're thinking about OpenEJB? -Donald Joe Bohn wrote: I agree we should get a 2.1.4 release out ... and you certainly have my vote for release manager! The only thing I would add to the list is to get our xBean references to a consistent versions. I noticed this as I was updating branches/2.1 and trunk to pull in the newly released xBean 3.5. In branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) and 3.5 dependencies (naming). I've been told that this was due to OpenJPA dependencies on 3.3. Now that we are pulling in a new OpenJPA release we will hopefully be able to update everything to use xBean 3.5. Joe Jarek Gawor wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
Re: Time for Geronimo 2.1.4 release?
Hey everyone, If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think that we'll need to chip in to resolve the problems that pop up when you use a version greater than 3.4.1. That was the highest version (available at the time) that could be used in the OpenEJB 3.0 branch without causing errors. I'll try switching to XBeans 3.5 (after the build I am in the middle of finishes) and let you all know if it goes through cleanly. My feeling is that it won't though. Also, I have been trying to get a 'final' Geronimo 2.0.x release put together and will need OpenEJB 3.0.1 for that (3.0 no longer builds because the artifacts for XBeans changed groupIds). Jay Joe Bohn wrote: I was relaying the information second-hand ... so it's very possible I got it wrong. It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can convince OpenEJB 3.0.x to xBean 3.5 we can then make the references consistent in our 2.1 branch. Thanks, Joe Donald Woods wrote: I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. Maybe you're thinking about OpenEJB? -Donald Joe Bohn wrote: I agree we should get a 2.1.4 release out ... and you certainly have my vote for release manager! The only thing I would add to the list is to get our xBean references to a consistent versions. I noticed this as I was updating branches/2.1 and trunk to pull in the newly released xBean 3.5. In branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) and 3.5 dependencies (naming). I've been told that this was due to OpenJPA dependencies on 3.3. Now that we are pulling in a new OpenJPA release we will hopefully be able to update everything to use xBean 3.5. Joe Jarek Gawor wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
Re: Time for Geronimo 2.1.4 release?
Those classes that Geronimo is looking for are OpenEJB classes. Jay Jay D. McHugh wrote: The problem is with the version of ASM that is brought in when using a higher version of XBeans. OpenEJB is using a method that has been removed: org.objectweb.asm.ClassReader.accept And Geronimo (already - not counting XBeans 3.5) is using classes that have been removed: LinkResolver UniqueDefaultLinkResolver Jay Joe Bohn wrote: Thanks for the info Jay and for doing some more digging. I don't really have a strong desire to push everything to xBean 3.5. I was just trying to eliminate the use of multiple xBean versions as this could potentially cause problems (and confusion) for our users. It looks like we originally moved up to xBean 3.5 (actually 3.5-SNAPSHOT) to resolve a jca context issue (Geronimo-4375). However, it looks like it was soon discovered that there were issues with the OpenEJB, ASM and xBean versions in G. As a result ... we ended up reverting back to an older ASM and xBean 3.3 for finder and reflect while keeping the newer xbean-naming 3.5 so that the original issue was still resolved. That seems to be working and is perhaps the best approach. I was just concerned about using the various xBean versions in our Geronimo 2.1.4 server. Perhaps using the various xBean versions is still the best thing to do here. I didn't realize that there were core issues in OpenEJB attempting to use anything greater than 3.4.1. Thanks, Joe Jay D. McHugh wrote: Hey everyone, If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think that we'll need to chip in to resolve the problems that pop up when you use a version greater than 3.4.1. That was the highest version (available at the time) that could be used in the OpenEJB 3.0 branch without causing errors. I'll try switching to XBeans 3.5 (after the build I am in the middle of finishes) and let you all know if it goes through cleanly. My feeling is that it won't though. Also, I have been trying to get a 'final' Geronimo 2.0.x release put together and will need OpenEJB 3.0.1 for that (3.0 no longer builds because the artifacts for XBeans changed groupIds). Jay Joe Bohn wrote: I was relaying the information second-hand ... so it's very possible I got it wrong. It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can convince OpenEJB 3.0.x to xBean 3.5 we can then make the references consistent in our 2.1 branch. Thanks, Joe Donald Woods wrote: I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. Maybe you're thinking about OpenEJB? -Donald Joe Bohn wrote: I agree we should get a 2.1.4 release out ... and you certainly have my vote for release manager! The only thing I would add to the list is to get our xBean references to a consistent versions. I noticed this as I was updating branches/2.1 and trunk to pull in the newly released xBean 3.5. In branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) and 3.5 dependencies (naming). I've been told that this was due to OpenJPA dependencies on 3.3. Now that we are pulling in a new OpenJPA release we will hopefully be able to update everything to use xBean 3.5. Joe Jarek Gawor wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
Re: Time for Geronimo 2.1.4 release?
The problem is with the version of ASM that is brought in when using a higher version of XBeans. OpenEJB is using a method that has been removed: org.objectweb.asm.ClassReader.accept And Geronimo (already - not counting XBeans 3.5) is using classes that have been removed: LinkResolver UniqueDefaultLinkResolver Jay Joe Bohn wrote: Thanks for the info Jay and for doing some more digging. I don't really have a strong desire to push everything to xBean 3.5. I was just trying to eliminate the use of multiple xBean versions as this could potentially cause problems (and confusion) for our users. It looks like we originally moved up to xBean 3.5 (actually 3.5-SNAPSHOT) to resolve a jca context issue (Geronimo-4375). However, it looks like it was soon discovered that there were issues with the OpenEJB, ASM and xBean versions in G. As a result ... we ended up reverting back to an older ASM and xBean 3.3 for finder and reflect while keeping the newer xbean-naming 3.5 so that the original issue was still resolved. That seems to be working and is perhaps the best approach. I was just concerned about using the various xBean versions in our Geronimo 2.1.4 server. Perhaps using the various xBean versions is still the best thing to do here. I didn't realize that there were core issues in OpenEJB attempting to use anything greater than 3.4.1. Thanks, Joe Jay D. McHugh wrote: Hey everyone, If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think that we'll need to chip in to resolve the problems that pop up when you use a version greater than 3.4.1. That was the highest version (available at the time) that could be used in the OpenEJB 3.0 branch without causing errors. I'll try switching to XBeans 3.5 (after the build I am in the middle of finishes) and let you all know if it goes through cleanly. My feeling is that it won't though. Also, I have been trying to get a 'final' Geronimo 2.0.x release put together and will need OpenEJB 3.0.1 for that (3.0 no longer builds because the artifacts for XBeans changed groupIds). Jay Joe Bohn wrote: I was relaying the information second-hand ... so it's very possible I got it wrong. It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can convince OpenEJB 3.0.x to xBean 3.5 we can then make the references consistent in our 2.1 branch. Thanks, Joe Donald Woods wrote: I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. Maybe you're thinking about OpenEJB? -Donald Joe Bohn wrote: I agree we should get a 2.1.4 release out ... and you certainly have my vote for release manager! The only thing I would add to the list is to get our xBean references to a consistent versions. I noticed this as I was updating branches/2.1 and trunk to pull in the newly released xBean 3.5. In branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) and 3.5 dependencies (naming). I've been told that this was due to OpenJPA dependencies on 3.3. Now that we are pulling in a new OpenJPA release we will hopefully be able to update everything to use xBean 3.5. Joe Jarek Gawor wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
[jira] Created: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
Geronimo 2.0.x branch does not build with tests --- Key: GERONIMO-4527 URL: https://issues.apache.org/jira/browse/GERONIMO-4527 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: core, kernel, OpenEJB Affects Versions: 2.0.3 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4527: Attachment: geronimo-4527.diff Put all of the changes here so that there would be an easily reviewable set of changes if anyone cared to see what was changed to fix the build. Geronimo 2.0.x branch does not build with tests --- Key: GERONIMO-4527 URL: https://issues.apache.org/jira/browse/GERONIMO-4527 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core, kernel, OpenEJB Affects Versions: 2.0.3 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Attachments: geronimo-4527.diff Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-4527. - Resolution: Fixed Fix Version/s: 2.0.3 Changes committed to branches/2.0 Sending modules/geronimo-client/src/main/java/org/apache/geronimo/client/AppClientContainer.java Sending modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java Sending modules/geronimo-openejb-builder/src/main/java/org/apache/geronimo/openejb/deployment/EjbRefBuilder.java Sendingpom.xml Transmitting file data Committed revision 740608. Geronimo 2.0.x branch does not build with tests --- Key: GERONIMO-4527 URL: https://issues.apache.org/jira/browse/GERONIMO-4527 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core, kernel, OpenEJB Affects Versions: 2.0.3 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.0.3 Attachments: geronimo-4527.diff Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12670246#action_12670246 ] Jay D. McHugh commented on GERONIMO-4527: - I have been trying to get 2.0 ready for release - including removing dependencies on beta versions. When I moved it to point it at OpenEJB 3.0 (rather than 3.0-beta-1), the build stopped working. If you switch away from the beta version, does the build still work for you? Geronimo 2.0.x branch does not build with tests --- Key: GERONIMO-4527 URL: https://issues.apache.org/jira/browse/GERONIMO-4527 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core, kernel, OpenEJB Affects Versions: 2.0.3 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.0.3 Attachments: geronimo-4527.diff Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4527) Geronimo 2.0.x branch does not build after updating OpenEJB to released version (3.0)
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4527: Description: Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. In particular, after changing the dependency on OpenEJB from 3.0-beta-1 to 3.0, the build stopped working. Due to changes in the group/artifact names of the artifacts for XBeans - OpenEJB 3.0 no longer builds. There is now a new snapshot version of OpenEJB (3.0.1-SNAPSHOT). These changes include the new snapshot version of OpenEJB rather than the unbuildable 3.0 version. was:Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. Summary: Geronimo 2.0.x branch does not build after updating OpenEJB to released version (3.0) (was: Geronimo 2.0.x branch does not build with tests) Sorry for any confusion. This issue sprung up as a result of removing the dependency to the beta version of OpenEJB locally. Geronimo 2.0.x branch does not build after updating OpenEJB to released version (3.0) - Key: GERONIMO-4527 URL: https://issues.apache.org/jira/browse/GERONIMO-4527 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core, kernel, OpenEJB Affects Versions: 2.0.3 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.0.3 Attachments: geronimo-4527.diff Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. In particular, after changing the dependency on OpenEJB from 3.0-beta-1 to 3.0, the build stopped working. Due to changes in the group/artifact names of the artifacts for XBeans - OpenEJB 3.0 no longer builds. There is now a new snapshot version of OpenEJB (3.0.1-SNAPSHOT). These changes include the new snapshot version of OpenEJB rather than the unbuildable 3.0 version. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: git, hg or bzr for G development?
It seems like using git could provide some really compelling advantages. At least one of which would be to enable the security team to put together a patch set outside of SVN. That would make it easier for us to compile, test, and save partial fixes to security problems without having the subversion commit logs reveal the issues prematurely. Jay Kevan Miller wrote: On Dec 26, 2008, at 3:48 PM, Jacek Laskowski wrote: On Thu, Dec 18, 2008 at 7:55 AM, Jason Dillon ja...@planet57.com mailto:ja...@planet57.com wrote: I've been doing some experimenting using svn.eu.apache.org with git, so far it has gone well. What does git have that svn doesn't which makes you so interested in the subject? IIUC, the major advantages of GIT are: * offline commits - you can commit changes, even if online. * cheap branching - this would make it much simpler for individuals to create private local branches and work on implementing a particular feature, without interfering with other development they might be working on in the same code branch. * fast merging - given the cheap branching, you need to do a lot of merging, which GIT is supposed to do very well GIT would not be a replacement of SVN. The GIT repositories are actually mirroring svn. GIT would just be a new tool for accessing our code. There are some usages of GIT that would not fit well into an Apache project. For instance, I would not want to see project members using GIT as a private means of sharing code updates. Ultimately, code needs to get into our svn repo -- that's where we should be sharing code. I'm going to look for some guides on using GIT on apache projects. Barring any objections, I'm going to request that Geronimo be added to the GIT mirrors later this week. --kevan
Re: [VOTE] Release XBean 3.5 - rc2
+1 I added the rat plugin to my local pom and checked each module. There were some files that were flagged as failures - but they were reasonable (i.e. generated files, etc). Built fine w/ tests. Jay Kevan Miller wrote: Here's my +1. I scanned code using RAT, reviewed artifacts, and ran a build. --kevan On Jan 26, 2009, at 3:18 PM, Joe Bohn wrote: I uploaded a second distribution of XBean 3.5 which should include the NOTICE/LICENSE files in all the appropriate places (I hope). The same changes are present in this candidate that were present in the last one: * SocketAddress factory example for Alex [1] * XBEAN-111 Only register Converters with the VM when requested [2] * Make dependencies optional [3] * XBEAN-114 generify xbean-naming [4] * XBEAN-115 Fix rebind of entry added using deepBind [5] * XBEAN-115 similar fix to for WritableContext for consistency [6] * try to follow apache policy and not deploy timestamped snapshots [7] * Fix classloader name when throwing a CNFE [8] * Let the tests pass on non-MacOS OSes [9] * XBEAN-120 Search for semi-annotated classes in inheritance tree (as if @Inherited's applied) [10] * XBEAN-120 Search for semi-annotated classes in inheritance tree (as if @Inherited's applied) [11] * update copyright years to include 2009 [12] * add a siteId property to assist in release [13] Please help validate this release. I'm a little concerned about xbean-spring as I noticed some errors fly by during the release process but everything eventually passed successfully. I'll start validating this in a Geronimo server image but at the moment it will only utilize xbean-naming 3.5. The staging repository is available at http://people.apache.org/~jbohn/staging-repo/xbean/ and the tag is available at http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.5/ I've run the rat tool to validate license headers. Please review and vote: [ ] +1 Release XBean 3.5 [ ] -1 Do not, because ... The vote will be open for 72 hours or longer as necessary to validate the images and get sufficient participation in the vote. [1] http://svn.apache.org/viewvc?view=revrevision=689356 [2] http://svn.apache.org/viewvc?view=revrevision=703580 [3] http://svn.apache.org/viewvc?view=revrevision=705314 [4] http://svn.apache.org/viewvc?view=revrevision=707161 [5] http://svn.apache.org/viewvc?view=revrevision=707227 [6] http://svn.apache.org/viewvc?view=revrevision=707230 [7] http://svn.apache.org/viewvc?view=revrevision=707719 [8] http://svn.apache.org/viewvc?view=revrevision=725706 [9] http://svn.apache.org/viewvc?view=revrevision=729545 [10] http://svn.apache.org/viewvc?view=revrevision=729546 [11] http://svn.apache.org/viewvc?view=revrevision=731945 [12] http://svn.apache.org/viewvc?view=revrevision=737042 [13] http://svn.apache.org/viewvc?view=revrevision=737184 Thanks, Joe
Re: [VOTE] Release Concurrent Spec jar (1.0) version 1.0-EA
+1 Jay Joe Bohn wrote: I've prepared a release candidate of the Concurrent spec for your review and vote. This is spec is still under development so we are using an artifact version of 1.0-EA to indicate that it is not yet final. I'm just the release vehicle here ... Jarek did all the work :-) The source level is Rev723453 in the following svn tag: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-concurrent_1.0_spec-1.0-EA Staging repo: http://people.apache.org/~jbohn/staging-repo/specs/geronimo-concurrent_1.0_spec/ Staging site: http://people.apache.org/~jbohn/staging-site/specs/geronimo-concurrent_1.0_spec/1.0-EA/ The artifacts were created using the maven-release-plugin. When the release vote is approved, the maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. [ ] +1 Release Concurrent Spec 1.0 version 1.0-EA [ ] 0 No opinion [ ] -1 Do not release Concurrent Spec 1.0 version 1.0-EA(please provide rationale) The voting will be open for 72 hours (ending approx. 6:00PM ET on 12/07/08) or until we have enough votes, whichever is longer. Joe
Re: [VOTE] Release Concurrent Spec jar (1.0) version 1.0-EA - rc3
+1 Jay (voted on the wrong thread last time) Joe Bohn wrote: I've prepared a third release candidate of the Concurrent spec for your review and vote. The only change from rc2 is an update to the LICENSE file to include just the apache header (thanks to Kevan). This is spec is still under development so we are using an artifact version of 1.0-EA to indicate that it is not yet final. I'm just the release vehicle here ... Jarek did all the work :-) The source level is Rev723453 in the following svn tag: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-concurrent_1.0_spec-1.0-EA Staging repo: http://people.apache.org/~jbohn/staging-repo/specs/geronimo-concurrent_1.0_spec/ Staging site: http://people.apache.org/~jbohn/staging-site/specs/geronimo-concurrent_1.0_spec/1.0-EA/ The artifacts were created using the maven-release-plugin and the maven rat plugin was run to verify the source contains the appropriate headers. When the release vote is approved, the maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. [ ] +1 Release Concurrent Spec 1.0 version 1.0-EA [ ] 0 No opinion [ ] -1 Do not release Concurrent Spec 1.0 version 1.0-EA(please provide rationale) The voting will be open for 72 hours (ending approx. 12:00AM ET on 12/12/08) or until we have enough votes, whichever is longer. Joe
Re: GERONIMO-4229
+1 to getting rid of GERONIMO_BASE Jay Jarek Gawor wrote: Hi, I was looking at GERONIMO-4229 today (please see the bug and my comments for details). There is a remaining issue with the GERONIMO_BASE property and what it does. The Java system property that it sets is not used anywhere in the code and therefore that property is useless. I have a couple of ideas what we can do with it or how to fix it: 1) Totally get rid off GERONIMO_BASE in the shell scripts. It doesn't do anything right now anyway and it just confuses people. People that want to use multiple server instances will need to pass org.apache.geronimo.server.dir or org.apache.geronimo.server.name property using the GERONIMO_OPTS env. property (as it is documented today). or 2) Keep GERONIMO_BASE but only pass org.apache.geronimo.server.dir property (to the java process) if the user has set the GERONIMO_BASE env. property explicitly. That is, do not set GERONIMO_BASE property automatically within the script as it is done now. If it would be automatically set, the org.apache.geronimo.server.name property (passed via GERONIMO_OPTS) would always be ignored. Thoughts? Jarek
Re: [VOTE] Release specs-parent 1.6
+1 Jay Joe Bohn wrote: This is a vote for specs-parent 1.6. The primary purpose for this release is to utilize the newly released genesis 1.5 which included some enhancements to facilitate maven site generation. There are also some minor changes in specs-parent to facilitate maven site generation. Once released and leveraged by the individual spec projects we should be able to produce better maven site content. The rat-maven-plugin has been used to check the source and passed. Staging repo (maven artifacts): http://people.apache.org/~jbohn/staging-repo/specs/ SVN source location: https://svn.apache.org/repos/asf/geronimo/specs/tags/specs-parent-1.6/ Generated Maven Site: http://people.apache.org/~jbohn/staging-site/specs/1.6/index.html The vote is open for 72 hours and will conclude on Friday (10/31) at 5:00 PM ET. [ ] +1 Release specs-parent 1.6 [ ] +0 No opinion [ ] -1 Don't release specs-parent 1.6 and reason why Thanks, Joe
Re: [DISCUSS] Moving the JAXB specification apis to Geronimo Specs
+1 Jay Guillaume Nodet wrote: In ServiceMix we have rewritten the JAXB specs jars (2.0 and 2.1) because we needed to be able to do some modifications for OSGi. We'd like to move them to the Geronimo Specs subproject as it would be more consistent and would allow them to pass the TCK. The code base are available at: https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jaxb-api-2.0/ https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jaxb-api-2.1/ I'm quite confident that passing the TCK should not be a major problem because they check the compliance with the Sun jars using a maven plugin that use introspection to detect signature changes between two jars. Anyway, feedback welcome.
Re: [DISCUSS] Geronimo 2.0.3 release
Hey Joe, Not releasing any more 2.0.x was one of the possible choices that I was leaning toward too. The only thing that kept it from being my first recommendation was that I was sad that so much work on the 2.0 branch would never get its day in the sun (at least not as 2.0). But, as far as stumbling blocks to moving up...I don't think there should be any large ones. I have been keeping current so I don't remember what (if anything) I had to do to move up to 2.1. Actually, that is not entirely true. There were a number of jar files that used to be included in Geronimo that were removed. I have since had to add them back to the repository whenever I reinstall. I think that we already handle deployment descriptors for older versions automatically (at least back to 2.0), so those should not be a problem. So, I think that if we put together a table of libraries that are no longer supplied and/or whose versions are not backwards compatible - that might be enough to handle at least the majority of conversion issues. But, if we do not release 2.0.3 then I think that we need to get rather vocal about the security issues and the -urgent- need to upgrade to 2.1+. Jay Joe Bohn wrote: I apologize for not raising this question on the earlier thread. I'm wondering if it is a good idea to release a 2.0.3 at this point in time. We've had several releases of 2.1.x (four) and we'll hopefully release 2.2 in the not too distant future. I'm a little concerned that releasing a 2.0.3 now will just encourage people to continue on the 2.0.* base rather than taking the plunge and moving up to 2.1.*. It's been a year since we released 2.0.2 and in addition to the security fixes there have been a lot of other fixes/enhancements in the 2.1 branch. What are the big stumbling blocks that prevent a user from moving from 2.0.2 to 2.1.3 to resolve the security concerns? Rather than releasing 2.0.3, should we maybe consider a greater focus on ensuring there is a smooth migration path from 2.0.2 to 2.1.3? Once we have clearly identified any issues and ensured that we have adequate directions we could notify the user community that there will be no further 2.0.* releases and encourage them to move to 2.1.3. It might actually be easier for us to release 2.0.3 in the short term, but sooner or later users will have to address the migration issues ... so I'm just wondering if it might be a better use of our time to address those migration issues now. Joe Jay D. McHugh wrote: The 2.0.x brach got sidelined by an intermittent ConcurrentModificationException during stress testing. But, recently there were a number of security issues found that apply to 2.0.2. So, I think it's time to start the discussion for a Geronimo 2.0.3 release (It actually already was started). Server fixes/enhancements are listed on the Release Status page (work in progress)- http://cwiki.apache.org/GMOxPMGT/geronimo-203-release-status.html Details on included security fixes in dependent components are listed on the Security page - http://geronimo.apache.org/20x-security-report.html I have already begun moving issues into 2.0.4 - Does anyone have additional fixes they would like to include in 2.0.3 before we cut the branch and start the release process? If I have moved an issue that you want to work on (And you have time to work on it right away) move it back onto a 2.0.3 fix and assign it to yourself. Jay
Re: Building 2.0.3
Thanks Donald,
It was the Maven version (g).
I just got a second test build completed. So, I am going to change the
pom.xml so that you have to use Maven between 2.0.5 and 2.0.7 so that
(hopefully) no one else runs into the same problems.
Jay
Donald Woods wrote:
Which OS, JDK and Maven?
The 2.0 builds are using Maven 2.0.7 and Sun 1.5.0_16 on a Linux system.
It's been a week or so since I rebuilt branches/2.0, but the last I
tried it worked for me with a clean repo on openSUSE 11.0 and MacOSX.
-Donald
Jay D. McHugh wrote:
Hello all,
I know that we have the automated build going on. And I have been
getting the emails daily saying that the build was successful for 2.0.3.
But, when I started with a fresh checkout and an empty repo - I was
unable to build.
Are there changes that were made on the automated build machine? Is
there something special about the settings it is using?
I have already fixed a couple of problems, but before I check them in -
I wanted to make sure that they are actually necessary.
Has anyone tried to do a clean and fresh build of 2.0 recently? Did you
need to do anything special?
I am currently getting stuck with the following exception (tracing
enabled):
console snip
[INFO]
[INFO] Building Geronimo :: System
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: process}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [antrun:run {execution: generate-dynamic-properties}]
[INFO] Executing tasks
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: Could not create task or type of type: propertyfile.
Ant could not find the task or a class this task relies upon.
This is common and has a number of causes; the usual
solutions are to read the manual pages then download and
install needed JAR files, or fix the build file:
- You have misspelt 'propertyfile'.
Fix: check your spelling.
- The task needs an external JAR file to execute
and this is not found at the right place in the classpath.
Fix: check the documentation for dependencies.
Fix: declare the task.
- The task is an Ant optional task and the JAR file and/or libraries
implementing the functionality were not found at the time you
yourself built your installation of Ant from the Ant sources.
Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the
task and make sure it contains more than merely a
META-INF/MANIFEST.MF.
If all it contains is the manifest, then rebuild Ant with the needed
libraries present in ${ant.home}/lib/optional/ , or alternatively,
download a pre-built release version from apache.org
- The build file was written for a later version of Ant
Fix: upgrade to at least the latest release version of Ant
- The task is not an Ant core or optional task
and needs to be declared using taskdef.
- You are attempting to use a task defined using
presetdef or macrodef but have spelt wrong or not
defined it at the point of use
Remember that for JAR files to be visible to Ant tasks implemented
in ANT_HOME/lib, the files must be in the same directory or on the
classpath
Please neither file bug reports on this problem, nor email the
Ant mailing lists, until all of these causes have been explored,
as this is not an Ant bug.
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing
ant tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke
[jira] Resolved: (GERONIMO-1907) Deploy command should redeploy if the app is already deployed
[ https://issues.apache.org/jira/browse/GERONIMO-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-1907. - Resolution: Won't Fix Assignee: Jay D. McHugh (was: Rakesh Midha) When an app is undeployed (as part of a redeploy) any other apps that depend on it are stopped. Trying to track down all apps that depend on the current app so that they can be automatically restarted is too much effort to expend in the 2.0.x branch. If there is sufficient interest - a new JIRA should be opened in a more current/active branch. Deploy command should redeploy if the app is already deployed - Key: GERONIMO-1907 URL: https://issues.apache.org/jira/browse/GERONIMO-1907 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment, usability Affects Versions: 1.1 Reporter: Aaron Mulder Assignee: Jay D. McHugh Priority: Critical Fix For: 2.0.3 Attachments: redeploy.patch Attached patch, and changing fix version to 1.2. Also unassigning so that committers can review and update. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1354) The var/config.xml file is always re-written even if no attribute changes are made by the user
[ https://issues.apache.org/jira/browse/GERONIMO-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-1354. --- The var/config.xml file is always re-written even if no attribute changes are made by the user -- Key: GERONIMO-1354 URL: https://issues.apache.org/jira/browse/GERONIMO-1354 Project: Geronimo Issue Type: Wish Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0 Reporter: John Sisson Assignee: Jay D. McHugh Fix For: 2.0.3 This means the user can never edit the config.xml file while Geronimo is running. The user has to shut down Geronimo and then make their changes and therefore the amount of time to implement a change is longer than needed. For 1.0 I will add some extra text to the warning in the top of the config.xml file ( see org.apache.geronimo.system.configuration.ServerOverride) that tells the user not to edit the file whilst Geronimo is running. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2128) Allow user to specify the Isolation Level for a CMP bean's SQL access
[ https://issues.apache.org/jira/browse/GERONIMO-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-2128: Fix Version/s: (was: 2.0.3) (was: 1.x) 2.0.4 Allow user to specify the Isolation Level for a CMP bean's SQL access - Key: GERONIMO-2128 URL: https://issues.apache.org/jira/browse/GERONIMO-2128 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Reporter: Matt Hogstrom Fix For: 2.0.4 Currently CMP beans all execute in the default isolation level of the datasource. This means that in many situations higher level locks are required for the database access than are required. This improvement will allow the user to specify a new attribute on a CMP entity bean isolation-level that will be the isolation level used for database access on this entity bean. This will require updates to OpenEJB and TranQL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2288) Abstract/Maven repositories install modules incorrectly
[ https://issues.apache.org/jira/browse/GERONIMO-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-2288: Fix Version/s: (was: 2.0.3) 2.0.4 Abstract/Maven repositories install modules incorrectly --- Key: GERONIMO-2288 URL: https://issues.apache.org/jira/browse/GERONIMO-2288 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel, Plugins Affects Versions: 1.1, 1.1.1, 1.2, 2.0-M6 Reporter: Aaron Mulder Assignee: Aaron Mulder Fix For: 2.0.4 The repository unpacks a JAR when it installs it only if the Artifact type is car. That is incorrect -- it should unpack any module with META-INF/config.ser (which is the logic that we use in other places, such as RepositoryConfigurationStore). This breaks plugins that don't have the type car (such as copying a database pool from server to server). The currently handling attempts to be generic by associating a behavior with each file type, though in practice this is only used for type=car. In the 1.1 branch, I am going to put in a workaround to look up the car handler any time we find a META-INF/config.ser (a pretty minimal workaround). In trunk, I think we should remove the behavior/type association and instead have a boolean for whether configurations should be unpacked, or an ArtifactTypeHandler property specifically for configurations and another one for non-configurations. I don't see any reason to distinguish based on module type. Input would be appreciated for the 1.2 resolution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DISCUSS] Geronimo 2.0.3 release
The 2.0.x brach got sidelined by an intermittent ConcurrentModificationException during stress testing. But, recently there were a number of security issues found that apply to 2.0.2. So, I think it's time to start the discussion for a Geronimo 2.0.3 release (It actually already was started). Server fixes/enhancements are listed on the Release Status page (work in progress)- http://cwiki.apache.org/GMOxPMGT/geronimo-203-release-status.html Details on included security fixes in dependent components are listed on the Security page - http://geronimo.apache.org/20x-security-report.html I have already begun moving issues into 2.0.4 - Does anyone have additional fixes they would like to include in 2.0.3 before we cut the branch and start the release process? If I have moved an issue that you want to work on (And you have time to work on it right away) move it back onto a 2.0.3 fix and assign it to yourself. Jay
[jira] Updated: (GERONIMO-2045) Plugin prerequisites: for DB pools, support DB type/version and table validation
[ https://issues.apache.org/jira/browse/GERONIMO-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-2045: Fix Version/s: (was: 2.0.3) (was: 1.x) 2.0.4 Plugin prerequisites: for DB pools, support DB type/version and table validation Key: GERONIMO-2045 URL: https://issues.apache.org/jira/browse/GERONIMO-2045 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 2.0.4 More robust database pool prerequisites for plugins: - check that one of a specific set of RDBMS name/version combinations is set for a connection pool prerequisite - check the schema somehow -- e.g. that some table exists, or some query returns an expected value -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1842) Dynamically load jars from the WEB-INF/lib directory
[ https://issues.apache.org/jira/browse/GERONIMO-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-1842: Fix Version/s: (was: 2.0.3) (was: 1.x) 2.0.4 Dynamically load jars from the WEB-INF/lib directory Key: GERONIMO-1842 URL: https://issues.apache.org/jira/browse/GERONIMO-1842 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: core Reporter: Prasad Kashyap Fix For: 2.0.4 Currently the server has a hardcoded list of what it expects in the WEB-INF/lib dir. This means that additions/deletion of jars in that directory will not be picked up without actually redeploying that app. This seems like a major irritant. The best thing of course would be to dynamically pick up or drop jars from the lib directory as they are added/deleted. But we can, for now, settle for loading/unloading them at an app restart. This should be the bare minimum requirement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3815) ContextManager.getCurrentContext() throws NullPointerException
[ https://issues.apache.org/jira/browse/GERONIMO-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3815: Fix Version/s: (was: 2.0.3) 2.0.4 ContextManager.getCurrentContext() throws NullPointerException -- Key: GERONIMO-3815 URL: https://issues.apache.org/jira/browse/GERONIMO-3815 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.1 Reporter: Vamsavardhana Reddy Fix For: 2.0.4, 2.1.4, 2.2 Attachments: GERONIMO-3815-2.debug.patch, GERONIMO-3815-3.debug.patch, GERONIMO-3815.debug.patch ContextManager.getCurrentContext() is throwing a NullPointerException. This is observed only when there is heavy load on the application. Most likely it is a threading issue where one thread is unregistering the subject while another is executing getCurrentContext(). Excerpt from stacktrace given below. Caused by: java.lang.NullPointerException at org.apache.geronimo.security.ContextManager.getCurrentContext(ContextManager.java:197) at org.apache.geronimo.openejb.GeronimoSecurityService.isCallerAuthorized(GeronimoSecurityService.java:101) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:142) at org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(EjbHomeProxyHandler.java:267) at org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:158) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy16.create(Unknown Source) ... 53 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4124) Tomcat jacc usage is messed up
[ https://issues.apache.org/jira/browse/GERONIMO-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4124: Fix Version/s: (was: 2.0.3) 2.0.4 Tomcat jacc usage is messed up -- Key: GERONIMO-4124 URL: https://issues.apache.org/jira/browse/GERONIMO-4124 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0.2, 2.1.1, 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0.4, 2.1.4, 2.2 Several problems: 1. UserDataPermissions are not getting evaluated by jacc due to the check for Subject in handler data. 2. Subject is never set into handler data (also a problem in jetty, dunno about openejb). 3. TomcatGeronimoRealm is calling ContextManager.setCallers before permission checks. This is wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4222: Fix Version/s: (was: 2.0.3) 2.0.4 Database pool unusable after database unavailable for awhile Key: GERONIMO-4222 URL: https://issues.apache.org/jira/browse/GERONIMO-4222 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2, 2.1, 2.1.1, 2.1.2, 2.1.4, 2.2 Environment: Red Hat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 Reporter: David Frahm Assignee: Donald Woods Fix For: 2.0.4, 2.1.4, 2.2 Attachments: before and after wasce restart.txt, stacktrace.txt I have frequent trouble with my database pool to an AS/400. The database is taken down every night for backup, and at least once a week the connection pool is unusable after the database comes back up. Restarting the connection pool makes everything work again. We are new to Geronimo/WAS-CE -- just this one app on one server -- so I don't have anything to compare to. However, we have had this same issue with a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. Configuration Info Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) Pool Min Size: 0 Pool Max Size: 100 Blocking Timeout: 5000 Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1807) Remove uses of ObjectName from core server
[ https://issues.apache.org/jira/browse/GERONIMO-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-1807: Fix Version/s: (was: 2.0.3) 2.0.4 Remove uses of ObjectName from core server -- Key: GERONIMO-1807 URL: https://issues.apache.org/jira/browse/GERONIMO-1807 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Reporter: Dain Sundstrom Fix For: 2.0.4 Using the ObjectName class in the core server causes a dependency on the jmx classes. We are also in the process of moving away from these, but there are still many places that use this class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4295) Upgrade to Derby 10.4.2.0
[ https://issues.apache.org/jira/browse/GERONIMO-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4295: Fix Version/s: (was: 2.0.3) 2.0.4 Upgrade to Derby 10.4.2.0 - Key: GERONIMO-4295 URL: https://issues.apache.org/jira/browse/GERONIMO-4295 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: dependencies Affects Versions: 2.0.3, 2.1.3, 2.2 Reporter: Donald Woods Assignee: Donald Woods Priority: Minor Fix For: 2.0.4, 2.1.4, 2.2 Upgrade to Derby 10.4.2.0, which was released on Sept. 5, 2008. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Genesis 1.5 - take 3
+1 Jay Joe Bohn wrote: This is a vote for Genesis 1.5. Take 3: In addition to take 1 take 2 this includes a more appropriate javadoc max memory setting. Take 2: Same as take 1 except for replacing the hard-coded dependency on geronimo-skin from 1.5-SNAPSHOT with 1.5 (this release). Take 1: While trying to get site generation improved for the specs, I discovered that I needed a few minor changes to genesis. It's been a while since we released a 1.x version of Genesis, so this also includes other changes as well. AFAIK this release includes these changes: - updated maven-plugin versions - updated default of uniqueVersion=false for apache-snapshots - improved multi-project support (such as for samples server) - improved site generation for dependent projects (specs) - elimination of tools-maven-plugin and added configuration for ianal-maven-plugin which now verifies legal files. The rat-maven-plugin has been used to check the source and passed. Staging repo (maven artifacts): http://people.apache.org/~jbohn/staging-repo/genesis/ SVN source location: https://svn.apache.org/repos/asf/geronimo/genesis/tags/genesis-1.5 Generated Maven Site: http://people.apache.org/~jbohn/staging-site/genesis/1.5/index.html The vote is open for 72 hours and will conclude on Friday (10/24) at 5:00 PM ET. [ ] +1 Release Genesis 1.5 [ ] +0 No opinion [ ] -1 Don't release Genesis 1.5 and reason why Thanks, Joe
