Queue and Persistence for openwire-cpp API
Hi, I am working on openwire-cpp ( for ActiveMQ-4.0) code on SuSe(Linux machine-i686-suse-linux, version 2.6.13-15.8-default) I am able to maintain the persistence by using the openwire-cpp API, but with a problem. In the case when the receiver is down and sender has sent messages. the restarted receiver does not get to receive the pending messages untill sender sends a new message. The receiver then receives all the pending message with this new message. What is going on? I am not getting this. Is this the openwire-cpp API fault Or I am doing something wrong(missing something). Thanks in advance Regards Arashad Ahamad
Re: subversion plugin for jira
Apparently the SVN plugin is installed (though its an old version - currently 0.8.2). Though the web admin front end I don't see a way to upgrade it or configure it so not sure what to do; we might have to pester the infra folks to upgrade it and configure it etc. It would be very handy though! On 7/5/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Hey guys, are we using this? http://confluence.atlassian.com/display/JIRAEXT/JIRA+Subversion+plugin Seems like it might be a way to bridge between commits and issues. Nate -- James --- http://radio.weblogs.com/0112098/
Re: subversion plugin for jira
There are still a few places where you must do the same thing with Confluence. But the new repository client plugin kicks much ass to get new plugins and update those that are installed. --jason On Jul 6, 2006, at 1:16 AM, James Strachan wrote: On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote: You must install a new jar in the WEB-INF/lib and redeploy the web- app. No nice and easy web admin for plugins in JIRA. Shame! :) I like the new confluence do-it-all-via-web stuff. Anyone know how to get on the box to upgrade it etc? -- James --- http://radio.weblogs.com/0112098/
RE: ActiveMQ-CPP Mac changes dropped
Hey Hiram, BTW, I just googled for svn:eol-style and ran across this link http://www.apache.org/dev/svn-eol-style.txt I'm guessing I should probably have these settings before I commit? ... oops! :) Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Wednesday, July 05, 2006 10:34 PM To: activemq-dev@geronimo.apache.org Subject: Re: ActiveMQ-CPP Mac changes dropped The only thing I did was use the svn propset svn:eol-style native command. So It's weird that there woudl be any loss of data. Do you got a link to jame's svn revistion? On 7/5/06, Timothy Bish [EMAIL PROTECTED] wrote: Hiram I was taking a look at the code in activemq-cpp to sync up all the changes that James had made for the Mac, and I noticed that as of 6:27pm today you had touched almost all the files, and now the changes James had made are gone. I think I got most of them into my own local SVN, but I am not 100%. I'm working on some additional things locally for the next rev. - Timothy A. Bish [EMAIL PROTECTED] -- Regards, Hiram Blog: http://hiramchirino.com
Re: Update to the wiki for the ActiveMQ CPP library
On 7/6/06, Mittler, Nathan [EMAIL PROTECTED] wrote: FYI, I've added a page to the wiki for ActiveMQ CPP: http://www.activemq.org/site/activemq-cpp-client.html Also updated the Integration C++ link on the navigation pane to reference this page instead of CMS and I updated the C Integration page to add a link to this page as well. Great stuff Nate! Documentation rocks :) -- James --- http://radio.weblogs.com/0112098/
[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12419427 ] Jacek Laskowski commented on GERONIMO-2161: --- What will happen after I've tested it out? How will we proceed? How do you want the changes to be applied to trunk? svn merge? [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml --- Key: GERONIMO-2161 URL: http://issues.apache.org/jira/browse/GERONIMO-2161 Project: Geronimo Type: Task Security: public(Regular issues) Components: buildsystem Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.2 Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch, GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch, GERONIMO-2161-v4.patch, GERONIMO-2161-v5.patch As I have mentioned before, I believe we should remove the Geronimo modules that are currently listed in the root pom.xml: This reduces the configuration of the pom by *~500 lines*. Modules that reference these as dependencies will need their pom's adjusted to include version${pom.version}/version and typecar/type for the configs. But in many places version already exists with the ${geronimoVersion} property... which kinda negates the purpose of the dependencyManagement section anyways. I believe that it is more work to keep track of every module in the root pom than it is to specify the additonal elements (mostly just version${pom.version}/version) in child poms. There is no additional maintenance, as the new elements never need to be changed. Net effect if this change is less configuration to maintain and thus a less brittle build that can adapt to change easier. Specifically these should be removed: {code:xml} dependency groupIdorg.apache.geronimo.modules/groupId artifactIdge-activemq-rar/artifactId version${geronimoVersion}/version typerar/type /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-activation/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-client/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-client-builder/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-common/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-connector/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-connector-builder/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-converter/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-core/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deploy-config/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deploy-jsr88/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deploy-tool/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deployment/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-derby/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-directory/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-javamail-transport/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-j2ee/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId
Re: Geronimo specs pre-RTC
On 7/6/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I had an ah ha experience after my fourth beer, before my third hamburger, yesterday. One word, branch. I'll cook something up in geronimo/specs/branch. I'll include Jason's suggestions. Yeah, it happened to me as well, but it was way faster than after the proverbial fourth beer - I couldn't survive after the second not mentioning the following ones ;-) May I read it as you being a not-yet-but-soon proponent of using branches before a commit to trunk with RTC? That would be great to hear a friendly soul nearby. ;-) Alan Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12419429 ] Jacek Laskowski commented on GERONIMO-2161: --- After some thinking...may I find out how the patch was cut? I mean what revisions it holds of svkmerge/m2migration? I'd like to apply the patch to my local copy of a fresh Geronimo srcs check-out with svn merge and give it a shot rather than relying on the incompatible patch. [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml --- Key: GERONIMO-2161 URL: http://issues.apache.org/jira/browse/GERONIMO-2161 Project: Geronimo Type: Task Security: public(Regular issues) Components: buildsystem Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.2 Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch, GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch, GERONIMO-2161-v4.patch, GERONIMO-2161-v5.patch As I have mentioned before, I believe we should remove the Geronimo modules that are currently listed in the root pom.xml: This reduces the configuration of the pom by *~500 lines*. Modules that reference these as dependencies will need their pom's adjusted to include version${pom.version}/version and typecar/type for the configs. But in many places version already exists with the ${geronimoVersion} property... which kinda negates the purpose of the dependencyManagement section anyways. I believe that it is more work to keep track of every module in the root pom than it is to specify the additonal elements (mostly just version${pom.version}/version) in child poms. There is no additional maintenance, as the new elements never need to be changed. Net effect if this change is less configuration to maintain and thus a less brittle build that can adapt to change easier. Specifically these should be removed: {code:xml} dependency groupIdorg.apache.geronimo.modules/groupId artifactIdge-activemq-rar/artifactId version${geronimoVersion}/version typerar/type /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-activation/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-client/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-client-builder/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-common/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-connector/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-connector-builder/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-converter/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-core/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deploy-config/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deploy-jsr88/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deploy-tool/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deployment/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-derby/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-directory/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-javamail-transport/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId
Re: [jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
I'm sorry... but I do not understand what you are asking Jacek. Could you please rephrase your question/request? Thanks, --jason On Jul 6, 2006, at 12:22 AM, Jacek Laskowski (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2161? page=comments#action_12419429 ] Jacek Laskowski commented on GERONIMO-2161: --- After some thinking...may I find out how the patch was cut? I mean what revisions it holds of svkmerge/m2migration? I'd like to apply the patch to my local copy of a fresh Geronimo srcs check-out with svn merge and give it a shot rather than relying on the incompatible patch. [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml - -- Key: GERONIMO-2161 URL: http://issues.apache.org/jira/browse/GERONIMO-2161 Project: Geronimo Type: Task Security: public(Regular issues) Components: buildsystem Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.2 Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161- v1.patch, GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch, GERONIMO-2161-v4.patch, GERONIMO-2161-v5.patch As I have mentioned before, I believe we should remove the Geronimo modules that are currently listed in the root pom.xml: This reduces the configuration of the pom by *~500 lines*. Modules that reference these as dependencies will need their pom's adjusted to include version${pom.version}/version and typecar/type for the configs. But in many places version already exists with the ${geronimoVersion} property... which kinda negates the purpose of the dependencyManagement section anyways. I believe that it is more work to keep track of every module in the root pom than it is to specify the additonal elements (mostly just version${pom.version}/version) in child poms. There is no additional maintenance, as the new elements never need to be changed. Net effect if this change is less configuration to maintain and thus a less brittle build that can adapt to change easier. Specifically these should be removed: {code:xml} dependency groupIdorg.apache.geronimo.modules/groupId artifactIdge-activemq-rar/artifactId version${geronimoVersion}/version typerar/type /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-activation/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-client/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-client-builder/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-common/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-connector/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-connector-builder/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-converter/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-core/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deploy-config/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deploy-jsr88/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deploy-tool/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-deployment/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-derby/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-directory/artifactId version${geronimoVersion}/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-javamail-transport/artifactId version${geronimoVersion}/version
Re: [jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm sorry... but I do not understand what you are asking Jacek. Could you please rephrase your question/request? How did you cut the latest patch v5? What commands did you use? I guess it was something like 'svn diff ... GERONIMO-2161-v5.patch', wasn't it? If so and the changes are part of a branch (e.g. svkmerge/m2migration), we (testers) could apply it to our local Geronimo srcs using 'svn merge' nor 'patch' that we've just found is incompatible. This way we will use svn commands only and be able to apply and test it. --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
--- Jason Dillon [EMAIL PROTECTED] wrote: What user friendliness are you talking about? --jason On Jul 5, 2006, at 2:25 AM, anita kulshreshtha wrote: I would also prefer to see any changes to improve the maintainability and user friendliness of M2 build be held off until the server assembly is functional. Thanks Anita --- David Jencks [EMAIL PROTECTED] wrote: On Jul 5, 2006, at 12:25 AM, John Sisson wrote: Jacek Laskowski wrote: On 7/3/06, Jason Dillon [EMAIL PROTECTED] wrote: NOTE... the m2 build in trunk is already broken... this patches help FIX MANY OF THOSE PROBLEMS! NOTED, but... it's not broken. it has never worked so we can pretend to call it broken. It's a small, but important point we cannot dismiss. Since the official build is still m1 and this will not affect the m1 build, I don't see why your point about breakage is applicable at all. ... When I first created the m1 build for Geronimo years ago there were certainly a few moments of breakage due to build changes, but since there was no commit by committee junk going on then it was easy to just fix when things happened to get a bit askew. The branch idea was just to make it easier to actually make progress, as I am move on this stuff way way faster than the lot of you can react to emails and JIRAs which often (as this one did) need several sets of emails to clarify. That's the point in RTC - discussing, discussing, over and over again. I'm not in favour of RTC, but some of its rules are fine. It fosters discussions we lacked. That's the main point of RTC. Isn't it funny that you've mentioned it as an argument against RTC? What's wrong with committing changes made in the branch back to trunk once they've been tested? My proposal is not to wait until the migration is done, but rather apply it in small portions, gradually. It should work, shouldn't it? I'd greatly appreciate your comment on it as I guess I don't see the whole picture and keep thinking the branch might help when others have already seen it would fall short. Can we avoid the concerns that have been aired regarding svn merging issues when directories are reorganised by leaving the reorganization of directories as a last phase of the m2 migration? I would have thought that we could move further along with the migration without reorganizing directories (AFAIK, maven should be able to work with existing directory structures, although doing so may incur more work). We would also need to coordinate the reorganization of directories with the owners of other branches from trunk, to minimize the impact on them. I would prefer to wait to reorganize the directories until after the work in the dead-1.2 branch is merged with trunk. I plan to go back to this activity now. Other committers may wish to note that merging the work in dead-1.2 should not need RTC as it is already part of a main development line. thanks david jencks John --jason Jacek __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
OSCON Geronimo BOF Scheduled
For those committers that will be at the OSCON Conference we have a BOF scheduled. It is: Your BoF for OSCON 2006 has been scheduled for: • Wednesday, July 26 • 7:30 pm - 8:30 pm • Location: D139-140 • BoF Name: New Features of Apache Geronimo 1.1 (including new plug-in capability) Who all will be at OSCON?
Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
The existing commands to build are - cd modules, mvn clean cd ..\m2-plugins, mvn and After this as long as you do not wipe out the plugin, one can use just mvn from the top directory to get a full build. Did these not work for you (after you had the right xmlbeans plugin)? The new build (GERONIMO-2161) uses 2 step process - mvn -Dstaqge=bootstrap mvn -Dstage=assemble The bootstrap stage still builds all the modules! The assemble stage does not build them. User will be forced to always use 2 commannds - clean repo or not. Which I think is not very user firendly. Hiding building modules and plugins in a bootstrap phase is more user friendly. Because the users will not be exposed to the shortcoming of maven. Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: What user friendliness are you talking about? --jason On Jul 5, 2006, at 2:25 AM, anita kulshreshtha wrote: I would also prefer to see any changes to improve the maintainability and user friendliness of M2 build be held off until the server assembly is functional. Thanks Anita --- David Jencks [EMAIL PROTECTED] wrote: On Jul 5, 2006, at 12:25 AM, John Sisson wrote: Jacek Laskowski wrote: On 7/3/06, Jason Dillon [EMAIL PROTECTED] wrote: NOTE... the m2 build in trunk is already broken... this patches help FIX MANY OF THOSE PROBLEMS! NOTED, but... it's not broken. it has never worked so we can pretend to call it broken. It's a small, but important point we cannot dismiss. Since the official build is still m1 and this will not affect the m1 build, I don't see why your point about breakage is applicable at all. ... When I first created the m1 build for Geronimo years ago there were certainly a few moments of breakage due to build changes, but since there was no commit by committee junk going on then it was easy to just fix when things happened to get a bit askew. The branch idea was just to make it easier to actually make progress, as I am move on this stuff way way faster than the lot of you can react to emails and JIRAs which often (as this one did) need several sets of emails to clarify. That's the point in RTC - discussing, discussing, over and over again. I'm not in favour of RTC, but some of its rules are fine. It fosters discussions we lacked. That's the main point of RTC. Isn't it funny that you've mentioned it as an argument against RTC? What's wrong with committing changes made in the branch back to trunk once they've been tested? My proposal is not to wait until the migration is done, but rather apply it in small portions, gradually. It should work, shouldn't it? I'd greatly appreciate your comment on it as I guess I don't see the whole picture and keep thinking the branch might help when others have already seen it would fall short. Can we avoid the concerns that have been aired regarding svn merging issues when directories are reorganised by leaving the reorganization of directories as a last phase of the m2 migration? I would have thought that we could move further along with the migration without reorganizing directories (AFAIK, maven should be able to work with existing directory structures, although doing so may incur more work). We would also need to coordinate the reorganization of directories with the owners of other branches from trunk, to minimize the impact on them. I would prefer to wait to reorganize the directories until after the work in the dead-1.2 branch is merged with trunk. I plan to go back to this activity now. Other committers may wish to note that merging the work in dead-1.2 should not need RTC as it is already part of a main development line. thanks david jencks John --jason Jacek __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
The existing commands to build are - cd modules, mvn clean cd ..\m2-plugins, mvn and After this as long as you do not wipe out the plugin, one can use just mvn from the top directory to get a full build. Did these not work for you (after you had the right xmlbeans plugin)? The new build (GERONIMO-2161) uses 2 step process - mvn -Dstaqge=bootstrap mvn -Dstage=assemble The bootstrap stage still builds all the modules! The assemble stage does not build them. User will be forced to always use 2 commannds - clean repo or not. Which I think is not very user firendly. Hiding building modules and plugins in a bootstrap phase is more user friendly. Because the users will not be exposed to the shortcoming of maven. Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: What user friendliness are you talking about? --jason On Jul 5, 2006, at 2:25 AM, anita kulshreshtha wrote: I would also prefer to see any changes to improve the maintainability and user friendliness of M2 build be held off until the server assembly is functional. Thanks Anita --- David Jencks [EMAIL PROTECTED] wrote: On Jul 5, 2006, at 12:25 AM, John Sisson wrote: Jacek Laskowski wrote: On 7/3/06, Jason Dillon [EMAIL PROTECTED] wrote: NOTE... the m2 build in trunk is already broken... this patches help FIX MANY OF THOSE PROBLEMS! NOTED, but... it's not broken. it has never worked so we can pretend to call it broken. It's a small, but important point we cannot dismiss. Since the official build is still m1 and this will not affect the m1 build, I don't see why your point about breakage is applicable at all. ... When I first created the m1 build for Geronimo years ago there were certainly a few moments of breakage due to build changes, but since there was no commit by committee junk going on then it was easy to just fix when things happened to get a bit askew. The branch idea was just to make it easier to actually make progress, as I am move on this stuff way way faster than the lot of you can react to emails and JIRAs which often (as this one did) need several sets of emails to clarify. That's the point in RTC - discussing, discussing, over and over again. I'm not in favour of RTC, but some of its rules are fine. It fosters discussions we lacked. That's the main point of RTC. Isn't it funny that you've mentioned it as an argument against RTC? What's wrong with committing changes made in the branch back to trunk once they've been tested? My proposal is not to wait until the migration is done, but rather apply it in small portions, gradually. It should work, shouldn't it? I'd greatly appreciate your comment on it as I guess I don't see the whole picture and keep thinking the branch might help when others have already seen it would fall short. Can we avoid the concerns that have been aired regarding svn merging issues when directories are reorganised by leaving the reorganization of directories as a last phase of the m2 migration? I would have thought that we could move further along with the migration without reorganizing directories (AFAIK, maven should be able to work with existing directory structures, although doing so may incur more work). We would also need to coordinate the reorganization of directories with the owners of other branches from trunk, to minimize the impact on them. I would prefer to wait to reorganize the directories until after the work in the dead-1.2 branch is merged with trunk. I plan to go back to this activity now. Other committers may wish to note that merging the work in dead-1.2 should not need RTC as it is already part of a main development line. thanks david jencks John --jason Jacek __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Additions to the Apache Geronimo project management ctte
Congratulations! Matt and Jeff Cheers Anita --- Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 5, 2006, at 1:32 PM, Rodent of Unusual Size wrote: Last week the PMC voted to invite Jeff Genender and Matt Hogstrom to join it. Both have accepted the invitation and will be part of the team responsible for overseeing the healthy development of the project. Welcome, Matt Jeff! - -- #kenP-)} Congratulation! -dain __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: OSCON Geronimo BOF Scheduled
Matt, I'll be there. I seem to be becoming a conference addict :-) cheers Jan Matt Hogstrom wrote: For those committers that will be at the OSCON Conference we have a BOF scheduled. It is: Your BoF for OSCON 2006 has been scheduled for: • Wednesday, July 26 • 7:30 pm - 8:30 pm • Location: D139-140 • BoF Name: New Features of Apache Geronimo 1.1 (including new plug-in capability) Who all will be at OSCON?
Re: Additions to the Apache Geronimo project management ctte
Cool ! Congrats guys ! Cheers Prasad On 7/6/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Congratulations! Matt and Jeff Cheers Anita --- Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 5, 2006, at 1:32 PM, Rodent of Unusual Size wrote: Last week the PMC voted to invite Jeff Genender and Matt Hogstrom to join it. Both have accepted the invitation and will be part of the team responsible for overseeing the healthy development of the project. Welcome, Matt Jeff! - -- #kenP-)} Congratulation! -dain __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
AMQ production status
Hi James We have our servers in C/C++. We are trying out available open source MQ services for maintaining persistent communication with our servers through our C++ and web clients. We tried the tests available for both Stomp and Openwire and got very little success with Stomp C++ (caught up with the persistency issue) and considerable with openwire C++ (I have an issue regarding this mailed to the mailing list on 06-July-2006). 1) Are both these C++ APIs (Stomp and Openwire) worth implementation and usage right now, or they are being made more ROBUST? 2) When can we see a PRODUCTION-able AMQ along with its full throttled APIs? Hearty Regards Naveen Rawat
[jira] Commented: (GERONIMO-2066) Openejb migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2066?page=comments#action_12419493 ] Anita Kulshreshtha commented on GERONIMO-2066: -- Oops! I named it openejb.patch. Use the latest patch. These patches are deceptive. The openejb builds even without them. When the jars are used to build Geronimo configs, the build fails. Prasad has been unable to build openejb configuraitons. This will be very helpful. Thanks! I think Jason has submitted a patch For G to use org.openejb groupId. This patch is a bug fix now. Because there is no 2.2 openejb with groupId openejb. Openejb migration to M2 --- Key: GERONIMO-2066 URL: http://issues.apache.org/jira/browse/GERONIMO-2066 Project: Geronimo Type: Sub-task Security: public(Regular issues) Environment: All Reporter: Anita Kulshreshtha Attachments: openejb.patch, openejb.patch, openejb.patch, openejb.patch The attached patch provides a local openejb build for Geronimo using o.a.g.modules groupId. This is to ensure that the latest openejb jars are available. The results for rev 2659 are below : Path: . URL: https://svn.codehaus.org/openejb/branches/v2_1/openejb2 Repository UUID: 2b0c1533-c60b-0410-b8bd-89f67432e5c6 Revision: 2659 Node Kind: directory Schedule: normal Last Changed Author: gdamour Last Changed Rev: 2659 Last Changed Date: 2006-05-27 08:00:16 -0400 (Sat, 27 May 2006) Properties Last Updated: 2006-05-26 19:05:28 -0400 (Fri, 26 May 2006) Todo - fix the test failures. APSHOT\openejb-builder-2.1-SNAPSHOT.jar [INFO] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] OpenEJB SUCCESS [3.953s] [INFO] OpenEJB :: Core SUCCESS [30.515s] [INFO] OpenEJB :: PK Generation :: Builder SUCCESS [9.297s] [INFO] OpenEJB :: Builder . SUCCESS [27.875s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 minute 12 seconds [INFO] Finished at: Mon May 29 08:11:40 EDT 2006 [INFO] Final Memory: 17M/53M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: AMQ production status
Hi Naveen, Comments inline ... -Original Message- From: Naveen Rawat [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 7:48 AM To: activemq-dev@geronimo.apache.org Subject: AMQ production status Hi James We have our servers in C/C++. We are trying out available open source MQ services for maintaining persistent communication with our servers through our C++ and web clients. We tried the tests available for both Stomp and Openwire and got very little success with Stomp C++ (caught up with the persistency issue) and considerable with openwire C++ (I have an issue regarding this mailed to the mailing list on 06-July-2006). Just out of curiosity, which Stomp C++ client did you try? The reason I ask is that we just submitted a replacement for the CMS client in activemq-cpp. This API does appear to have support for persistence, although I'm not sure that we have a unit test that verifies it yet. 1) Are both these C++ APIs (Stomp and Openwire) worth implementation and usage right now, or they are being made more ROBUST? The activemq-cpp is new and will be the beginning of creating a single C++ client that will support both stomp and openwire (you will be able to choose which protocol in the url). So, there is definitely activity in this area and they should continue to improve. 2) When can we see a PRODUCTION-able AMQ along with its full throttled APIs? I would try activemq-cpp, if you haven't already - it's leaps and bounds above the old CMS code! Hearty Regards Naveen Rawat Regards, Nate
Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
Please ignore this.. (hit send accidentally) Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: --- Jason Dillon [EMAIL PROTECTED] wrote: What user friendliness are you talking about? --jason On Jul 5, 2006, at 2:25 AM, anita kulshreshtha wrote: I would also prefer to see any changes to improve the maintainability and user friendliness of M2 build be held off until the server assembly is functional. Thanks Anita --- David Jencks [EMAIL PROTECTED] wrote: On Jul 5, 2006, at 12:25 AM, John Sisson wrote: Jacek Laskowski wrote: On 7/3/06, Jason Dillon [EMAIL PROTECTED] wrote: NOTE... the m2 build in trunk is already broken... this patches help FIX MANY OF THOSE PROBLEMS! NOTED, but... it's not broken. it has never worked so we can pretend to call it broken. It's a small, but important point we cannot dismiss. Since the official build is still m1 and this will not affect the m1 build, I don't see why your point about breakage is applicable at all. ... When I first created the m1 build for Geronimo years ago there were certainly a few moments of breakage due to build changes, but since there was no commit by committee junk going on then it was easy to just fix when things happened to get a bit askew. The branch idea was just to make it easier to actually make progress, as I am move on this stuff way way faster than the lot of you can react to emails and JIRAs which often (as this one did) need several sets of emails to clarify. That's the point in RTC - discussing, discussing, over and over again. I'm not in favour of RTC, but some of its rules are fine. It fosters discussions we lacked. That's the main point of RTC. Isn't it funny that you've mentioned it as an argument against RTC? What's wrong with committing changes made in the branch back to trunk once they've been tested? My proposal is not to wait until the migration is done, but rather apply it in small portions, gradually. It should work, shouldn't it? I'd greatly appreciate your comment on it as I guess I don't see the whole picture and keep thinking the branch might help when others have already seen it would fall short. Can we avoid the concerns that have been aired regarding svn merging issues when directories are reorganised by leaving the reorganization of directories as a last phase of the m2 migration? I would have thought that we could move further along with the migration without reorganizing directories (AFAIK, maven should be able to work with existing directory structures, although doing so may incur more work). We would also need to coordinate the reorganization of directories with the owners of other branches from trunk, to minimize the impact on them. I would prefer to wait to reorganize the directories until after the work in the dead-1.2 branch is merged with trunk. I plan to go back to this activity now. Other committers may wish to note that merging the work in dead-1.2 should not need RTC as it is already part of a main development line. thanks david jencks John --jason Jacek __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Errors while using Geronimo Eclipse Plugin RC2
Hi Sachin,I tried using WTP 1.5 and Eclipse 3.2. The problems mentioned earlier disappear and I am able to start/stop the server successfully.However after the server gets started, when I right click on the server, I see that Launch Geronimo Console is disabled. Isn't this a bug? Shall I open a JIRA for the same?I also observed that the .log file in my eclipse\workspace\.metadata directory has the following messages logged. Do you suspect any problem here?--!SESSION 2006-07-06 17:50: 17.529 ---eclipse.buildId=M20060629-1905java.version=1.4.2_08java.vendor=Sun Microsystems Inc.BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_USCommand-line arguments: -os win32 -ws win32 -arch x86 -clean !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'deployment' !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'naming'!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.534!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'web'-- - Shiva KumarOn 7/5/06, Sachin Patel [EMAIL PROTECTED] wrote: Can you retry using the callisto release (WTP 1.5, and Eclipse 3.2)?This is what the plugin is built on and supports.On Jul 5, 2006, at 9:05 AM, Shiva Kumar H R wrote: Hi, I am using http://people.apache.org/dist/geronimo/eclipse/unstable/ g-eclipse-plugin-1.1-RC2.zip with Eclipse 3.1.2 and WTP 1.0.2 (buildwtp-sdk-R-1.0.2-200604200208). 1) While defining a New Server, during this dialog New Apache Geronimo v1.1 Runtime: Please enter the directory where Geronimo is currently installed or where you would like it to be installed. as shown in attachment 1.GIF, once I specify the Application Server Installation Directory, the upper portion of the Dialog gets reduced in size leaving me unable to see the message/info there, as shown in attachment 2.GIF . Although this doesn't stop me from defining a new server, I miss out on the information which was displayed during that dialog. 2) After defining the server (I have the following server installed: Geronimo 1.1 with Jetty with Sun JDK 1.4.2_08), when I try to start the server, server does get started with the below messages in Console view: -- - ... 18:22:49,519 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/ remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=jsp because no targets are running for reference JettyServletRegistration matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,j2eeType=WebModule,name=geronimo/remote-deploy- jetty/1.1/car 18:22:49,649 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/ remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=file-upload because no targets are running for reference Previous matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,WebModule=geronimo/remote-deploy-jetty/1.1/ car,j2eeType=Servlet,name=404-error Geronimo startup complete -- - However the Servers view still shows the server status as Starting.. as shown in attachment 3.GIF. And after a while, an Error message Timeout waiting for Apache Geronimo 1.1 to start. Server did not start after 24s. (as shown in attachment 4.GIF) gets thrown. The .log file in eclipse\workspace \.metadata directory has the following messages logged: -- - !SESSION 2006-07-05 17:53:56.827 --- eclipse.buildId=M20060118-1600 java.version=1.4.2_08 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments:-os win32 -ws win32 -arch x86 !ENTRY org.eclipse.wst.server.core 4 0 2006-07-05 18:26:00.293 !MESSAGE Timeout waiting for Apache Geronimo 1.1 to start. Server did not start after 24s. -- - - Shiva Kumar 1.GIF 2.GIF 3.GIF 4.GIF-sachin
Fwd: Errors while using Geronimo Eclipse Plugin RC2
I intended to send my first mail to dev@geronimo.apache.org and copy user@geronimo.apache.org on the CC list. But mistakenly I CC'ed it to [EMAIL PROTECTED]. After that, I see some mails getting missed from the user list. I am sorry for the confusion caused. Now sending this mail to both dev user lists. Thx,Shiva Kumar-- Forwarded message --From: Shiva Kumar H R [EMAIL PROTECTED] Date: Jul 6, 2006 5:58 PMSubject: Re: Errors while using Geronimo Eclipse Plugin RC2To: dev@geronimo.apache.orgHi Sachin,I tried using WTP 1.5 and Eclipse 3.2. The problems mentioned earlier disappear and I am able to start/stop the server successfully.However after the server gets started, when I right click on the server, I see that Launch Geronimo Console is disabled. Isn't this a bug? Shall I open a JIRA for the same?I also observed that the .log file in my eclipse\workspace\.metadata directory has the following messages logged. Do you suspect any problem here?--!SESSION 2006-07-06 17:50: 17.529 ---eclipse.buildId=M20060629-1905java.version=1.4.2_08java.vendor=Sun Microsystems Inc.BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 -clean !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'deployment' !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'naming'!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.534!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'web'-- - Shiva KumarOn 7/5/06, Sachin Patel [EMAIL PROTECTED] wrote: Can you retry using the callisto release (WTP 1.5, and Eclipse 3.2)?This is what the plugin is built on and supports.On Jul 5, 2006, at 9:05 AM, Shiva Kumar H R wrote: Hi, I am using http://people.apache.org/dist/geronimo/eclipse/unstable/ g-eclipse-plugin-1.1-RC2.zip with Eclipse 3.1.2 and WTP 1.0.2 (buildwtp-sdk-R-1.0.2-200604200208). 1) While defining a New Server, during this dialog New Apache Geronimo v1.1 Runtime: Please enter the directory where Geronimo is currently installed or where you would like it to be installed. as shown in attachment 1.GIF, once I specify the Application Server Installation Directory, the upper portion of the Dialog gets reduced in size leaving me unable to see the message/info there, as shown in attachment 2.GIF . Although this doesn't stop me from defining a new server, I miss out on the information which was displayed during that dialog. 2) After defining the server (I have the following server installed: Geronimo 1.1 with Jetty with Sun JDK 1.4.2_08), when I try to start the server, server does get started with the below messages in Console view: -- - ... 18:22:49,519 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/ remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=jsp because no targets are running for reference JettyServletRegistration matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,j2eeType=WebModule,name=geronimo/remote-deploy- jetty/1.1/car 18:22:49,649 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/ remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=file-upload because no targets are running for reference Previous matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,WebModule=geronimo/remote-deploy-jetty/1.1/ car,j2eeType=Servlet,name=404-error Geronimo startup complete -- - However the Servers view still shows the server status as Starting.. as shown in attachment 3.GIF. And after a while, an Error message Timeout waiting for Apache Geronimo 1.1 to start. Server did not start after 24s. (as shown in attachment 4.GIF) gets thrown. The .log file in eclipse\workspace \.metadata directory has the following messages logged: -- - !SESSION 2006-07-05 17:53:56.827 ---
Re: Implementing Global JNDI
Hi David, I tried this and it works for Custom Resource Adapters. There is still a problem for Registering GBeans in Global JNDI through the builder ( ServiceConfigBuilder ). The Builder is a part of geronimo-gbean-deployer plan which is parent of j2ee-deployer. The geronimo-naming jars are loaded in j2ee-deployer. Hence we dont get access in ServiceConfigBuilder to GBeanReference thats part of naming. Currently all the binding GBeans are in naming package. So it works for all j2ee deployments. Is there a way to work around this ClassLoading problem heirarchy for binding GBeans through builder? Regards Krishnakumar On 6/28/06, David Jencks [EMAIL PROTECTED] wrote: I think there is a simpler solution, or perhaps I don't understand all the details of what you are proposing. I think if you give your binding gbeans the magic classLoader attribute everything will work. This will be set to the configuration classloader for the configuration the gbean is in, not the configuration the gbeans class is loaded in. This classloader should always have the necessary classes in it. thanks david jencks On Jun 28, 2006, at 12:39 AM, Manu George wrote: Hi, The problem we are facing regarding adapters is because the binding gbeans were added to the naming module of geronimo. We are planning to change this by creating a separate module for global jndi and then adding it as a dependency in the configuration that is getting deployed. This will be done in the builders. All the reference creation logic can also be moved to the gbeans.The Binding GBeans will then have access to application level classes as they will be loaded in the app class loader. We hope this approach will solve the current problem. We will post the code again after making these changes. Thanks Manu On 6/28/06, Krishnakumar B [EMAIL PROTECTED] wrote: Hi, We have created a JIRA (http://issues.apache.org/jira/browse/GERONIMO-2153 ) and attached the initial draft. We have tried two approaches. * Adding to plan * Deploying from Builder. The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag global-jndi/ in opene ejb plan. Resource Adapter and GBean have a gbean plan added to deployment plan. gbean name=JMSQueueFactoryJNDIBindingGBean class=org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean attribute name=configIdtest/jms.rar/1.0/rar/attribute attribute name=jndiNameglobalJMSQueueFactory/attribute attribute name=componentNameJMSQueueFactory/attribute attribute name=j2eeTypeJCAManagedConnectionFactory/attribute attribute name=interfaceNameorg.apache.geronimo.jms.connector.JMSQueueConnectionFactory/attribute /gbean and gbean name=TestGBeanJNDIBindingGBean class=org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean attribute name=configIdtest/gbean/1.0/car/attribute attribute name=jndiNameglobalTestGBean/attribute attribute name=componentNameTestGBean/attribute attribute name=j2eeTypeGBean/attribute attribute name=classNamegbean.test.TestGBean/attribute /gbean We have a Classloading issue when trying to maintain all the BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource Adapters that are not J2EE interfaces like javax.sql.DataSource / javax.jms.QueueConnectionFactory we get a ClassNotFound as the class is not available at Classloader of rmi-naming. We spent a lot of time trying to solve this issue but are not able to find a solution as the application level interface or class is not available. This problem will not occur for j2ee interfaces like DataSource, EJB interfaces, Queue, Topic etc.. If the approach is correct we would like to add the other features to make this more suitable for adding into the product. Regards Krishnakumar B On 6/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 6/23/06, Krishnakumar B [EMAIL PROTECTED] wrote: The plan needs to have some XML Tag to say this resource needs to gets into Global JNDI and the builder can then add it to geronimo: Context. This is not implemented yet. Currently if we deploy a connector it gets in global jndi. I might've misunderstood it, but isn't Global JNDI == geronimo: context == global: context? If so, why is this copying from Global JNDI to the geronimo: namespace? Looking forward to seeing your patch for it. Just as Guillaume suggested, please create an JIRA issue and attach the patch to it. Krishnakumar B Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Created: (AMQ-798) provide a new JMS header to indiciate the first message in a sequence being dispatched to a consumer
provide a new JMS header to indiciate the first message in a sequence being dispatched to a consumer Key: AMQ-798 URL: https://issues.apache.org/activemq/browse/AMQ-798 Project: ActiveMQ Type: New Feature Reporter: james strachan Assigned to: james strachan This would allow consumers to listen for this message and if the boolean is set its the first message being dispatched for a group so the consumer could flush a cache or something -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How do we build the Eclipse Plugin assembly?
Hi Sachin,Thanks for pointing out those areas where I can start contributing. I will look at the code for Form page editors for deployment plans and Wizards. I will start a separate discussion thread on them. Meanwhile I will also see if I can fix some of the JIRAs in GeronimoDevtools. - ShivaOn 7/5/06, Sachin Patel [EMAIL PROTECTED] wrote: Hi Shiva,On Jul 3, 2006, at 2:56 AM, Shiva Kumar H R wrote: Hi Sachin, I too am facing the same problem as Donald during the assembly of Eclipse Plugin. I am building Revision 418691 of the trunk, using Sun JDK 1.4.2_08 Maven 2.0.4 on a WinXP sp2 machine.Ok, I'll see if I can reproduce on another machine and dig into it. By the way, I am interested in contributing to Geronimo Eclipse Plugin. Last year I have done some work on Eclipse Plugin Development and I am comfortable with SWT, JFace and Plugin Development. Also, some of the work I did in Eclipse Drag and Drop got published here: http://www-128.ibm.com/developerworks/library/ os-ecl-dragdrop/index.htmlGreat! SWT and JFace experience is definitely something we coulduse.So one of the big things we need coverage on is providing Form Page editors for our deployment plans.Currently if you double clickfor example on the geronimo-web.xml it will open up a form editor.You will see that the coverage is currently very minimal and due tomy lack of UI creativity many of the tables and such look exactly the same. :)The wizards are also very primative and we desperately needto enhance these.So if you're interested this would be a greatplace to contribute.This would also help you get a goodunderstanding of each of the geronimo deployment plans. Last one week I have been browsing through the Geronimo Dev Mailing Lists, as well as JIRA, to figure out how I can contribute to the Eclipse plugin development. If you can point me to a few to-do items of immediate interest, I would be more than happy to pick them up and start working on them right away. Thanks, Shiva Kumar On 7/1/06, Sachin Patel [EMAIL PROTECTED] wrote: You have to invoke it manually as you've done.I haven't figured out how to invoke a build+assembly in one step.As far as the file sizes kevan saw the same problem, and we couldn't figure out why. On Jun 30, 2006, at 5:15 PM, Donald Woods wrote: I just checked out Rev418113 of the Eclipse plugin trunk, started with a clean m2 repo and successfully got a mvn install to complete after several attempts. But, when I look in the assembly/ directory, no target/ directory was created.Is this expected? When I ran mvn from the assembly directory, it created a target directory, but the following zipfiles were only 22 bytes each - g-eclipse-plugin-1.1-deployable.zip g-eclipse-plugin-1.1-updatesite.zip I'm building on WinXP with Maven 2.0.4 and Sun Java 1.4.2_12-b03.-Donald -sachin-sachin-- Thanks, Shiva Kumar
RE: AMQ production status
Hi Nate Thanks for the information. Just out of curiosity, which Stomp C++ client did you try? The reason I ask is that we just submitted a replacement for the CMS client in activemq-cpp. This API does appear to have support for persistence, although I'm not sure that we have a unit test that verifies it yet. We are using the main.cpp file that comes in /test along with the Stomp C++ APIs from svn : https://svn.apache.org/repos/asf/incubator/activemq/trunk/cms. We have segregated the main.cpp into a sender and a receiver. 1) From where can I get the fresh CMS replacement as told by you. Can you provide the specific location? I would try activemq-cpp, if you haven't already - it's leaps and bounds above the old CMS code! 2) I am using ActiveMQ 4.0.x java version. Is activemq-cpp a C++ MQ server? If, then what's its capacity against Java, .Net clients. Hearty Regards Naveen Rawat
RE: AMQ production status
Comments inline: Just out of curiosity, which Stomp C++ client did you try? The reason I ask is that we just submitted a replacement for the CMS client in activemq-cpp. This API does appear to have support for persistence, although I'm not sure that we have a unit test that verifies it yet. We are using the main.cpp file that comes in /test along with the Stomp C++ APIs from svn : https://svn.apache.org/repos/asf/incubator/activemq/trunk/cms. We have segregated the main.cpp into a sender and a receiver. 1) From where can I get the fresh CMS replacement as told by you. Can you provide the specific location? The CMS replacement is called activemq-cpp and its located here: https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp It is still under active development by Nathan and me. I would try activemq-cpp, if you haven't already - it's leaps and bounds above the old CMS code! 2) I am using ActiveMQ 4.0.x java version. Is activemq-cpp a C++ MQ server? If, then what's its capacity against Java, .Net clients. Activemq-cpp is a c++ implementation of the JMS Client API, currently it only speaks the stomp protocol, but in time it should also gain the ability to use the openwire protocol as well. You still need to run an AMQ broker just as you did before. The tests in the test-integration folder show example usage, which is now very much like using the Java based JMS client API. - Timothy A. Bish Sensis Corporation -
[RTC] Vote on GERONIMO-2161 - restart 1
+1 to getting this patch in... I spent some time working with Jason and Jacek last night on this patch. It is fairly large and reaching. There appears to be an issue with SVN creating a bad patch file for several files but I don't believe this is Jason's issue but rather with SVN. There are 5 failed hunks in the v5 patch. I manually copied the files from branches/m2migration into trunk as these were the source of the modification. The build was successful and I understand what Jason is doing here. I am giving this patch a +1 and would like to see Jason get this applied at his earliest convenience. There are issues with moving forward but getting on a better code base will accelerate progress on getting to a fully integrated build. We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. I would like to see Jason get these changes into trunk as well as resolve the patch issue. Matt *** Notations of applicability *** Here is the output from the patch when I applied it. I increased the FUZZ factor to a horrible 8 but it had no effect. hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l ~/Downloads/GERONIMO-2161-v5.patch.txt patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/online-deployer/pom.xml patching file configs/j2ee-deployer/pom.xml patching file configs/tomcat-deployer/pom.xml patching file configs/activemq/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/geronimo-gbean-deployer/pom.xml patching file configs/shutdown/pom.xml patching file configs/hot-deployer/pom.xml patching file configs/servlets-examples-jetty/pom.xml patching file configs/jetty-deployer/pom.xml patching file configs/openejb/pom.xml patching file configs/unavailable-webservices-deployer/pom.xml patching file configs/axis-deployer/pom.xml patching file configs/system-database/pom.xml patching file configs/ldap-demo-tomcat/pom.xml patching file configs/upgrade/pom.xml patching file configs/welcome-jetty/pom.xml patching file configs/j2ee-security/pom.xml patching file configs/upgrade-cli/pom.xml patching file configs/rmi-naming/pom.xml patching file configs/ldap-demo-jetty/pom.xml patching file configs/client-deployer/pom.xml patching file configs/client-corba/src/plan/plan.xml Hunk #2 succeeded at 17 with fuzz 2. patching file configs/client-corba/pom.xml patching file configs/axis/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/j2ee-system/pom.xml patching file
Re: openejb itests?
Hi Prasad, First we needed the geronimo-deployment-plugin to be in m2. So in http://issues.apache.org/jira/browse/GERONIMO-1738, I got the deployment-plugin migarted to m2. The RTC for this is pending 2 more votes. Now, if you and Jason can review and approve it, we can get it in the build. I applied the patch but it appears that there is a problem with it, AppTest.java has 3 copies of the code in it for example (as well as pom.xml and many if not all the other files). Here is the url to what I downloaded and I'm looking at; http://issues.apache.org/jira/secure/attachment/12324416/geronimo- deployment-plugin.patch which is the first patch from JIRA #1738 referenced above. Next, I came up with a simple m2 multi-build project for itests. Jacek put it in the sandbox for us. http://issues.apache.org/jira/browse/GERONIMO-1654. (I think I also opened some JIRAs in OpenEJB project with itest patches. Let me search for those). Sounds good, looking forward to reviewing the jira's. I used to take an m1 binary distribution and manually put it into an m2 local repo for this work. Now that we are working on m2, hopefully we shall soon have the binary distributions for us to work with directly. An m1 distribution of G or something else? We could then to try to bring itests out of the sandbox and merge it with trunk. The vision I have for itests is to make it the all encompassing system integration test for Geronimo. We have unit tests in the individual modules. Even that covers only a third of our code approx. Then we have the J2EE CTK tests that ensures G's J2EE compliance. But geronimo being a sum of many individual parts, there must be a whole range of tests that are applicable to the whole system when put together but fall beyond the purview of CTK. These are what I hope itests will catch. Agreed that having more tests would be a very 'good thing' I began playing with itests but quickly moved on the m2 migration work since that was so much necessary both for G and for itests. It would be nice to get the itests running and into the project soon. agreed TTFN, -bd- Cheers Prasad. On 7/5/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Prasad, I would like to see the itests for openejb running from m2. David mentioned that you might have already done a bunch of work on that front. Could you update me on the status of that? I'm happy to jump in where ever to help make them functional again. Thanks! Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html
Re: Errors while using Geronimo Eclipse Plugin RC2
On Jul 6, 2006, at 8:28 AM, Shiva Kumar H R wrote: Hi Sachin, I tried using WTP 1.5 and Eclipse 3.2. The problems mentioned earlier disappear and I am able to start/stop the server successfully. However after the server gets started, when I right click on the server, I see that Launch Geronimo Console is disabled. Isn't this a bug? Shall I open a JIRA for the same? Yes, I noticed this as well, please open a JIRA. I also observed that the .log file in my eclipse\workspace \.metadata directory has the following messages logged. Do you suspect any problem here? No this is ok and just a warning. I can't remove the duplicate extensions because they are being inserted automatically by EMF during the build. -- !SESSION 2006-07-06 17:50: 17.529 --- eclipse.buildId=M20060629-1905 java.version=1.4.2_08 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 -clean !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524 !MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'deployment' !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524 !MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'naming' !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.534 !MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'web' -- - Shiva Kumar On 7/5/06, Sachin Patel [EMAIL PROTECTED] wrote: Can you retry using the callisto release (WTP 1.5, and Eclipse 3.2)? This is what the plugin is built on and supports. On Jul 5, 2006, at 9:05 AM, Shiva Kumar H R wrote: Hi, I am using http://people.apache.org/dist/geronimo/eclipse/unstable/ g-eclipse-plugin-1.1-RC2.zip with Eclipse 3.1.2 and WTP 1.0.2 (build wtp-sdk-R-1.0.2-200604200208). 1) While defining a New Server, during this dialog New Apache Geronimo v1.1 Runtime: Please enter the directory where Geronimo is currently installed or where you would like it to be installed. as shown in attachment 1.GIF, once I specify the Application Server Installation Directory, the upper portion of the Dialog gets reduced in size leaving me unable to see the message/info there, as shown in attachment 2.GIF . Although this doesn't stop me from defining a new server, I miss out on the information which was displayed during that dialog. 2) After defining the server (I have the following server installed: Geronimo 1.1 with Jetty with Sun JDK 1.4.2_08), when I try to start the server, server does get started with the below messages in Console view: -- - ... 18:22:49,519 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/ remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=jsp because no targets are running for reference JettyServletRegistration matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,j2eeType=WebModule,name=geronimo/remote-deploy- jetty/1.1/car 18:22:49,649 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/ remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=file-upload because no targets are running for reference Previous matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,WebModule=geronimo/remote-deploy-jetty/1.1/ car,j2eeType=Servlet,name=404-error Geronimo startup complete -- - However the Servers view still shows the server status as Starting.. as shown in attachment 3.GIF. And after a while, an Error message Timeout waiting for Apache Geronimo 1.1 to start. Server did not start after 24s. (as shown in attachment 4.GIF) gets thrown. The .log file in eclipse\workspace \.metadata directory has the following messages logged: -- - !SESSION 2006-07-05 17:53:56.827 --- eclipse.buildId=M20060118-1600 java.version=1.4.2_08 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line
Re: How do we build the Eclipse Plugin assembly?
Great! We look forward to your contributions. On Jul 6, 2006, at 9:16 AM, Shiva Kumar H R wrote: Hi Sachin, Thanks for pointing out those areas where I can start contributing. I will look at the code for Form page editors for deployment plans and Wizards. I will start a separate discussion thread on them. Meanwhile I will also see if I can fix some of the JIRAs in GeronimoDevtools. - Shiva On 7/5/06, Sachin Patel [EMAIL PROTECTED] wrote: Hi Shiva, On Jul 3, 2006, at 2:56 AM, Shiva Kumar H R wrote: Hi Sachin, I too am facing the same problem as Donald during the assembly of Eclipse Plugin. I am building Revision 418691 of the trunk, using Sun JDK 1.4.2_08 Maven 2.0.4 on a WinXP sp2 machine. Ok, I'll see if I can reproduce on another machine and dig into it. By the way, I am interested in contributing to Geronimo Eclipse Plugin. Last year I have done some work on Eclipse Plugin Development and I am comfortable with SWT, JFace and Plugin Development. Also, some of the work I did in Eclipse Drag and Drop got published here: http://www-128.ibm.com/developerworks/library/ os-ecl-dragdrop/index.html Great! SWT and JFace experience is definitely something we could use. So one of the big things we need coverage on is providing Form Page editors for our deployment plans. Currently if you double click for example on the geronimo-web.xml it will open up a form editor. You will see that the coverage is currently very minimal and due to my lack of UI creativity many of the tables and such look exactly the same. :) The wizards are also very primative and we desperately need to enhance these. So if you're interested this would be a great place to contribute. This would also help you get a good understanding of each of the geronimo deployment plans. Last one week I have been browsing through the Geronimo Dev Mailing Lists, as well as JIRA, to figure out how I can contribute to the Eclipse plugin development. If you can point me to a few to-do items of immediate interest, I would be more than happy to pick them up and start working on them right away. Thanks, Shiva Kumar On 7/1/06, Sachin Patel [EMAIL PROTECTED] wrote: You have to invoke it manually as you've done. I haven't figured out how to invoke a build+assembly in one step. As far as the file sizes kevan saw the same problem, and we couldn't figure out why. On Jun 30, 2006, at 5:15 PM, Donald Woods wrote: I just checked out Rev418113 of the Eclipse plugin trunk, started with a clean m2 repo and successfully got a mvn install to complete after several attempts. But, when I look in the assembly/ directory, no target/ directory was created. Is this expected? When I ran mvn from the assembly directory, it created a target directory, but the following zipfiles were only 22 bytes each - g-eclipse-plugin-1.1-deployable.zip g-eclipse-plugin-1.1-updatesite.zip I'm building on WinXP with Maven 2.0.4 and Sun Java 1.4.2_12-b03. -Donald -sachin -sachin -- Thanks, Shiva Kumar -sachin
[jira] Created: (GERONIMODEVTOOLS-89) Can't use Launch Geronimo Console after right clicking on Server, with Eclipse Plugin 1.1 RC2
Can't use Launch Geronimo Console after right clicking on Server, with Eclipse Plugin 1.1 RC2 --- Key: GERONIMODEVTOOLS-89 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-89 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Versions: 1.1.0 Environment: Eclipse Plugin 1.1 RC2, Geronimo 1.1, WTP 1.5, Eclipse 3.2, WinXP sp2 on an Intel32 desktop. Reporter: Shiva Kumar H R I am using Geronimo Eclipse Plugin RC2 (available from http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-RC2.zip) with Eclipse 3.2 and WTP 1.5 (build wtp-sdk-R-1.5.0-200606281455.zip). I am able to define a new server and start/stop the server successfully. However after the server gets started, when I right click on the server, I see that Launch Geronimo Console is disabled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: openejb itests?
Hi Bill, Inline- On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Prasad, First we needed the geronimo-deployment-plugin to be in m2. So in http://issues.apache.org/jira/browse/GERONIMO-1738, I got the deployment-plugin migarted to m2. The RTC for this is pending 2 more votes. Now, if you and Jason can review and approve it, we can get it in the build. I applied the patch but it appears that there is a problem with it, AppTest.java has 3 copies of the code in it for example (as well as pom.xml and many if not all the other files). Here is the url to what I downloaded and I'm looking at; http://issues.apache.org/jira/secure/attachment/12324416/geronimo- deployment-plugin.patch which is the first patch from JIRA #1738 referenced above. You might want to pick up the latest patch from the Manage Attachments link. The patches on the JIRA page are sorted alphabetically. The patch that you downloaded was my initial submission. The other one with ( http://issues.apache.org/jira/secure/attachment/12335875/geronimo-deployment-plugin-RTC-VOTE.2.patch ) is what you need. This was uploaded by David Jencks after reviewing mine and making some changes based on other reviews. I used to take an m1 binary distribution and manually put it into an m2 local repo for this work. Now that we are working on m2, hopefully we shall soon have the binary distributions for us to work with directly. An m1 distribution of G or something else? Yes, of G. Cheers Prasad
Re: [RTC] Vote on GERONIMO-2161 - restart 1
I get similar issues, but upon carefully reviewing the patch(es), I am in full agreement. +1 to the patch. Jeff Matt Hogstrom wrote: +1 to getting this patch in... I spent some time working with Jason and Jacek last night on this patch. It is fairly large and reaching. There appears to be an issue with SVN creating a bad patch file for several files but I don't believe this is Jason's issue but rather with SVN. There are 5 failed hunks in the v5 patch. I manually copied the files from branches/m2migration into trunk as these were the source of the modification. The build was successful and I understand what Jason is doing here. I am giving this patch a +1 and would like to see Jason get this applied at his earliest convenience. There are issues with moving forward but getting on a better code base will accelerate progress on getting to a fully integrated build. We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. I would like to see Jason get these changes into trunk as well as resolve the patch issue. Matt *** Notations of applicability *** Here is the output from the patch when I applied it. I increased the FUZZ factor to a horrible 8 but it had no effect. hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l ~/Downloads/GERONIMO-2161-v5.patch.txt patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/online-deployer/pom.xml patching file configs/j2ee-deployer/pom.xml patching file configs/tomcat-deployer/pom.xml patching file configs/activemq/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/geronimo-gbean-deployer/pom.xml patching file configs/shutdown/pom.xml patching file configs/hot-deployer/pom.xml patching file configs/servlets-examples-jetty/pom.xml patching file configs/jetty-deployer/pom.xml patching file configs/openejb/pom.xml patching file configs/unavailable-webservices-deployer/pom.xml patching file configs/axis-deployer/pom.xml patching file configs/system-database/pom.xml patching file configs/ldap-demo-tomcat/pom.xml patching file configs/upgrade/pom.xml patching file configs/welcome-jetty/pom.xml patching file configs/j2ee-security/pom.xml patching file configs/upgrade-cli/pom.xml patching file configs/rmi-naming/pom.xml patching file configs/ldap-demo-jetty/pom.xml patching file configs/client-deployer/pom.xml patching file configs/client-corba/src/plan/plan.xml
[jira] Resolved: (GERONIMODEVTOOLS-89) Can't use Launch Geronimo Console after right clicking on Server, with Eclipse Plugin 1.1 RC2
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-89?page=all ] Sachin Patel resolved GERONIMODEVTOOLS-89: -- Fix Version: 1.1.0 Resolution: Fixed Assign To: Sachin Patel This should be fixed now. Can't use Launch Geronimo Console after right clicking on Server, with Eclipse Plugin 1.1 RC2 --- Key: GERONIMODEVTOOLS-89 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-89 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Versions: 1.1.0 Environment: Eclipse Plugin 1.1 RC2, Geronimo 1.1, WTP 1.5, Eclipse 3.2, WinXP sp2 on an Intel32 desktop. Reporter: Shiva Kumar H R Assignee: Sachin Patel Fix For: 1.1.0 I am using Geronimo Eclipse Plugin RC2 (available from http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-RC2.zip) with Eclipse 3.2 and WTP 1.5 (build wtp-sdk-R-1.5.0-200606281455.zip). I am able to define a new server and start/stop the server successfully. However after the server gets started, when I right click on the server, I see that Launch Geronimo Console is disabled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2163) WADI Integration for Jetty
[ http://issues.apache.org/jira/browse/GERONIMO-2163?page=all ] Gianny Damour updated GERONIMO-2163: Attachment: geronimo.patch Refreshed Geronimo patch against trunk WADI Integration for Jetty -- Key: GERONIMO-2163 URL: http://issues.apache.org/jira/browse/GERONIMO-2163 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assignee: Gianny Damour Priority: Minor Attachments: geronimo-wadi-integration-preview.patch, geronimo.patch, wadi-geronimo-integration-preview.patch Email sent to the dev@ list. Hi, I have been working on a second integration attempt of WADI and I am posting here a high-level description of the current state of progress such that people can jump in. At this stage, this is a Jetty only attempt and I do believe that the same approach can be applied for Tomcat. The current integration provides (very unreliable) HttpSession state migration. It only works for a single Web-application; more effort is required on the WADI side to support multiple Web-applications and this will not impact the integration piece of code. I (more or less successfully) tested the integration with mod_proxy + mod_proxy_balancer and mod_proxy + mod_rewrite in front of three Geronimo servers running the WADI demo web-app. The code changes are: * new module to capture some clustering contracts - geronimo-clustering: there Node, SessionManager, Session and ClusteredInvocation are defined. * new module to provide a WADI implementation of the above - geronimo-clustering-wadi; * new module to capture clustering builder contracts - geronimo-clustering-builder: there is only one interesting interface JettyClusteringBuilder. This later defines a couple of methods to augment the environment of a Web module being built and add clustering specific GBeans; * new module to provide a WADI implementation of the above - Geronimo-clustering-builder-wadi; and * geronimo-jetty-builder and geronimo-jetty are impacted to hook in clustering. These two modules depend on geronimo-clustering and geronimo-clustering-builder and not on WADI specific modules. Two new modules are added: * jetty-clustering- wadi: this module defines default WADI GBeans such as Dispatcher, ReplicationManagerFactory, BackingStrategyFactory et cetera; and * jetty-clustering-builder-wadi: this module defines a builder to process Jetty DD and add various GBeans to the module being built. I think that the implementation is flexible enough to plug in another clustering implementation such as Kache. As a matter of fact, there are some severe reliability (e.g. locking issues) and integration (only one Web-app can be clustered) issues, which need to be fixed. So, this work is not yet ready to be RTC voted. Having said that, I have opened a JIRA such that people can have a look to the integration. Thanks, Gianny -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2163) WADI Integration for Jetty
[ http://issues.apache.org/jira/browse/GERONIMO-2163?page=all ] Gianny Damour updated GERONIMO-2163: Attachment: wadi.patch Refreshed WADI patch. WADI Integration for Jetty -- Key: GERONIMO-2163 URL: http://issues.apache.org/jira/browse/GERONIMO-2163 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assignee: Gianny Damour Priority: Minor Attachments: geronimo-wadi-integration-preview.patch, geronimo.patch, wadi-geronimo-integration-preview.patch, wadi.patch Email sent to the dev@ list. Hi, I have been working on a second integration attempt of WADI and I am posting here a high-level description of the current state of progress such that people can jump in. At this stage, this is a Jetty only attempt and I do believe that the same approach can be applied for Tomcat. The current integration provides (very unreliable) HttpSession state migration. It only works for a single Web-application; more effort is required on the WADI side to support multiple Web-applications and this will not impact the integration piece of code. I (more or less successfully) tested the integration with mod_proxy + mod_proxy_balancer and mod_proxy + mod_rewrite in front of three Geronimo servers running the WADI demo web-app. The code changes are: * new module to capture some clustering contracts - geronimo-clustering: there Node, SessionManager, Session and ClusteredInvocation are defined. * new module to provide a WADI implementation of the above - geronimo-clustering-wadi; * new module to capture clustering builder contracts - geronimo-clustering-builder: there is only one interesting interface JettyClusteringBuilder. This later defines a couple of methods to augment the environment of a Web module being built and add clustering specific GBeans; * new module to provide a WADI implementation of the above - Geronimo-clustering-builder-wadi; and * geronimo-jetty-builder and geronimo-jetty are impacted to hook in clustering. These two modules depend on geronimo-clustering and geronimo-clustering-builder and not on WADI specific modules. Two new modules are added: * jetty-clustering- wadi: this module defines default WADI GBeans such as Dispatcher, ReplicationManagerFactory, BackingStrategyFactory et cetera; and * jetty-clustering-builder-wadi: this module defines a builder to process Jetty DD and add various GBeans to the module being built. I think that the implementation is flexible enough to plug in another clustering implementation such as Kache. As a matter of fact, there are some severe reliability (e.g. locking issues) and integration (only one Web-app can be clustered) issues, which need to be fixed. So, this work is not yet ready to be RTC voted. Having said that, I have opened a JIRA such that people can have a look to the integration. Thanks, Gianny -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. Don't we have it behind us already? I thought we agreed upon the fact that unix patch is incompatible with svn diff and thus we need to use svn diff to create a patch for review and merge it to our own local copies using svn merge. The point is to get the revisions a patch is built from, but the rest should work. I would like to see Jason get these changes into trunk as well as resolve the patch issue. (Oh, poor Jacek and his poor English that doesn't let him explain how we should proceed :-)) To be honest, I don't like how the patch has been reviewed and voted. How can we say it works if we (me, including) couldn't apply it to our local source copies? If one's going to say it's because of the unix patch I'll start screaming...That's why svn merge exists, doesn't it? Ok, stop whining... I wonder how the changes will be applied to trunk if patch doesn't work? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Assigned: (AMQ-797) ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets
[ https://issues.apache.org/activemq/browse/AMQ-797?page=all ] Nathan Mittler reassigned AMQ-797: -- Assign To: Nathan Mittler ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets -- Key: AMQ-797 URL: https://issues.apache.org/activemq/browse/AMQ-797 Project: ActiveMQ Type: Bug Components: CMS Environment: Windows Mingw GNU builds Reporter: Timothy Bish Assignee: Nathan Mittler Priority: Minor Attachments: patch-makefile-windows-debug.txt, patch-makefile-windows-release.txt Original Estimate: 1 minute Remaining: 1 minute The windows makefiles for the MinGW targets fail to link the test and test-integration targets. When the code was submitted the makefiles were changed to build the library with the libactivemq-cpp.a name, but the windows makefiles still try and link the tests against libactivemq.a -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Errors while using Geronimo Eclipse Plugin RC2
As far as the UI problem of the dialog size, can you open a JIRA and attach the screen shot to it. Also since you're the SWT/JFace expert :) if I point you to the code, would you be able to provide a quick fix? Thanks. On Jul 6, 2006, at 10:08 AM, Sachin Patel wrote: On Jul 6, 2006, at 8:28 AM, Shiva Kumar H R wrote: Hi Sachin, I tried using WTP 1.5 and Eclipse 3.2. The problems mentioned earlier disappear and I am able to start/stop the server successfully. However after the server gets started, when I right click on the server, I see that Launch Geronimo Console is disabled. Isn't this a bug? Shall I open a JIRA for the same? Yes, I noticed this as well, please open a JIRA. I also observed that the .log file in my eclipse\workspace \.metadata directory has the following messages logged. Do you suspect any problem here? No this is ok and just a warning. I can't remove the duplicate extensions because they are being inserted automatically by EMF during the build. - - !SESSION 2006-07-06 17:50: 17.529 --- eclipse.buildId=M20060629-1905 java.version=1.4.2_08 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 -clean !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524 !MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'deployment' !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524 !MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'naming' !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.534 !MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'web' - - - Shiva Kumar On 7/5/06, Sachin Patel [EMAIL PROTECTED] wrote: Can you retry using the callisto release (WTP 1.5, and Eclipse 3.2)? This is what the plugin is built on and supports. On Jul 5, 2006, at 9:05 AM, Shiva Kumar H R wrote: Hi, I am using http://people.apache.org/dist/geronimo/eclipse/unstable/ g-eclipse-plugin-1.1-RC2.zip with Eclipse 3.1.2 and WTP 1.0.2 (build wtp-sdk-R-1.0.2-200604200208). 1) While defining a New Server, during this dialog New Apache Geronimo v1.1 Runtime: Please enter the directory where Geronimo is currently installed or where you would like it to be installed. as shown in attachment 1.GIF, once I specify the Application Server Installation Directory, the upper portion of the Dialog gets reduced in size leaving me unable to see the message/info there, as shown in attachment 2.GIF . Although this doesn't stop me from defining a new server, I miss out on the information which was displayed during that dialog. 2) After defining the server (I have the following server installed: Geronimo 1.1 with Jetty with Sun JDK 1.4.2_08), when I try to start the server, server does get started with the below messages in Console view: - - - ... 18:22:49,519 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car? J2EEApplication=null,WebModule=geronimo/ remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=jsp because no targets are running for reference JettyServletRegistration matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,j2eeType=WebModule,name=geronimo/remote- deploy- jetty/1.1/car 18:22:49,649 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car? J2EEApplication=null,WebModule=geronimo/ remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=file-upload because no targets are running for reference Previous matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,WebModule=geronimo/remote-deploy-jetty/1.1/ car,j2eeType=Servlet,name=404-error Geronimo startup complete - - - However the Servers view still shows the server status as Starting.. as shown in attachment 3.GIF. And after a while, an Error message Timeout waiting for Apache Geronimo 1.1 to start. Server did not start after 24s. (as shown in attachment 4.GIF) gets thrown. The .log file in eclipse\workspace \.metadata directory has the following messages logged: - -
How were the Geronimo 1.0 and 1.1 artifacts published to a Maven2 Repo?
For Geronimo 1.1, both of the Eclipse plugin and Daytrader sample require valid Maven2 POM files in order to determine the dependencies/imports when building, so how were these created from the current Maven1 based Geronimo 1.0 and 1.1 builds? Is there a way we can automate this for our local Geronimo 1.1.1-SNAPSHOT builds? -Donald smime.p7s Description: S/MIME Cryptographic Signature
[jira] Commented: (AMQ-797) ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets
[ https://issues.apache.org/activemq/browse/AMQ-797?page=comments#action_36530 ] Nathan Mittler commented on AMQ-797: Tim, I've applied the patch ... give it a try and make sure everything is as it should be. Thanks, Nate ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets -- Key: AMQ-797 URL: https://issues.apache.org/activemq/browse/AMQ-797 Project: ActiveMQ Type: Bug Components: CMS Environment: Windows Mingw GNU builds Reporter: Timothy Bish Assignee: Nathan Mittler Priority: Minor Attachments: patch-makefile-windows-debug.txt, patch-makefile-windows-release.txt Original Estimate: 1 minute Remaining: 1 minute The windows makefiles for the MinGW targets fail to link the test and test-integration targets. When the code was submitted the makefiles were changed to build the library with the libactivemq-cpp.a name, but the windows makefiles still try and link the tests against libactivemq.a -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
M2 assembly question
Is it better to have an separate assembly module that generates the assemblies or is it better to have the assembly plugin configured in the root pom? Currently in devtools I have it as a seperate module and use dependencySets to specify what gets included in the binaries. However as mentioned in earlier threads this is having problems working on one platform but not on another. I don't know if it would make a difference if I define the assembly config in the root POM and use moduleSets instead. I'm wanting to put out a vote on the release of the 1.1 version of the eclipse plugin but need to get this problem fixed as currently my machine seems to be the only machine in which the assembly generation seems to be working :(. -sachin
Derby/JMX and GBeans
Hi, I' writing JMX MBeans for Apache Derby and would like to know how Geronimo handles calls to normal MBeans and getPlatformMBean. One of my aims to make sure that Derby's MBeans integrate well into existing JMX enabled containers. Therefore, instead of starting a new MBean server for Derby, I would like to register Derby's MBeans in the containers MBeanServer. I looked at the Geronimo code and found that Derby is already implemented as a GBean which can be managed within Geronimo. However, the functionality is very limited. My MBeans expose much more stats about derby and provide a lot more configurability. I'm not very sure on this, but AFAIK, if I add MBeans to Derby via normal JMX calls, they will appear in JConsole, but distinct from Geronimo. Therefore, If I do want to make these as part of GBean management, I need to write wrapper calls around my MBeans and expose them as GBean calls? I have just started reading Geronimo's code and documentation and any help would be greatly appriciated. Thank you. Best Regards, Sanket Sharma
[jira] Commented: (AMQ-797) ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets
[ https://issues.apache.org/activemq/browse/AMQ-797?page=comments#action_36531 ] Timothy Bish commented on AMQ-797: -- I gave them a try, works fine now. ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets -- Key: AMQ-797 URL: https://issues.apache.org/activemq/browse/AMQ-797 Project: ActiveMQ Type: Bug Components: CMS Environment: Windows Mingw GNU builds Reporter: Timothy Bish Assignee: Nathan Mittler Priority: Minor Attachments: patch-makefile-windows-debug.txt, patch-makefile-windows-release.txt Original Estimate: 1 minute Remaining: 1 minute The windows makefiles for the MinGW targets fail to link the test and test-integration targets. When the code was submitted the makefiles were changed to build the library with the libactivemq-cpp.a name, but the windows makefiles still try and link the tests against libactivemq.a -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Implementing Global JNDI
See my comment in the jira about this, I don't think you need to use any naming References at all, nor do you need anything but a GBean reference to the appropriate GBean. http://issues.apache.org/jira/browse/GERONIMO-2153 thanks david jencks On Jul 6, 2006, at 6:06 AM, Krishnakumar B wrote: Hi David, I tried this and it works for Custom Resource Adapters. There is still a problem for Registering GBeans in Global JNDI through the builder ( ServiceConfigBuilder ). The Builder is a part of geronimo-gbean-deployer plan which is parent of j2ee-deployer. The geronimo-naming jars are loaded in j2ee-deployer. Hence we dont get access in ServiceConfigBuilder to GBeanReference thats part of naming. Currently all the binding GBeans are in naming package. So it works for all j2ee deployments. Is there a way to work around this ClassLoading problem heirarchy for binding GBeans through builder? Regards Krishnakumar On 6/28/06, David Jencks [EMAIL PROTECTED] wrote: I think there is a simpler solution, or perhaps I don't understand all the details of what you are proposing. I think if you give your binding gbeans the magic classLoader attribute everything will work. This will be set to the configuration classloader for the configuration the gbean is in, not the configuration the gbeans class is loaded in. This classloader should always have the necessary classes in it. thanks david jencks On Jun 28, 2006, at 12:39 AM, Manu George wrote: Hi, The problem we are facing regarding adapters is because the binding gbeans were added to the naming module of geronimo. We are planning to change this by creating a separate module for global jndi and then adding it as a dependency in the configuration that is getting deployed. This will be done in the builders. All the reference creation logic can also be moved to the gbeans.The Binding GBeans will then have access to application level classes as they will be loaded in the app class loader. We hope this approach will solve the current problem. We will post the code again after making these changes. Thanks Manu On 6/28/06, Krishnakumar B [EMAIL PROTECTED] wrote: Hi, We have created a JIRA (http://issues.apache.org/jira/browse/GERONIMO-2153 ) and attached the initial draft. We have tried two approaches. * Adding to plan * Deploying from Builder. The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag global-jndi/ in opene ejb plan. Resource Adapter and GBean have a gbean plan added to deployment plan. gbean name=JMSQueueFactoryJNDIBindingGBean class=org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean attribute name=configIdtest/jms.rar/1.0/rar/attribute attribute name=jndiNameglobalJMSQueueFactory/attribute attribute name=componentNameJMSQueueFactory/attribute attribute name=j2eeTypeJCAManagedConnectionFactory/attribute attribute name=interfaceNameorg.apache.geronimo.jms.connector.JMSQueueConnec tionFactory/attribute /gbean and gbean name=TestGBeanJNDIBindingGBean class=org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean attribute name=configIdtest/gbean/1.0/car/attribute attribute name=jndiNameglobalTestGBean/attribute attribute name=componentNameTestGBean/attribute attribute name=j2eeTypeGBean/attribute attribute name=classNamegbean.test.TestGBean/attribute /gbean We have a Classloading issue when trying to maintain all the BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource Adapters that are not J2EE interfaces like javax.sql.DataSource / javax.jms.QueueConnectionFactory we get a ClassNotFound as the class is not available at Classloader of rmi-naming. We spent a lot of time trying to solve this issue but are not able to find a solution as the application level interface or class is not available. This problem will not occur for j2ee interfaces like DataSource, EJB interfaces, Queue, Topic etc.. If the approach is correct we would like to add the other features to make this more suitable for adding into the product. Regards Krishnakumar B On 6/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 6/23/06, Krishnakumar B [EMAIL PROTECTED] wrote: The plan needs to have some XML Tag to say this resource needs to gets into Global JNDI and the builder can then add it to geronimo: Context. This is not implemented yet. Currently if we deploy a connector it gets in global jndi. I might've misunderstood it, but isn't Global JNDI == geronimo: context == global: context? If so, why is this copying from Global JNDI to the geronimo: namespace? Looking forward to seeing your patch for it. Just as Guillaume suggested, please create an JIRA issue and attach the patch to it. Krishnakumar B Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
Jacek, I agree that that it has been hard to install. We need to figure out why. That is another issue I think. Matt Jacek Laskowski wrote: On 7/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. Don't we have it behind us already? I thought we agreed upon the fact that unix patch is incompatible with svn diff and thus we need to use svn diff to create a patch for review and merge it to our own local copies using svn merge. The point is to get the revisions a patch is built from, but the rest should work. I would like to see Jason get these changes into trunk as well as resolve the patch issue. (Oh, poor Jacek and his poor English that doesn't let him explain how we should proceed :-)) To be honest, I don't like how the patch has been reviewed and voted. How can we say it works if we (me, including) couldn't apply it to our local source copies? If one's going to say it's because of the unix patch I'll start screaming...That's why svn merge exists, doesn't it? Ok, stop whining... I wonder how the changes will be applied to trunk if patch doesn't work? Jacek
[jira] Resolved: (AMQ-797) ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets
[ https://issues.apache.org/activemq/browse/AMQ-797?page=all ] Nathan Mittler resolved AMQ-797: Resolution: Fixed ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets -- Key: AMQ-797 URL: https://issues.apache.org/activemq/browse/AMQ-797 Project: ActiveMQ Type: Bug Components: CMS Environment: Windows Mingw GNU builds Reporter: Timothy Bish Assignee: Nathan Mittler Priority: Minor Attachments: patch-makefile-windows-debug.txt, patch-makefile-windows-release.txt Original Estimate: 1 minute Remaining: 1 minute The windows makefiles for the MinGW targets fail to link the test and test-integration targets. When the code was submitted the makefiles were changed to build the library with the libactivemq-cpp.a name, but the windows makefiles still try and link the tests against libactivemq.a -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Found a fix but don't know why...Re: M2 assembly question
So I'm not sure if this is a bug in Maven or not... but in a given module if the POM packaging is set to pom and if assembly descriptors use dependencySet the dependencies as specified in the POM seem to be ignored and the assembly zips end up being empty. If I set the packaging to jar then the dependencies get picked up and packaged. I'm going to go and and fix this in the devtools assembly module by changing the packaging to a jar, if anyone thinks this is wrong let me know. On Jul 6, 2006, at 12:34 PM, Sachin Patel wrote: Is it better to have an separate assembly module that generates the assemblies or is it better to have the assembly plugin configured in the root pom? Currently in devtools I have it as a seperate module and use dependencySets to specify what gets included in the binaries. However as mentioned in earlier threads this is having problems working on one platform but not on another. I don't know if it would make a difference if I define the assembly config in the root POM and use moduleSets instead. I'm wanting to put out a vote on the release of the 1.1 version of the eclipse plugin but need to get this problem fixed as currently my machine seems to be the only machine in which the assembly generation seems to be working :(. -sachin -sachin
[jira] Updated: (GERONIMO-2082) [m2] stax dependencies are all wrong
[ http://issues.apache.org/jira/browse/GERONIMO-2082?page=all ] David Jencks updated GERONIMO-2082: --- Component: buildsystem [m2] stax dependencies are all wrong Key: GERONIMO-2082 URL: http://issues.apache.org/jira/browse/GERONIMO-2082 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem Versions: 1.2 Reporter: David Jencks Assignee: David Jencks Fix For: 1.2 Attachments: geronimo-no-stax-v2.diff, geronimo-no-stax.diff, m2-repo.jar, openejb-no-stax-v2.diff, openejb-no-stax.diff, xbean-2.0.0.pom, xmlbeans-maven-plugin-2.0.1-SNAPSHOT.jar, xmlbeans-maven-plugin-2.0.1-SNAPSHOT.jar The dependencies for xmlbeans and the maven xmlbeans plugins are all wrong. xmlbeans pom needs to depend on stax-api, see http://jira.codehaus.org/browse/MEV-406 xmlbeans plugin needs to have stax-api and stax dependencies removed, see http://jira.codehaus.org/browse/MXMLBEANS-19 At this point we can remove all stax and stax-api dependencies from our (and openejb) poms. I'll attach the modified xmlbeans pom, the modified plugin, and the patches to remove all stax mentions from our poms. I'd appreciate some verification of my results. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
The exact command used to make the v5 patch was (from trunk): svn diff GERONIMO-2161.patch And, as I thought I explained to you before, the same changes are applied to this branch: https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ m2migration/ You can just use the branch to test the changes, or merge those changes into your branch, which should have the same results at the cost of additional merging. --jason On Jul 6, 2006, at 4:09 AM, Jacek Laskowski wrote: On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm sorry... but I do not understand what you are asking Jacek. Could you please rephrase your question/request? How did you cut the latest patch v5? What commands did you use? I guess it was something like 'svn diff ... GERONIMO-2161-v5.patch', wasn't it? If so and the changes are part of a branch (e.g. svkmerge/m2migration), we (testers) could apply it to our local Geronimo srcs using 'svn merge' nor 'patch' that we've just found is incompatible. This way we will use svn commands only and be able to apply and test it. --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Updated: (GERONIMO-1737) Plugin migration to Maven 2: geronimo-assembly-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1737?page=all ] David Jencks updated GERONIMO-1737: --- Attachment: m2-jetty-server.patch Using prasad's assembly plugin that I believe he is attaching to this issue, and trunk as of rev 419642, I got a jetty server with 13 modules to build using this patch, and it starts!. Many of the changes such as fixing the openejb groupId may be duplicated in other patches. Plugin migration to Maven 2: geronimo-assembly-plugin - Key: GERONIMO-1737 URL: http://issues.apache.org/jira/browse/GERONIMO-1737 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.x Reporter: Jacek Laskowski Assignee: Prasad Kashyap Attachments: m2-jetty-server.patch It's a task to keep track of the progress of the plugin build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote: I wonder how the changes will be applied to trunk if patch doesn't work? It is easy enough to apply the patch and then copy the files from the svkmerge/m2migration branch manually to recreate the complete v5 patch changes. --jason
Re: Found a fix but don't know why...Re: M2 assembly question
Thanks Jason!, Comparing your pom to mine, I changed the packaging back to pom, and noticed your configuration for the assembly plugin invoked the goal attached where mine invoked assembly. Changing it to attached seemed to correct the problem. Although I still don't understand why as looking at both of the goal descriptions they do the same thing. On Jul 6, 2006, at 3:08 PM, Jason Dillon wrote: I am using pom packaging for GShell assemblies (as well for other projects) with no problems using dependencySets: http://svn.apache.org/repos/asf/geronimo/sandbox/gshell/trunk/ gshell-assemblies/gshell-complete-assembly/pom.xml But, that assembly's pom can not depend on another pom with pom packaging and expect to pick up all of the dependencies it has listed. --jason On Jul 6, 2006, at 11:04 AM, Sachin Patel wrote: So I'm not sure if this is a bug in Maven or not... but in a given module if the POM packaging is set to pom and if assembly descriptors use dependencySet the dependencies as specified in the POM seem to be ignored and the assembly zips end up being empty. If I set the packaging to jar then the dependencies get picked up and packaged. I'm going to go and and fix this in the devtools assembly module by changing the packaging to a jar, if anyone thinks this is wrong let me know. On Jul 6, 2006, at 12:34 PM, Sachin Patel wrote: Is it better to have an separate assembly module that generates the assemblies or is it better to have the assembly plugin configured in the root pom? Currently in devtools I have it as a seperate module and use dependencySets to specify what gets included in the binaries. However as mentioned in earlier threads this is having problems working on one platform but not on another. I don't know if it would make a difference if I define the assembly config in the root POM and use moduleSets instead. I'm wanting to put out a vote on the release of the 1.1 version of the eclipse plugin but need to get this problem fixed as currently my machine seems to be the only machine in which the assembly generation seems to be working :(. -sachin -sachin -sachin
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote: On 7/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. Don't we have it behind us already? I thought we agreed upon the fact that unix patch is incompatible with svn diff and thus we need to use svn diff to create a patch for review and merge it to our own local copies using svn merge. The point is to get the revisions a patch is built from, but the rest should work. We must resolve why svn diff + patch does not work... else it will be very, very difficult to take in changes from non-commiters who do not have access to create branches for us to merge. To be honest, I don't like how the patch has been reviewed and voted. How can we say it works if we (me, including) couldn't apply it to our local source copies? If one's going to say it's because of the unix patch I'll start screaming...That's why svn merge exists, doesn't it? Ok, stop whining... Dude! You can apply the changes to your workspace... many other have done so. Yes, patch barfs on a few bits, but copy over the changed files, which are all minor anyways, and you are set. --jason
Re: Found a fix but don't know why...Re: M2 assembly question
From what I understand, the assembly goal is a tad broke and causes a duplicate assembly to run. It was meant to be run as in `mvn assembly:assembly' not as part of a phase. But lucky for us they added these new goals that work better when attached to a phase. --jason On Jul 6, 2006, at 12:23 PM, Sachin Patel wrote: Thanks Jason!, Comparing your pom to mine, I changed the packaging back to pom, and noticed your configuration for the assembly plugin invoked the goal attached where mine invoked assembly. Changing it to attached seemed to correct the problem. Although I still don't understand why as looking at both of the goal descriptions they do the same thing. On Jul 6, 2006, at 3:08 PM, Jason Dillon wrote: I am using pom packaging for GShell assemblies (as well for other projects) with no problems using dependencySets: http://svn.apache.org/repos/asf/geronimo/sandbox/gshell/trunk/ gshell-assemblies/gshell-complete-assembly/pom.xml But, that assembly's pom can not depend on another pom with pom packaging and expect to pick up all of the dependencies it has listed. --jason On Jul 6, 2006, at 11:04 AM, Sachin Patel wrote: So I'm not sure if this is a bug in Maven or not... but in a given module if the POM packaging is set to pom and if assembly descriptors use dependencySet the dependencies as specified in the POM seem to be ignored and the assembly zips end up being empty. If I set the packaging to jar then the dependencies get picked up and packaged. I'm going to go and and fix this in the devtools assembly module by changing the packaging to a jar, if anyone thinks this is wrong let me know. On Jul 6, 2006, at 12:34 PM, Sachin Patel wrote: Is it better to have an separate assembly module that generates the assemblies or is it better to have the assembly plugin configured in the root pom? Currently in devtools I have it as a seperate module and use dependencySets to specify what gets included in the binaries. However as mentioned in earlier threads this is having problems working on one platform but not on another. I don't know if it would make a difference if I define the assembly config in the root POM and use moduleSets instead. I'm wanting to put out a vote on the release of the 1.1 version of the eclipse plugin but need to get this problem fixed as currently my machine seems to be the only machine in which the assembly generation seems to be working :(. -sachin -sachin -sachin
Re: [jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote: The exact command used to make the v5 patch was (from trunk): svn diff GERONIMO-2161.patch And, as I thought I explained to you before, the same changes are applied to this branch: https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ m2migration/ You can just use the branch to test the changes, or merge those changes into your branch, which should have the same results at the cost of additional merging. Understood. Would you consider a small improvement in the process (let me call it this way before we'll find a better name for it ;-))? You've been working on the patch in your local copy of Geronimo trunk. You did svn co ...trunk. Correct? When you finished your work, you executed 'svn diff' to cut the patch. Correct? The patch turned out to be 'broken' or 'incompatible' for unix patch command and thus noone could test it out extensively, but look at it and verify reading. Correct? I can see a few issues with that approach: 1/ You're working alone with no help from anyone. No, I don't mind your working alone and show changes when they're ready. The point is that I don't foster an interest of others to be involved and possibly contribute/help you. 2/ As we have already found out, unix patch is not reliable and thus is not an option in a long turn. We need to figure out a way to work in a collaborative manner without the overhead of unix patch that makes the process of applying changes more complicated than it really needs to be. If your changes are between some revisions (e.g. initial branch creation revision and HEAD) anyone can use the branch and apply the change with svn merge command to his/her local Geronimo sources copy and test it out. Once an issue is found, the one who spot it could fix it in your branch and again call a vote. There're some other benefits, but these should be enough for now (unless you're not convinced and I'll have to write them down ;-)) WDYT? --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: How do we build the Eclipse Plugin assembly?
This problem (thanks Jason) is now fixed. An mvn at the root will build all modules and generate the assemblies in one shot. On Jun 30, 2006, at 5:15 PM, Donald Woods wrote: I just checked out Rev418113 of the Eclipse plugin trunk, started with a clean m2 repo and successfully got a mvn install to complete after several attempts. But, when I look in the assembly/ directory, no target/ directory was created. Is this expected? When I ran mvn from the assembly directory, it created a target directory, but the following zipfiles were only 22 bytes each - g-eclipse-plugin-1.1-deployable.zip g-eclipse-plugin-1.1-updatesite.zip I'm building on WinXP with Maven 2.0.4 and Sun Java 1.4.2_12-b03. -Donald -sachin
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote: On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote: I wonder how the changes will be applied to trunk if patch doesn't work? It is easy enough to apply the patch and then copy the files from the svkmerge/m2migration branch manually to recreate the complete v5 patch changes. I must be missing something as I don't understand how you can use 'easy enough' when we all were struggling with applying it. Could you elaborate a bit more? --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: openejb itests?
Yep. This is it. So what you could do is take a m1 binary and run the mvn install:install-file command to install it into your m2 local repo. The exact syntax of that command is in the error message that you have pasted. Cheers Prasad On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Prasad, Is this error that causes you to manually install an m1 built bit into the m2 repo? If so could you point me to exactly what bits to copy? Thanks! -bd- [INFO] Configured Artifact: org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1- SNAPSHOT:zip [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.geronimo.distributions ArtifactId: geronimo-jetty-j2ee Version: 1.1-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file - DgroupId=org.apache.geronimo.distributions -DartifactId=geronimo- jetty-j2ee \ -Dversion=1.1-SNAPSHOT -Dpackaging=zip -Dfile=/path/to/file org.apache.geronimo.distributions:geronimo-jetty-j2ee:zip:1.1- SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), Maven snapshots (http://cvs.apache.org/maven-snapshot-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 4 seconds [INFO] Finished at: Thu Jul 06 12:32:17 MDT 2006 [INFO] Final Memory: 5M/9M [INFO] On Jul 6, 2006, at 8:35 AM, Prasad Kashyap wrote: Hi Bill, Inline- On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Prasad, First we needed the geronimo-deployment-plugin to be in m2. So in http://issues.apache.org/jira/browse/GERONIMO-1738, I got the deployment-plugin migarted to m2. The RTC for this is pending 2 more votes. Now, if you and Jason can review and approve it, we can get it in the build. I applied the patch but it appears that there is a problem with it, AppTest.java has 3 copies of the code in it for example (as well as pom.xml and many if not all the other files). Here is the url to what I downloaded and I'm looking at; http://issues.apache.org/jira/secure/attachment/12324416/geronimo- deployment-plugin.patch which is the first patch from JIRA #1738 referenced above. You might want to pick up the latest patch from the Manage Attachments link. The patches on the JIRA page are sorted alphabetically. The patch that you downloaded was my initial submission. The other one with ( http://issues.apache.org/jira/secure/attachment/12335875/geronimo- deployment-plugin-RTC-VOTE.2.patch ) is what you need. This was uploaded by David Jencks after reviewing mine and making some changes based on other reviews. I used to take an m1 binary distribution and manually put it into an m2 local repo for this work. Now that we are working on m2, hopefully we shall soon have the binary distributions for us to work with directly. An m1 distribution of G or something else? Yes, of G. Cheers Prasad
[jira] Commented: (GERONIMO-1737) Plugin migration to Maven 2: geronimo-assembly-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1737?page=comments#action_12419600 ] Prasad Kashyap commented on GERONIMO-1737: -- David, I think the following are missing from the bin.xml. They have to be merged under the relavant sections to your bin.xml fileSets fileSet directory${basedir}/src/var/directory outputDirectory/var/outputDirectory lineEndingcrlf/lineEnding /fileSet /filesets files file source${basedir}/src/var/config/config.xml/source outputDirectoryvar/config/outputDirectory destNameconfig.xml.orig/destName filteredtrue/filtered lineEndingcrlf/lineEnding /file file source${basedir}/src/var/config/config.xml/source outputDirectoryvar/config/outputDirectory destNameoffline-deployer-list/destName filteredtrue/filtered lineEndingcrlf/lineEnding /file /files Plugin migration to Maven 2: geronimo-assembly-plugin - Key: GERONIMO-1737 URL: http://issues.apache.org/jira/browse/GERONIMO-1737 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.x Reporter: Jacek Laskowski Assignee: Prasad Kashyap Attachments: geronimo-assembly-plugin.patch, m2-jetty-server.patch, maven-assembly-plugin.patch It's a task to keep track of the progress of the plugin build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RTC] Vote on GERONIMO-2161 - restart 1
IIUC, after this restart, we need one more +1 from a PMC member to allow these changes to be committed to the trunk. Assuming that another +1 comes in soonish, how long shall I wait before applying? --jason On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote: +1 to getting this patch in... I spent some time working with Jason and Jacek last night on this patch. It is fairly large and reaching. There appears to be an issue with SVN creating a bad patch file for several files but I don't believe this is Jason's issue but rather with SVN. There are 5 failed hunks in the v5 patch. I manually copied the files from branches/m2migration into trunk as these were the source of the modification. The build was successful and I understand what Jason is doing here. I am giving this patch a +1 and would like to see Jason get this applied at his earliest convenience. There are issues with moving forward but getting on a better code base will accelerate progress on getting to a fully integrated build. We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. I would like to see Jason get these changes into trunk as well as resolve the patch issue. Matt *** Notations of applicability *** Here is the output from the patch when I applied it. I increased the FUZZ factor to a horrible 8 but it had no effect. hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l ~/Downloads/ GERONIMO-2161-v5.patch.txt patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/online-deployer/pom.xml patching file configs/j2ee-deployer/pom.xml patching file configs/tomcat-deployer/pom.xml patching file configs/activemq/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/geronimo-gbean-deployer/pom.xml patching file configs/shutdown/pom.xml patching file configs/hot-deployer/pom.xml patching file configs/servlets-examples-jetty/pom.xml patching file configs/jetty-deployer/pom.xml patching file configs/openejb/pom.xml patching file configs/unavailable-webservices-deployer/pom.xml patching file configs/axis-deployer/pom.xml patching file configs/system-database/pom.xml patching file configs/ldap-demo-tomcat/pom.xml patching file configs/upgrade/pom.xml patching file configs/welcome-jetty/pom.xml patching file configs/j2ee-security/pom.xml patching file configs/upgrade-cli/pom.xml patching file configs/rmi-naming/pom.xml patching file configs/ldap-demo-jetty/pom.xml patching file configs/client-deployer/pom.xml
Re: [RTC] Vote on GERONIMO-2161 - restart 1
If Jacek +1d it (I don't recall if he did) you have 3 +1s. Jeff Jason Dillon wrote: IIUC, after this restart, we need one more +1 from a PMC member to allow these changes to be committed to the trunk. Assuming that another +1 comes in soonish, how long shall I wait before applying? --jason On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote: +1 to getting this patch in... I spent some time working with Jason and Jacek last night on this patch. It is fairly large and reaching. There appears to be an issue with SVN creating a bad patch file for several files but I don't believe this is Jason's issue but rather with SVN. There are 5 failed hunks in the v5 patch. I manually copied the files from branches/m2migration into trunk as these were the source of the modification. The build was successful and I understand what Jason is doing here. I am giving this patch a +1 and would like to see Jason get this applied at his earliest convenience. There are issues with moving forward but getting on a better code base will accelerate progress on getting to a fully integrated build. We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. I would like to see Jason get these changes into trunk as well as resolve the patch issue. Matt *** Notations of applicability *** Here is the output from the patch when I applied it. I increased the FUZZ factor to a horrible 8 but it had no effect. hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l ~/Downloads/GERONIMO-2161-v5.patch.txt patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/online-deployer/pom.xml patching file configs/j2ee-deployer/pom.xml patching file configs/tomcat-deployer/pom.xml patching file configs/activemq/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/geronimo-gbean-deployer/pom.xml patching file configs/shutdown/pom.xml patching file configs/hot-deployer/pom.xml patching file configs/servlets-examples-jetty/pom.xml patching file configs/jetty-deployer/pom.xml patching file configs/openejb/pom.xml patching file configs/unavailable-webservices-deployer/pom.xml patching file configs/axis-deployer/pom.xml patching file configs/system-database/pom.xml patching file configs/ldap-demo-tomcat/pom.xml patching file configs/upgrade/pom.xml patching file configs/welcome-jetty/pom.xml patching file configs/j2ee-security/pom.xml patching file
Re: [RTC] Vote on GERONIMO-2161 - restart 1
I don't recall Jacek +1'ing... before or after the restart. * * * But, I was more curious how long after the next +1 comes in I should wait before applying this? --jason On Jul 6, 2006, at 2:08 PM, Jeff Genender wrote: If Jacek +1d it (I don't recall if he did) you have 3 +1s. Jeff Jason Dillon wrote: IIUC, after this restart, we need one more +1 from a PMC member to allow these changes to be committed to the trunk. Assuming that another +1 comes in soonish, how long shall I wait before applying? --jason On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote: +1 to getting this patch in... I spent some time working with Jason and Jacek last night on this patch. It is fairly large and reaching. There appears to be an issue with SVN creating a bad patch file for several files but I don't believe this is Jason's issue but rather with SVN. There are 5 failed hunks in the v5 patch. I manually copied the files from branches/m2migration into trunk as these were the source of the modification. The build was successful and I understand what Jason is doing here. I am giving this patch a +1 and would like to see Jason get this applied at his earliest convenience. There are issues with moving forward but getting on a better code base will accelerate progress on getting to a fully integrated build. We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. I would like to see Jason get these changes into trunk as well as resolve the patch issue. Matt *** Notations of applicability *** Here is the output from the patch when I applied it. I increased the FUZZ factor to a horrible 8 but it had no effect. hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l ~/Downloads/GERONIMO-2161-v5.patch.txt patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/online-deployer/pom.xml patching file configs/j2ee-deployer/pom.xml patching file configs/tomcat-deployer/pom.xml patching file configs/activemq/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/geronimo-gbean-deployer/pom.xml patching file configs/shutdown/pom.xml patching file configs/hot-deployer/pom.xml patching file configs/servlets-examples-jetty/pom.xml patching file configs/jetty-deployer/pom.xml patching file configs/openejb/pom.xml patching file configs/unavailable-webservices-deployer/pom.xml patching file configs/axis-deployer/pom.xml patching file configs/system-database/pom.xml patching file configs/ldap-demo-tomcat/pom.xml
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote: IIUC, after this restart, we need one more +1 from a PMC member to allow these changes to be committed to the trunk. Assuming that another +1 comes in soonish, how long shall I wait before applying? +1 (I did review it only as I had troubles test it out thorougly) Wait 18 hours and go ahead. 18 hours will let the sun round the globe so others get a chance to vote...against ;-) --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: openejb itests?
Hi Prasad,Thanks, - I guess I was hoping that it was something smaller :-)I had to;1) install the jetty version but changed version to 1.1 and updated itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT2) install the tomcat version but changed version to 1.1 and updated itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT3) enable the utils 3) delete the explicit mention of version from the maven-site-plugin in teardown-tests.pom.xml4) add junit as a dependency otherwise the mvn failed unless -Dmaven.test.skip=true was specified5) run mvnAlthough the build succeeds, nothing appears to happen (see attached log)From what I can tell the geronimo-deployment-plugin is not being built correctly, none of the src's are being compiled and placed into the jar file. I poked around but the reason escapes me...TTFN,Bill DudneyMyFaces - http://myfaces.apache.orgCayenne - http://incubator.apache.org/projects/cayenne.html[INFO] Scanning for projects...[INFO] Reactor build order: [INFO] Geronimo Integration Tests[INFO] Geronimo :: itests :: system[INFO] Geronimo :: itests :: webcontainer[INFO] Geronimo :: itests :: teardown[INFO] [INFO] Building Geronimo Integration Tests[INFO] task-segment: [install][INFO] [INFO] [site:attach-descriptor][INFO] [dependency:unpack {execution: unpack}][INFO] Configured Artifact: org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1:zip[INFO] geronimo-jetty-j2ee-1.1.zip already unpacked.Downloading: http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom[WARNING] Unable to get resource from repository Maven snapshots (http://cvs.apache.org/maven-snapshot-repository)Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom[WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2)Downloading: http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom[WARNING] Unable to get resource from repository Maven snapshots (http://cvs.apache.org/maven-snapshot-repository)Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom[WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2)[INFO] [antrun:run {execution: prepare}][INFO] Executing tasks [delete] Deleting 1 files from /private/tmp/foo/sandbox/itests/target/logs [touch] Creating /private/tmp/foo/sandbox/itests/target/logs/results.log[INFO] Executed tasks[INFO] [install:install][INFO] Installing /private/tmp/foo/sandbox/itests/pom.xml to /Users/bdudney/.m2/repository/org/apache/geronimo/itests/geronimo-itests-parent/1.0/geronimo-itests-parent-1.0.pom[INFO] [INFO] Building Geronimo :: itests :: system[INFO] task-segment: [install][INFO] [INFO] [resources:resources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:compile][INFO] Nothing to compile - all classes are up to date[INFO] [resources:testResources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:testCompile][INFO] Nothing to compile - all classes are up to date[INFO] [surefire:test][INFO] No tests to run.[INFO] [jar:jar][WARNING] JAR will be empty - no content was marked for inclusion![INFO] Building jar: /private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar[INFO] [antrun:run {execution: prepare}][INFO] Executing tasks [delete] Deleting 1 files from /private/tmp/foo/sandbox/itests/system-tests/target/logs [touch] Creating /private/tmp/foo/sandbox/itests/system-tests/target/logs/results.log[INFO] Executed tasks[INFO] [install:install][INFO] Installing /private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar to /Users/bdudney/.m2/repository/org/apache/geronimo/itests/system-tests/1.0/system-tests-1.0.jar[INFO] [INFO] Building Geronimo :: itests :: webcontainer[INFO] task-segment: [install][INFO] [INFO] [resources:resources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:compile][INFO] Nothing to compile - all classes are up to date[INFO] [resources:testResources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:testCompile][INFO] Nothing to compile - all classes are up to date[INFO] [surefire:test][INFO] Surefire report directory:
[jira] Commented: (GERONIMO-1737) Plugin migration to Maven 2: geronimo-assembly-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1737?page=comments#action_12419616 ] David Jencks commented on GERONIMO-1737: I agree about the additions to my patch. Just to be clear, my patch is informative work in progress, it should not be committed at this point because it does not start a lot of the configs since they aren't available yet for the m2 server. Plugin migration to Maven 2: geronimo-assembly-plugin - Key: GERONIMO-1737 URL: http://issues.apache.org/jira/browse/GERONIMO-1737 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.x Reporter: Jacek Laskowski Assignee: Prasad Kashyap Attachments: geronimo-assembly-plugin.patch, m2-jetty-server.patch, maven-assembly-plugin.patch It's a task to keep track of the progress of the plugin build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On Jul 6, 2006, at 2:09 PM, Jason Dillon wrote: I don't recall Jacek +1'ing... before or after the restart. * * * But, I was more curious how long after the next +1 comes in I should wait before applying this? My point of view is that while there might be a minimum time needed in total for a vote, there is no need to wait after the 3rd +1 as long as that minumum time since the start of the vote has elapsed. This vote has been going on with additions for 5 days now with no technical objections, although jason has enhanced the patch in several ways. Anyone with the slightest concerns about this patch has had more than adequate time to object, and they continue to be able to object till the heat death of the universe. Commit it now. (non binding) david jencks --jason On Jul 6, 2006, at 2:08 PM, Jeff Genender wrote: If Jacek +1d it (I don't recall if he did) you have 3 +1s. Jeff Jason Dillon wrote: IIUC, after this restart, we need one more +1 from a PMC member to allow these changes to be committed to the trunk. Assuming that another +1 comes in soonish, how long shall I wait before applying? --jason On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote: +1 to getting this patch in... I spent some time working with Jason and Jacek last night on this patch. It is fairly large and reaching. There appears to be an issue with SVN creating a bad patch file for several files but I don't believe this is Jason's issue but rather with SVN. There are 5 failed hunks in the v5 patch. I manually copied the files from branches/m2migration into trunk as these were the source of the modification. The build was successful and I understand what Jason is doing here. I am giving this patch a +1 and would like to see Jason get this applied at his earliest convenience. There are issues with moving forward but getting on a better code base will accelerate progress on getting to a fully integrated build. We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. I would like to see Jason get these changes into trunk as well as resolve the patch issue. Matt *** Notations of applicability *** Here is the output from the patch when I applied it. I increased the FUZZ factor to a horrible 8 but it had no effect. hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l ~/Downloads/GERONIMO-2161-v5.patch.txt patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/online-deployer/pom.xml patching
Re: [RTC] Vote on GERONIMO-2161 - restart 1
w00t! --jason On Jul 6, 2006, at 4:54 PM, Jeff Genender wrote: Consider it blessed. ;-) Jason Dillon wrote: On Jul 6, 2006, at 4:23 PM, David Jencks wrote: My point of view is that while there might be a minimum time needed in total for a vote, there is no need to wait after the 3rd +1 as long as that minumum time since the start of the vote has elapsed. This vote has been going on with additions for 5 days now with no technical objections, although jason has enhanced the patch in several ways. Anyone with the slightest concerns about this patch has had more than adequate time to object, and they continue to be able to object till the heat death of the universe. Commit it now. (non binding) I'd be more than happy to do so if someone from the PMC would bless that action. --jason
[jira] Created: (GERONIMO-2167) deployer.jar not cleaning up properly during redeploy and undeploy
deployer.jar not cleaning up properly during redeploy and undeploy -- Key: GERONIMO-2167 URL: http://issues.apache.org/jira/browse/GERONIMO-2167 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Environment: Win32/XP SP1 Sun JDK 1.5_06 Reporter: Leonard Wu deployment using deploy.jar doesn't appear to clean up correctly. first deploy always works. subsequent re-deploy and un-deploy are problematic. following illustrates the full sequence of events as i had encountered: -- D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja r --user system --password manager deploy D:/work/SERVER/dwr-demo.war Deployed littleoldme/dwrdemo/1.1/war @ http://vaio:8080/dwr-demo D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war' Stopped littleoldme/dwrdemo/1.1/war Unloaded littleoldme/dwrdemo/1.1/war Uninstalled littleoldme/dwrdemo/1.1/war Deployed littleoldme/dwrdemo/1.1/war Started littleoldme/dwrdemo/1.1/war Redeployed littleoldme/dwrdemo/1.1/war D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war' Stopped littleoldme/dwrdemo/1.1/war Unloaded littleoldme/dwrdemo/1.1/war Uninstalled littleoldme/dwrdemo/1.1/war Error: Operation failed: org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException: Configuration already exists: littleoldme/dwrdemo/1.1/war Configuration already exists: littleoldme/dwrdemo/1.1/war D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja r --user system --password manager undeploy littleoldme/dwrdemo/1.1/war Error: littleoldme/dwrdemo/1.1/war does not appear to be a the name of a module available on the selected server. Perhaps it has already been stopped or undeployed? If you're trying to specify a TargetModuleID, use the syntax TargetName|ModuleName instead. If you're not sure what's running, try the list-modules command. -- While in this broken state, i'm able to recover by manually removing the ${geronimo}/repository/littleoldme directory and removing the one line in ${geronimo}/var/config/config.xml that says module load=false name=littleoldme/dwrdemo/1.1/war/ However, this only gets me to a fresh beginning, and then the whole sequence starts again as I repeat (re/un)deploying. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2167) deployer.jar not cleaning up properly during redeploy and undeploy
[ http://issues.apache.org/jira/browse/GERONIMO-2167?page=comments#action_12419630 ] Leonard Wu commented on GERONIMO-2167: -- deployment plan, geronimo-web.xml is included in the WAR deployer.jar not cleaning up properly during redeploy and undeploy -- Key: GERONIMO-2167 URL: http://issues.apache.org/jira/browse/GERONIMO-2167 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: Win32/XP SP1 Sun JDK 1.5_06 Reporter: Leonard Wu Attachments: dwr-demo.war deployment using deploy.jar doesn't appear to clean up correctly. first deploy always works. subsequent re-deploy and un-deploy are problematic. following illustrates the full sequence of events as i had encountered: -- D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja r --user system --password manager deploy D:/work/SERVER/dwr-demo.war Deployed littleoldme/dwrdemo/1.1/war @ http://vaio:8080/dwr-demo D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war' Stopped littleoldme/dwrdemo/1.1/war Unloaded littleoldme/dwrdemo/1.1/war Uninstalled littleoldme/dwrdemo/1.1/war Deployed littleoldme/dwrdemo/1.1/war Started littleoldme/dwrdemo/1.1/war Redeployed littleoldme/dwrdemo/1.1/war D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war' Stopped littleoldme/dwrdemo/1.1/war Unloaded littleoldme/dwrdemo/1.1/war Uninstalled littleoldme/dwrdemo/1.1/war Error: Operation failed: org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException: Configuration already exists: littleoldme/dwrdemo/1.1/war Configuration already exists: littleoldme/dwrdemo/1.1/war D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja r --user system --password manager undeploy littleoldme/dwrdemo/1.1/war Error: littleoldme/dwrdemo/1.1/war does not appear to be a the name of a module available on the selected server. Perhaps it has already been stopped or undeployed? If you're trying to specify a TargetModuleID, use the syntax TargetName|ModuleName instead. If you're not sure what's running, try the list-modules command. -- While in this broken state, i'm able to recover by manually removing the ${geronimo}/repository/littleoldme directory and removing the one line in ${geronimo}/var/config/config.xml that says module load=false name=littleoldme/dwrdemo/1.1/war/ However, this only gets me to a fresh beginning, and then the whole sequence starts again as I repeat (re/un)deploying. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-799) Handle async ConnectionError that may happen between brokers using a network bridge.
Handle async ConnectionError that may happen between brokers using a network bridge. Key: AMQ-799 URL: https://issues.apache.org/activemq/browse/AMQ-799 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Reporter: Hiram Chirino Fix For: 4.1, 4.0.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-799) Handle async ConnectionError that may happen between brokers using a network bridge.
[ https://issues.apache.org/activemq/browse/AMQ-799?page=all ] Hiram Chirino resolved AMQ-799: --- Resolution: Fixed Handle async ConnectionError that may happen between brokers using a network bridge. Key: AMQ-799 URL: https://issues.apache.org/activemq/browse/AMQ-799 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Reporter: Hiram Chirino Fix For: 4.1, 4.0.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Added confluence pages Committing patches to the Subversion Repository and How to prepare and contribute patches
I have added the page Committing patches to the Subversion Repository as a place to document the issues/recommendations involved in applying and committing patches. See http://cwiki.apache.org/confluence/display/GMOxDEV/Committing+patches+to+the+Subversion+Repository It is very much under construction and is based upon a mail from the derby lists that discussed processes for committing patches http://mail-archives.apache.org/mod_mbox/db-derby-dev/200603.mbox/[EMAIL PROTECTED] I haven't spent much time on it yet, but thought it would be worthwhile getting a confluence page started that everyone can update with their encounters with patches so we can develop some guidelines that can be used for people new to the project in the future. I have also created a related How to prepare and contribute patches page. http://cwiki.apache.org/confluence/display/GMOxDEV/How+to+prepare+and+contribute+patches Currently this just contains some links to some similar pages on other projects that may have some useful content. If anyone knows of other pages that may provide a good base to work from, please to add them to the page. Regards, John
Re: openejb itests?
I just built the geronimo-deployment-plugin from this patch ( http://issues.apache.org/jira/secure/attachment/12335875/geronimo-deployment-plugin-RTC-VOTE.2.patch ). It built successfully and installed in the local m2 repo. It's been a good 3-4 months since I last worked on itests but it is all coming back to me now. This seems to be a good time for me to start looking at itests again. Currently I could make use of this breather in the m2 migration work as issues like RTC, trunk or branch, invalid poms etc are sorted out. We still don't have a m2 distribution but we are slowly getting there. Cheers Prasad. On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Prasad, Thanks, - I guess I was hoping that it was something smaller :-) I had to; 1) install the jetty version but changed version to 1.1 and updated itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT 2) install the tomcat version but changed version to 1.1 and updated itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT 3) enable the utils 3) delete the explicit mention of version from the maven-site-plugin in teardown-tests.pom.xml 4) add junit as a dependency otherwise the mvn failed unless -Dmaven.test.skip=true was specified 5) run mvn Although the build succeeds, nothing appears to happen (see attached log) From what I can tell the geronimo-deployment-plugin is not being built correctly, none of the src's are being compiled and placed into the jar file. I poked around but the reason escapes me... TTFN, Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Geronimo Integration Tests [INFO] Geronimo :: itests :: system [INFO] Geronimo :: itests :: webcontainer [INFO] Geronimo :: itests :: teardown [INFO] [INFO] Building Geronimo Integration Tests [INFO]task-segment: [install] [INFO] [INFO] [site:attach-descriptor] [INFO] [dependency:unpack {execution: unpack}] [INFO] Configured Artifact: org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1:zip [INFO] geronimo-jetty-j2ee-1.1.zip already unpacked. Downloading: http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom [WARNING] Unable to get resource from repository Maven snapshots (http://cvs.apache.org/maven-snapshot-repository) Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Downloading: http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom [WARNING] Unable to get resource from repository Maven snapshots (http://cvs.apache.org/maven-snapshot-repository) Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [antrun:run {execution: prepare}] [INFO] Executing tasks [delete] Deleting 1 files from /private/tmp/foo/sandbox/itests/target/logs [touch] Creating /private/tmp/foo/sandbox/itests/target/logs/results.log [INFO] Executed tasks [INFO] [install:install] [INFO] Installing /private/tmp/foo/sandbox/itests/pom.xml to /Users/bdudney/.m2/repository/org/apache/geronimo/itests/geronimo-itests-parent/1.0/geronimo-itests-parent-1.0.pom [INFO] [INFO] Building Geronimo :: itests :: system [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] No tests to run. [INFO] [jar:jar] [WARNING] JAR will be empty - no content was marked for inclusion! [INFO] Building jar: /private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar [INFO] [antrun:run {execution: prepare}] [INFO] Executing tasks [delete] Deleting 1 files from /private/tmp/foo/sandbox/itests/system-tests/target/logs [touch] Creating /private/tmp/foo/sandbox/itests/system-tests/target/logs/results.log [INFO] Executed tasks [INFO] [install:install] [INFO] Installing /private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar to
FYI: Planning to upgrade to Derby 10.1.3 for the Geronimo 1.1.1 release (GERONIMO-2155)
In the Derby library does not have line number debug information mail thread [1] a few weeks ago I asked whether people wanted to upgrade to the Derby 10.1.3 maintenance release [2]. David Jencks was the only person who mentioned it should go in the 1.1.1 release but did not hear any objections from others. If anyone disagrees with this plan, please speak up before I start looking into this next week. John [1] http://www.mail-archive.com/dev@geronimo.apache.org/msg25051.html [2] http://mail-archives.apache.org/mod_mbox/db-derby-user/200607.mbox/[EMAIL PROTECTED]
Re: tag 1.0.0 does not build - missing dependencies
On Jul 3, 2006, at 8:29 PM, Simon Godik wrote: I'm having difficulty building 1.0.0 tag. Dependencies are missing: commons-fileupload-1.1-dev.jar, dwr-1.0.jar, org.apache.geronimo.specs/geronimo-corba_2.3_spec/1.0/jar I did not get past corba dependency. Any special instructions for 1.0 tag? Simon, There was an inconsistency between the Geronimo and OpenEJB dependencies in Geronimo 1.0. See http://issues.apache.org/jira/ browse/GERONIMO-1449 To fix, you can apply the patch attached to the Jira to your configs/ j2ee-server/project.xml file or manually download the jar. Also, you'll want to change line 29 of your etc/project.properties file to use the new apache repo url (I suspect you've done this already): Index: etc/project.properties === --- etc/project.properties (revision 419225) +++ etc/project.properties (working copy) @@ -26,7 +26,7 @@ # maven.repo.remote=\ -http://cvs.apache.org/repository,\ +http://people.apache.org/repository,\ http://dist.codehaus.org,\ http://www.mortbay.org/maven,\ http://www.ibiblio.org/maven,\ --kevan
Re: svn commit: r419764 - /geronimo/trunk/m2-plugins/pom.xml
Yes, sorry... I'm currently resolving an issue that has popped up due to changes made in the trunk post the last cut of the patch which kinda whacked the application an validation. I'm reapplying now from a known good source and revalidating. Will need to correct a faulty commit to all_changes.log post commiting the real changes for 2161. This is an unfortunate reality that occurs when delaying major changes for a significant period. --jason On Jul 6, 2006, at 7:39 PM, John Sisson wrote: [EMAIL PROTECTED] wrote: Author: jdillon Date: Thu Jul 6 18:43:26 2006 New Revision: 419764 URL: http://svn.apache.org/viewvc?rev=419764view=rev Log: Merge changes for m2 Modified: geronimo/trunk/m2-plugins/pom.xml (contents, props changed) Hi Jason, Can you please put the JIRA issue in the svn log comments so it shows up in the Subversion commits tab in the JIRA issue so everyone can keep track of what commits/merges have been done for a JIRA. Thanks, John
Tag 1.1 issue?
I tried to build the v1.1 of Geronimo tag and I noticed that when I went to do a m:co of openejb, it is giving me the openejb branch instead of the 2.1 tag. Sure enough, upon perusal of the tagged root maven.xml, its pulling the openejb branch and not the tag. I am assuming this is an oversight and it should pull the tag orf openejb, not the branch. Do we need this fixed so we can do a build of our svn tagged 1.1? Jeff