Re: JIRA project for GShell?
Well, who can argue with that line of reasoning. :) Now that I think of it, if making a Jira project helps build a community around it, let's do it. It will be trivial to drop the project, as Dain has previously mentioned. Regards, Alan Jason Dillon wrote: GShell isn't gonna die... it will rule the world one day... its already kicking much ass. Unix geeks are gonna love us... :-] --jason On 6/9/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Jun 9, 2006, at 9:35 AM, Alan D. Cabrera wrote: > Jason Dillon wrote: >> Can we create a new JIRA project for GShell? I've got a bunch of >> task/todo items that I would like to track in JIRA so it is easier >> to prioritize and plan. >> >> Thoughts? >> >> --jason >> > IMO, if it gets out of the sandbox, it deserves a Jira project. I seen no reason not to give it a JIRA. If it dies in the sandbox, we can always delete the JIRA. -dain
Re: Next Geronimo Community Meeting
Aaron Mulder wrote: Well, I think it's adequately clear that people think we ought to run our meetings differently. Can we set up a next meeting, which everyone is invited to? We'll need people to help organize, as well as to cover the space, food, and telecom, but this should not be unmanageable. Of the people who would be interested in attending a project meeting, which of these work for you? 1) TheServerSide Barcelona 2) ApacheCon Dublin 3) OSCon Portland 4) ApacheCon Austin 5) Other Also, will you help organize and will you (or your company) chip in to cover costs? For my part, 1 & 2 would be best, I'm not sure about 3 & 4 yet, I can help organize, and I don't yet know about sponsorship. I'll be at 2-4. Regards, Alan
Re: Frustrations of a Release Manager
Aaron, The info was available publicly more than a week ago (If one know what to look for..): http://svn.apache.org/viewvc?view=rev&revision=411036 I presume that the expectation of the board and the pmc chair is for us to figure out things for ourselves. If we expect someone to lay down the rules either we will protest on the language or throw hands up in the air over tiny language tweaks or figure out a way to stay true to the word but not the intent of the policy. (think what we did as teenagers :) SO...we need to learn to fish and not expect a fish to be given to us. That way next time a situation arises, we know exactly what to do and what not to do. BTW, Am really glad we are talking in public about our folly/foible(s). This is an absolute first step towards making things better. thanks, dims On 6/9/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: Dims, Please don't imply that the PMC chair has sent an at-all useful message. (Why is the PMC different today than 4 weeks ago? I don't know -- you have made the first announcement of this just today. What's the message?) You in your e-mail right here have said what you though went wrong and how you think it could be corrected in the future. One of my biggest complaints with the board and the PMC chair is that they have done neither. In conversation with the PMC chair I practically begged him to tell me I had done something wrong WRT the JavaOne meeting and what should be done differently next time. He declined. I asked him to provide concrete examples of behavior of any kind that he thought needed to be changed. He declined. I think the message you provided below "If I had known about the meeting I would have done this... What Apache projects usually do is this... All it would have taken was this..." was extremely useful. Please, please encourage the PMC chair to take this approach in the future. Thanks, Aaron On 6/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Bruce, > > If you are again asking for my input here it isIt's plain and > simple. If there is a forum for discussion, it should be open as much > as possible. If it's not possible because of either monetary or space > constraints, then at least there should be some notification whereby > one can give their input on topics at hand via email and/or IRC. > > If i had known about significant discussions, i'd have brought up the > topic of how/what my thoughts are on a JAX-WS implementation and the > lack of a credible JAXB2 implementation. So the "Notes from JavaOne" > [1] would have brought out the problems we will be facing implementing > both JAX-WS and JAX-RPC (and using a single SAAJ impl) which could > have been discussed at this forum. I really have to thank David who > followed up by initiating discussion on axis-dev [2] after JavaOne. > > Clearly there was a private list of people who were invited and an > agenda was drawn up which was not shared with the whole dev team > either privately or publicly. Typically in all Apache projects, we > call it a F2F, pre announce it, discuss via email/wiki some of the > items before hand and thrash out the rest in person. > > All it would have taken is *ONE* lousy email asking for input on items > to be discussed either publicly or privately to all committers. Hiding > behind facade's like "oh, it was a vendor meeting" or "meeting > friends" or "We just left out just one person" or "Oh, There was a > BOF" or a thousand other excuses don't count. All you need to think > about is whether you are being fair to everyone who is engaged in the > project or not. By "bring the community together", hope you don't mean > that we just go back to our merry ways and not learn a lesson or two > from the strong actions by the pmc chair. > > Guys, there is something wrong we are doing. Let's fix it > > [1] http://marc.theaimsgroup.com/?l=geronimo-dev&m=114807250831613&w=2 > [2] http://marc.theaimsgroup.com/?t=11484081113&r=1&w=2 > > thanks, > dims > > On 6/9/06, Bruce Snyder <[EMAIL PROTECTED]> wrote: > > On 6/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > > Sigh! :( Looks like all efforts are down the drain. > > > > > > On 6/9/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > > > > I don't see what's wrong with a group of folks interested in Gernoimo > > > > getting together to talk about Geronimo. So long as it's positioned > > > > as discussion not decision-making, of course -- which, as I recall, it > > > > was. > > > > Dims, statements like that don't work to bring the community together, > > they only cause more animosity. Let's try to move beyond the jabs and > > let the people with unresolved issues air their concerns so that they > > can work together. > > > > Yet again I'm now thoroughly confused on this whole topic. Does this > > mean that nobody can even talk about Geronimo unless it's on-list in > > some way? Does this mean if someone at a client site or a local JUG or > > anywhere asks me questions about Geronim
Re: Next Geronimo Community Meeting
Thanks for taking a lead on this... Aaron Mulder wrote: > Well, I think it's adequately clear that people think we ought to run > our meetings differently. Can we set up a next meeting, which > everyone is invited to? We'll need people to help organize, as well > as to cover the space, food, and telecom, but this should not be > unmanageable. > > Of the people who would be interested in attending a project meeting, > which of these work for you? > > 1) TheServerSide Barcelona > 2) ApacheCon Dublin > 3) OSCon Portland > 4) ApacheCon Austin > 5) Other > 3 & 4 (for me... U.S. bound Jeff with baby on the way end of June...yeah I almost was in Europe...wa!) > Also, will you help organize and will you (or your company) chip in to > cover costs? Maybe...pretty reasonable chance my company may be able to "chip in" a bit. > > For my part, 1 & 2 would be best, I'm not sure about 3 & 4 yet, I can > help organize, and I don't yet know about sponsorship. > More discussion on this...I think we can get a pretty cool community event going. > Thanks, >Aaron
Next Geronimo Community Meeting
Well, I think it's adequately clear that people think we ought to run our meetings differently. Can we set up a next meeting, which everyone is invited to? We'll need people to help organize, as well as to cover the space, food, and telecom, but this should not be unmanageable. Of the people who would be interested in attending a project meeting, which of these work for you? 1) TheServerSide Barcelona 2) ApacheCon Dublin 3) OSCon Portland 4) ApacheCon Austin 5) Other Also, will you help organize and will you (or your company) chip in to cover costs? For my part, 1 & 2 would be best, I'm not sure about 3 & 4 yet, I can help organize, and I don't yet know about sponsorship. Thanks, Aaron
Re: Frustrations of a Release Manager
Please see below: On 6/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Alan, Forwarding to dev with your permission. Let's just bring all issues into the open and use this opportunity to vent, clear our heads and hopefully help put our best foot forward from now on. thanks, dims On 6/9/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > This is a private email so that I have things clear in my head. If you > think that it's useful to post to the dev group, that's cool. You have > my permission to forward this email on to whomever you'd like. > > Davanum Srinivas wrote, On 6/9/2006 3:03 PM: > > > Bruce, > > > > If you are again asking for my input here it isIt's plain and > > simple. If there is a forum for discussion, it should be open as much > > as possible. If it's not possible because of either monetary or space > > constraints, then at least there should be some notification whereby > > one can give their input on topics at hand via email and/or IRC. > > How was Aaron's email [1] not a notification? Is there a better way to > provide notes on what one talked about at a conference? Absolutely. Since this is after the fact. there is no other way to inform. I was talking about what needs to be done *before* a F2F. > > If i had known about significant discussions, i'd have brought up the > > topic of how/what my thoughts are on a JAX-WS implementation and the > > lack of a credible JAXB2 implementation. So the "Notes from JavaOne" > > [1] would have brought out the problems we will be facing implementing > > both JAX-WS and JAX-RPC (and using a single SAAJ impl) which could > > have been discussed at this forum. I really have to thank David who > > followed up by initiating discussion on axis-dev [2] after JavaOne. > > You still have time to discuss. What in [1] made you think that the > notes were carved in stone? Yep. Again after the fact. Yes, we had some discussions on axis-dev which i posted. I am still waiting to hear on how other things alluded to in the Notes email are going to weigh in (XFire/Celtix). Specifically interested in how they are planning to implement JAXRPC (the old spec) and rpc/encoded support and saaj and other things that J2EE spec mandates. > > Clearly there was a private list of people who were invited and an > > agenda was drawn up which was not shared with the whole dev team > > either privately or publicly. Typically in all Apache projects, we > > call it a F2F, pre announce it, discuss via email/wiki some of the > > items before hand and thrash out the rest in person. > > Yep. That was a not too good. But people can still discuss things even > afterward, no? People who have these private meetings run the risk of > having to discuss the round if issues a second time if they are not > inclusive. Again. After the fact, yes. Was trying to show how being inclusive will help make the F2F better with a real not made up example. > > > > All it would have taken is *ONE* lousy email asking for input on items > > to be discussed either publicly or privately to all committers. Hiding > > behind facade's like "oh, it was a vendor meeting" or "meeting > > friends" or "We just left out just one person" or "Oh, There was a > > BOF" or a thousand other excuses don't count. > > > I think that what you see are individuals' interpretation of what the > get-together was for themselves. If everyone had the *exact* same story > line then, that would have been truly suspicious. My feeling is that people are trying to say whatever they can to see if it will stick. So far nothing has. My favorite though is "Oh! we did not take a decision!!!" :) > I gotta say. I'm kinda scratching my head about this. I was at the > meeting for the last few minutes but was an active participant in its > formation and I think that it was handled "ok", not great, but "ok". > Nothing was decided and things were reported back to the group. > > Now, compare this to the plugins.com where actual code started going in > and I got grief from fellow PMCers for even pointing it out. I learned > that this came about from a discussion at TSS and it was never > publically reported to anyone. This is what everyone should be craping > their pants about. This was clearly wrong. and the RTC was probably for such behavior. > Bringing the two, to be sure there are others, together points out that > Geronimo is in serious trouble. Pointing out that single J1 meeting > makes it seem kinda "shrill". As i mentioned to you before. The meeting was the last straw IMHO > Thoughts? > > > All you need to think > > about is whether you are being fair to everyone who is engaged in the > > project or not. By "bring the community together", hope you don't mean > > that we just go back to our merry ways and not learn a lesson or two > > from the strong actions by the pmc chair. > > > > Guys, there is something wrong we are doing. Let's fix it > > > +1 > > > > [1] http://marc.theaimsgroup.com/?l=geroni
Re: Frustrations of a Release Manager
Thanks. I just sent a note to Dims before I noticed he forwarded it on to the group: Matt made two comments that reminded me of why it was a bad meeting all around. 1) People explicitly said that they wanted to be at the meeting and they were excluded. 2) The cost of a lunch should never be the deciding factor in a meeting. I take my comments back about the meeting. Regards, Alan Jeff Genender wrote: Great email from Alan. Alan, feel free to share these feelings with the group. I am inspired that you have similar thoughts as many of us (not that I ever even questioned that ;-) ]. Thanks. Jeff Davanum Srinivas wrote: Alan, Forwarding to dev with your permission. Let's just bring all issues into the open and use this opportunity to vent, clear our heads and hopefully help put our best foot forward from now on. thanks, dims On 6/9/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: This is a private email so that I have things clear in my head. If you think that it's useful to post to the dev group, that's cool. You have my permission to forward this email on to whomever you'd like. Davanum Srinivas wrote, On 6/9/2006 3:03 PM: Bruce, If you are again asking for my input here it isIt's plain and simple. If there is a forum for discussion, it should be open as much as possible. If it's not possible because of either monetary or space constraints, then at least there should be some notification whereby one can give their input on topics at hand via email and/or IRC. How was Aaron's email [1] not a notification? Is there a better way to provide notes on what one talked about at a conference? If i had known about significant discussions, i'd have brought up the topic of how/what my thoughts are on a JAX-WS implementation and the lack of a credible JAXB2 implementation. So the "Notes from JavaOne" [1] would have brought out the problems we will be facing implementing both JAX-WS and JAX-RPC (and using a single SAAJ impl) which could have been discussed at this forum. I really have to thank David who followed up by initiating discussion on axis-dev [2] after JavaOne. You still have time to discuss. What in [1] made you think that the notes were carved in stone? Clearly there was a private list of people who were invited and an agenda was drawn up which was not shared with the whole dev team either privately or publicly. Typically in all Apache projects, we call it a F2F, pre announce it, discuss via email/wiki some of the items before hand and thrash out the rest in person. Yep. That was a not too good. But people can still discuss things even afterward, no? People who have these private meetings run the risk of having to discuss the round if issues a second time if they are not inclusive. All it would have taken is *ONE* lousy email asking for input on items to be discussed either publicly or privately to all committers. Hiding behind facade's like "oh, it was a vendor meeting" or "meeting friends" or "We just left out just one person" or "Oh, There was a BOF" or a thousand other excuses don't count. I think that what you see are individuals' interpretation of what the get-together was for themselves. If everyone had the *exact* same story line then, that would have been truly suspicious. I gotta say. I'm kinda scratching my head about this. I was at the meeting for the last few minutes but was an active participant in its formation and I think that it was handled "ok", not great, but "ok". Nothing was decided and things were reported back to the group. Now, compare this to the plugins.com where actual code started going in and I got grief from fellow PMCers for even pointing it out. I learned that this came about from a discussion at TSS and it was never publically reported to anyone. This is what everyone should be craping their pants about. Bringing the two, to be sure there are others, together points out that Geronimo is in serious trouble. Pointing out that single J1 meeting makes it seem kinda "shrill". Thoughts? All you need to think about is whether you are being fair to everyone who is engaged in the project or not. By "bring the community together", hope you don't mean that we just go back to our merry ways and not learn a lesson or two from the strong actions by the pmc chair. Guys, there is something wrong we are doing. Let's fix it +1 [1] http://marc.theaimsgroup.com/?l=geronimo-dev&m=114807250831613&w=2 [2] http://marc.theaimsgroup.com/?t=11484081113&r=1&w=2 I am not disagreeing that Geronimo is in serious trouble. I totally agree with you. Regards, Alan
Re: Frustrations of a Release Manager
Great email from Alan. Alan, feel free to share these feelings with the group. I am inspired that you have similar thoughts as many of us (not that I ever even questioned that ;-) ]. Thanks. Jeff Davanum Srinivas wrote: > Alan, > > Forwarding to dev with your permission. Let's just bring all issues > into the open and use this opportunity to vent, clear our heads and > hopefully help put our best foot forward from now on. > > thanks, > dims > > On 6/9/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> This is a private email so that I have things clear in my head. If you >> think that it's useful to post to the dev group, that's cool. You have >> my permission to forward this email on to whomever you'd like. >> >> Davanum Srinivas wrote, On 6/9/2006 3:03 PM: >> >> > Bruce, >> > >> > If you are again asking for my input here it isIt's plain and >> > simple. If there is a forum for discussion, it should be open as much >> > as possible. If it's not possible because of either monetary or space >> > constraints, then at least there should be some notification whereby >> > one can give their input on topics at hand via email and/or IRC. >> >> How was Aaron's email [1] not a notification? Is there a better way to >> provide notes on what one talked about at a conference? >> >> > >> > If i had known about significant discussions, i'd have brought up the >> > topic of how/what my thoughts are on a JAX-WS implementation and the >> > lack of a credible JAXB2 implementation. So the "Notes from JavaOne" >> > [1] would have brought out the problems we will be facing implementing >> > both JAX-WS and JAX-RPC (and using a single SAAJ impl) which could >> > have been discussed at this forum. I really have to thank David who >> > followed up by initiating discussion on axis-dev [2] after JavaOne. >> >> You still have time to discuss. What in [1] made you think that the >> notes were carved in stone? >> >> > Clearly there was a private list of people who were invited and an >> > agenda was drawn up which was not shared with the whole dev team >> > either privately or publicly. Typically in all Apache projects, we >> > call it a F2F, pre announce it, discuss via email/wiki some of the >> > items before hand and thrash out the rest in person. >> >> Yep. That was a not too good. But people can still discuss things even >> afterward, no? People who have these private meetings run the risk of >> having to discuss the round if issues a second time if they are not >> inclusive. >> >> > >> > All it would have taken is *ONE* lousy email asking for input on items >> > to be discussed either publicly or privately to all committers. Hiding >> > behind facade's like "oh, it was a vendor meeting" or "meeting >> > friends" or "We just left out just one person" or "Oh, There was a >> > BOF" or a thousand other excuses don't count. >> >> >> I think that what you see are individuals' interpretation of what the >> get-together was for themselves. If everyone had the *exact* same story >> line then, that would have been truly suspicious. >> >> I gotta say. I'm kinda scratching my head about this. I was at the >> meeting for the last few minutes but was an active participant in its >> formation and I think that it was handled "ok", not great, but "ok". >> Nothing was decided and things were reported back to the group. >> >> Now, compare this to the plugins.com where actual code started going in >> and I got grief from fellow PMCers for even pointing it out. I learned >> that this came about from a discussion at TSS and it was never >> publically reported to anyone. This is what everyone should be craping >> their pants about. >> >> Bringing the two, to be sure there are others, together points out that >> Geronimo is in serious trouble. Pointing out that single J1 meeting >> makes it seem kinda "shrill". >> >> Thoughts? >> >> > All you need to think >> > about is whether you are being fair to everyone who is engaged in the >> > project or not. By "bring the community together", hope you don't mean >> > that we just go back to our merry ways and not learn a lesson or two >> > from the strong actions by the pmc chair. >> > >> > Guys, there is something wrong we are doing. Let's fix it >> >> >> +1 >> >> > >> > [1] http://marc.theaimsgroup.com/?l=geronimo-dev&m=114807250831613&w=2 >> > [2] http://marc.theaimsgroup.com/?t=11484081113&r=1&w=2 >> >> >> I am not disagreeing that Geronimo is in serious trouble. I totally >> agree with you. >> >> Regards, >> Alan >> >> > >
Re: [jira] Commented: (GERONIMO-1638) Multiple servers sharing the same repo and config store
Hi Dave, Thanks for pointing this problem out. I simply forget to provide an AMQ patch to fix it; this is now done: http://issues.apache.org/activemq/browse/AMQ-746. Also, this feature is broken in 1.1. Basically, SharedLib and FileKeystoreManager do not properly resolve their resources and, as a consequence, the server simply shuts down. Thanks, Gianny Dave Colasurdo wrote: BTW, I think additional fixes are required in 1.1.1 before claiming support for multiple concurrent server instances from a single installation.. Awhile back I was able to start the server using an external var directory (via -Dorg.apache.geronimo.server.dir). After changing all the ports and trying to start a second instance from the default location, I encountered a startup exception regarding the activemq transaction journal. Suspect code changes are needed to relocate the journal to a location outside the installation directory. Thanks -Dave- John Sisson (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12415496 ] John Sisson commented on GERONIMO-1638: --- Currently working on scripts as discussed at http://www.mail-archive.com/dev@geronimo.apache.org/msg22807.html . Have made changes but they need to be tested on windows, cygwin and unix, so looks like this is going to be for 1.1.1 . Multiple servers sharing the same repo and config store --- Key: GERONIMO-1638 URL: http://issues.apache.org/jira/browse/GERONIMO-1638 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: usability Versions: 1.0 Reporter: Gianny Damour Assignee: John Sisson Fix For: 1.1 David J. sent to the dev mailing list: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are "located" outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to "relocate". I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like "resolveVar" and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the "var" trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now "var". Several people have suggested putting an additional config-store into var for "private" use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
[jira] Commented: (GERONIMO-1638) Multiple servers sharing the same repo and config store
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12415636 ] Gianny Damour commented on GERONIMO-1638: - Open a JIRA to fix the AMQ problem reported by Dave Colasurdo. http://issues.apache.org/activemq/browse/AMQ-746 > Multiple servers sharing the same repo and config store > --- > > Key: GERONIMO-1638 > URL: http://issues.apache.org/jira/browse/GERONIMO-1638 > Project: Geronimo > Type: New Feature > Security: public(Regular issues) > Components: usability > Versions: 1.0 > Reporter: Gianny Damour > Assignee: John Sisson > Fix For: 1.1 > Attachments: GERONIMO-1638.patch > > David J. sent to the dev mailing list: > Many people have talked on and off about how to set up multiple servers > sharing the same repository and config-store, but we haven't arrived at an > agreed on way to do it. We have a prospective customer for this feature > (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in > my head, discuss it, and have someone implement it. I believe any > implementation will be more or less trivial, the hard part is figuring out > what to do. > I've only thought of ways to extend what we have now, rather than > restructure anything or add big new capabilities. If someone sees a better > way, please speak up. > So, we have a ServerInfo gbean that knows where geronimo is located and can > resolve absolute locations for other components. Then we have things like > the repository and config store gbeans that typically are "located" outside > the var dir and things like the logging framework, local attribute manager, > derby, and tomcat, that typically keep stuff in the var directory. > All or most of these start with the first configuration loaded so they can't > have any attributes overridden by config.xml: in fact this file is read by > one of the gbeans that we need to "relocate". > I've thought of two related solutions. Both of them involve giving > ServerInfo knowledge of another path and another resolve method. > One would be something like "resolveVar" and would normally resolve to > geronimo_home/var. This would involve all the gbeans currently looking > inside var having the "var" trimmed off the front of their paths and using > the new resolveVar method. In this case we'd have different servers > represented as e.g. > var1 > var2 > var3 > ... > The other would give ServerInfo something like resolveServer which would > normally resolve to geronimo_home. The gbeans looking inside var would keep > their current paths and just call the new resolve method instead of the old > one. In this case we'd have servers like > var > server1/var > server2/var > ... > In either case I think starting geronimo with a command line argument > pointing to the var directory is the only way to specify which server you > want to run; the default would presumably be as now "var". > Several people have suggested putting an additional config-store into var > for "private" use by a particular server. At the moment I think that > providing a different config-store class that uses the new resolve method > on server info would be the best way to do this. > I'm not attached to these ideas but this is as far as my thinking has gone. > Please comment. > thanks > david jencks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Frustrations of a Release Manager
3.5 months for the planned cycle seems a bit two long especially when you think it would be reasonable to bump it for something important. I personally would like to see 2 months planned, so if it runs long we are closer to 3 months instead of 4. -dain On Jun 9, 2006, at 4:22 PM, Aaron Mulder wrote: On 6/9/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Sounds good. Can you put together a time table representation of this idea? It would help me understand the nuances. Hypothentically speaking, here's a 3.5-month schedule for 1.2: June 12: 1.1 released - select release manager for 1.2 - set goals for 1.2 July 1: 1.2-M1 released July 21: 1.2-M2 released August 14: 1.2-beta1 released Sep 1: 1.2-beta2 released, no new features Sep 14: 1.2-rc1 released, no non-critical bugs - 1.3-SNAPSHOT branch created Sep 21: 1.2-rc2 released Sep 27: vote on 1.2-rc2 as 1.2 Oct 1: release 1.2 Though perhaps we could move the feature/bug freezes down one release. And, of course, if a lot of problems were discovered in, say, 1.2-rc1 then perhaps we'd introduce an extra 1-2 week rc into the plan. What do you think? Thanks, Aaron
[jira] Updated: (GERONIMO-1638) Multiple servers sharing the same repo and config store
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=all ] Gianny Damour updated GERONIMO-1638: Attachment: GERONIMO-1638.patch This is a patch which fixes a couple of relocation issues for SharedLib and FileKeystoreManager. > Multiple servers sharing the same repo and config store > --- > > Key: GERONIMO-1638 > URL: http://issues.apache.org/jira/browse/GERONIMO-1638 > Project: Geronimo > Type: New Feature > Security: public(Regular issues) > Components: usability > Versions: 1.0 > Reporter: Gianny Damour > Assignee: John Sisson > Fix For: 1.1 > Attachments: GERONIMO-1638.patch > > David J. sent to the dev mailing list: > Many people have talked on and off about how to set up multiple servers > sharing the same repository and config-store, but we haven't arrived at an > agreed on way to do it. We have a prospective customer for this feature > (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in > my head, discuss it, and have someone implement it. I believe any > implementation will be more or less trivial, the hard part is figuring out > what to do. > I've only thought of ways to extend what we have now, rather than > restructure anything or add big new capabilities. If someone sees a better > way, please speak up. > So, we have a ServerInfo gbean that knows where geronimo is located and can > resolve absolute locations for other components. Then we have things like > the repository and config store gbeans that typically are "located" outside > the var dir and things like the logging framework, local attribute manager, > derby, and tomcat, that typically keep stuff in the var directory. > All or most of these start with the first configuration loaded so they can't > have any attributes overridden by config.xml: in fact this file is read by > one of the gbeans that we need to "relocate". > I've thought of two related solutions. Both of them involve giving > ServerInfo knowledge of another path and another resolve method. > One would be something like "resolveVar" and would normally resolve to > geronimo_home/var. This would involve all the gbeans currently looking > inside var having the "var" trimmed off the front of their paths and using > the new resolveVar method. In this case we'd have different servers > represented as e.g. > var1 > var2 > var3 > ... > The other would give ServerInfo something like resolveServer which would > normally resolve to geronimo_home. The gbeans looking inside var would keep > their current paths and just call the new resolve method instead of the old > one. In this case we'd have servers like > var > server1/var > server2/var > ... > In either case I think starting geronimo with a command line argument > pointing to the var directory is the only way to specify which server you > want to run; the default would presumably be as now "var". > Several people have suggested putting an additional config-store into var > for "private" use by a particular server. At the moment I think that > providing a different config-store class that uses the new resolve method > on server info would be the best way to do this. > I'm not attached to these ideas but this is as far as my thinking has gone. > Please comment. > thanks > david jencks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
1.1 Blocker - Bad deployment jams repo
I thought maybe we could punt on this, but after using the current build just a little bit, it's really nasty. If a deployment fails, you can't deploy that same module again (ever) without manually deleting files from the repository: http://issues.apache.org/jira/browse/GERONIMO-2101 I think we need to fix this for 1.1. I don't know if the better solution is to try to delete the files from the repository when the deployment fails, or to be willing to overwrite when a new deployment finds old files already there. Any suggestions? Thanks, Aaron
[jira] Created: (GERONIMO-2101) Deployment failures prevent future deployments
Deployment failures prevent future deployments -- Key: GERONIMO-2101 URL: http://issues.apache.org/jira/browse/GERONIMO-2101 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1 If you deploy and there's an error, the next deploy attempt invariably gets: Error: Unable to distribute foo-1.0.jar: org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException: Configuration already exists: bar/foo/1.0/car In other words, the bad deployment was written into the repository but not deleted when the deployment failed, and is now blocking future deployments. The only solution seems to be to manually delete the offending directory from the repository. -- 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: [Build error] - I can not build a freash copy of r411545
On Jun 9, 2006, at 9:13 PM, Mohammed Nour wrote:Hi All... I did what u told me Joe and guess what, at last I can say Geronim :), I got a successful build, I guess the whole problem was the length of the directory within which I put src code. Thanks a lot guys :) Hey Mohammed,Congrats! +1 for your perseverance. Things can get a bit tough as we near the end of a release cycle. Hopefully the big obstacles are out of the way. Let us know how things go for you...--kevan On 6/8/06, Joe Bohn <[EMAIL PROTECTED]> wrote: FWIW, I updated my 1.1 image earlier today (rev. 412818 along withopenejb) and did a successful online build on windows xp using "maven m:clean new". It built on the first attempt with no problems (not evena download error which is really unusual in my experience). My rootpath is relatively short ("c:\geronimo1.1") so I didn't hit the path-length errors. Of course all of this was after the specs,openejb, etc... had been updated. It might be worth-while to startover at this point, checkout geronimo 1.1 and openejb, and give itanother try. JoeMatt Hogstrom wrote:> Unfortunately we've burned up a lot of real estate in Geronimo. Windows> users are adversely affected by this. The only way to address this> problem in the short term Mohammed is to shorten your path. >> I'll checkout a fresh copy of 1.1 as I've seen other traffic on the list> indicating a build problem.>> Mohammed Nour wrote:>>> Hi All... I succeeded to pass the point of build error by bypassing building both * >> daytrader* and *servlet-examples* projects. But I got another error in>> the>> assembly phase because of path is too long, which is a Windows>> problem. Is>> there any work-around to overcome this problem other than making another >> copy of *G* source to be more shalow on the dir heirarchy of Windows>> directories ??? --->> "Never give up, Never..." >> --->> *Thanks and best regards>> Mohammad Nour El-Din*>> On 6/8/06, Mohammed Nour < [EMAIL PROTECTED]> wrote:> Hi Matt...>> I did what you told me to do, I ceched out the specs, built them>>> using *maven>>> install* command, tryied to build G again but failed with the same error >>> of ClassNotFoundException.>> I am trying to trace this error, but anybody knows about the solution of>>> this problem please help?>> I would like to mention that I am using: >> WindowsXP, Java 1.4.2_11, Maven 1.1b2>> --->>> "Never give up, Never...">>> --- >>> *Thanks and best regards>>> Mohammad Nour El-Din>>> *> On 6/6/06, Matt Hogstrom < [EMAIL PROTECTED]> wrote:>> > Mohammed,>>> > You need to checkout the spec independent of Geronimo. Do an >>> > svn co http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1>>> > cd to that directory and execute: >>> > mvn install>>> > This will update your specs and you should be good to go.>>> > Matt>>> > >>> > Mohammed Nour wrote:>>> > > Hi All...>>> > > > I failed again to build a brand new fresh copy og *G,* and here>>> is the >>> > link>>> > > of the build error>>> > > http://rifers.org/paste/show/886>>> > > > -- >>> > > "Never give up, Never...">>> > > -->>> > > *Thanks and best regards...*>>> > > *Mohammad Nour El-Din* >>> > > > > > On 6/5/06, Bryan Noll <[EMAIL PROTECTED]> wrote:>>> > > >>> > >> Mohammad,>>> > > > >> I was having the same issue you were just the other day. I got>>> it to>>> > >> work >>> > >> by doing the following:>>> > > > >> maven -Dmaven.test.skip -Dmaven.itest.skip>>> > > > >> >>> > > > > > >> David Jencks wrote:>>> > > > > > >> On Jun 4, 2006, at 6:58 AM, Mohammed Nour wrote: >>> > > > >> Hi All...>>> > > > >> I've been struggling too long trying to building G, but all my>>> tries>>> > >> failed. I got a fresh copy of r411545 and got the following error >>> > while>>> > >> trying to build it>>> > > > >> http://rifers.org/paste/show/877>>> > >> >>> > >> I talked with djencks on IRC and he ask me to try building>>> TrnaQl and>>> > >> OEJB>>> > >> separatly and then try to build G again, but while I am trying to >>> > >> build OEJB>>> > >> I got the following error>>> > > > >> http://rifers.org/paste/show/878 >>> > > > > > > > >> All the parts of openejb that are known to build, built for>>> you. We>>> > are >>> > >> currently only using core, openejb-builder, and pkgen-builder. I'm>>> > >> afraid>>> > >> that I am so used to how I build openejb from within geronimo I >>> > forget>>> > >> that>>> > >> there are other ways.>>> > > > > > >> What I do is check out openejb inside geronimo using >>> > >> maven m:co>>> > > > > > >> which checks out the correct version (2.
Re: maven-itest-plugin
http://people.apache.org/repository/maven/plugins/ On 6/9/06, Jay D. McHugh <[EMAIL PROTECTED]> wrote: Hello all, I am trying to build 1.1 from source and I am running into an unfulfilled dependency: maven-itest-plugin-1.0.jar When I try to find it to manually download it (as some pages I found on google suggested) I find that it is apparently no longer a valid maven plugin. How do I get around this? Thanks in advance, Jay -- Davanum Srinivas : http://wso2.com/blogs/
Re: Frustrations of a Release Manager
Alan, Forwarding to dev with your permission. Let's just bring all issues into the open and use this opportunity to vent, clear our heads and hopefully help put our best foot forward from now on. thanks, dims On 6/9/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: This is a private email so that I have things clear in my head. If you think that it's useful to post to the dev group, that's cool. You have my permission to forward this email on to whomever you'd like. Davanum Srinivas wrote, On 6/9/2006 3:03 PM: > Bruce, > > If you are again asking for my input here it isIt's plain and > simple. If there is a forum for discussion, it should be open as much > as possible. If it's not possible because of either monetary or space > constraints, then at least there should be some notification whereby > one can give their input on topics at hand via email and/or IRC. How was Aaron's email [1] not a notification? Is there a better way to provide notes on what one talked about at a conference? > > If i had known about significant discussions, i'd have brought up the > topic of how/what my thoughts are on a JAX-WS implementation and the > lack of a credible JAXB2 implementation. So the "Notes from JavaOne" > [1] would have brought out the problems we will be facing implementing > both JAX-WS and JAX-RPC (and using a single SAAJ impl) which could > have been discussed at this forum. I really have to thank David who > followed up by initiating discussion on axis-dev [2] after JavaOne. You still have time to discuss. What in [1] made you think that the notes were carved in stone? > Clearly there was a private list of people who were invited and an > agenda was drawn up which was not shared with the whole dev team > either privately or publicly. Typically in all Apache projects, we > call it a F2F, pre announce it, discuss via email/wiki some of the > items before hand and thrash out the rest in person. Yep. That was a not too good. But people can still discuss things even afterward, no? People who have these private meetings run the risk of having to discuss the round if issues a second time if they are not inclusive. > > All it would have taken is *ONE* lousy email asking for input on items > to be discussed either publicly or privately to all committers. Hiding > behind facade's like "oh, it was a vendor meeting" or "meeting > friends" or "We just left out just one person" or "Oh, There was a > BOF" or a thousand other excuses don't count. I think that what you see are individuals' interpretation of what the get-together was for themselves. If everyone had the *exact* same story line then, that would have been truly suspicious. I gotta say. I'm kinda scratching my head about this. I was at the meeting for the last few minutes but was an active participant in its formation and I think that it was handled "ok", not great, but "ok". Nothing was decided and things were reported back to the group. Now, compare this to the plugins.com where actual code started going in and I got grief from fellow PMCers for even pointing it out. I learned that this came about from a discussion at TSS and it was never publically reported to anyone. This is what everyone should be craping their pants about. Bringing the two, to be sure there are others, together points out that Geronimo is in serious trouble. Pointing out that single J1 meeting makes it seem kinda "shrill". Thoughts? > All you need to think > about is whether you are being fair to everyone who is engaged in the > project or not. By "bring the community together", hope you don't mean > that we just go back to our merry ways and not learn a lesson or two > from the strong actions by the pmc chair. > > Guys, there is something wrong we are doing. Let's fix it +1 > > [1] http://marc.theaimsgroup.com/?l=geronimo-dev&m=114807250831613&w=2 > [2] http://marc.theaimsgroup.com/?t=11484081113&r=1&w=2 I am not disagreeing that Geronimo is in serious trouble. I totally agree with you. Regards, Alan -- Davanum Srinivas : http://wso2.com/blogs/
Re: Some features for 1.1.1 -- module/deployment extensions
That's already possible. I had it working earlier, but we need to recreate the metadata file for it that lists the modules to add and the modules to remove. If you get a chance, could you look at project.xml for the J2EE assemblies vs. the minimal assemblies and make a list of all the Geronimo modules in the two? Such as: module J2EE minimal system yes yes unavailable-webservices-deployer no yes ... We can use a list like that to create the plugin metadata to upgrade minimal to full J2EE. Thanks, Aaron On 6/9/06, Donald Woods <[EMAIL PROTECTED]> wrote: Would this also enable the scenario of someone wanting to upgrade a minimal-tomcat-server with the unavailable-webservices-deployer to include the Axis and Axis-builder modules? -Donald Aaron Mulder wrote: > FYI, I plan to address > http://issues.apache.org/jira/browse/GERONIMO-1873 as soon as possible > in 1.1.1. I'd like plugins to be able to define new deployment unit > formats (e.g. JBI service assemblies, a Spring deployment unit, a > Quartz job as a deployment unit, or a Jasper report as a deployment > unit). > > Any of those will probably need a geronimo-XYZ.xml deployment plan, to > supply a module ID and dependencies if nothing else. And currently, > the deploy tool doesn't know how to crack open an arbitrary deployment > unit and figure out its module ID, which is necessary to support > redeployment when the plan is embedded in the archive (it has to know > what existing module(s) to replace). > > There are two possible solutions: one is to stop using JSR-88 for > deployment and just pass the archive to the server and let it do its > thing; the other is to let each deployer indicate the name of its > deployment plan (when the plan is packed in the module). I'd lean > toward the second approach for 1.1.1, as it's a fairly trivial change. > > A related question is whether we should let you pack non-J2EE > deployment units in an EAR. That is, if we define a JasperReports > report deployment unit, should your EAR be able to contain a WAR, an > EJB JAR, and 2 reports? I would think so, though we may choose to > implement a wrapper that would hold the EAR and the 2 reports instead. > I'm not sure how extensive a change this might require -- we seem to > have some special handling for classpaths for modules within an EAR, > and I don't know where that happens and what's likely to break. > > If we do nothing, the alternative is that you'd only be able to > redeploy new types of modules if you pass either the module ID or the > plan on the command line along with the archive (no packing plan in > archive), and if you had a J2EE app and a handful of other modules > that all work together, you would still have to deploy/redeploy them > all individually. > > Thanks, >Aaron > >
Re: JIRA project for GShell?
+1 On Jun 9, 2006, at 10:50 AM, Jason Dillon wrote: Can we create a new JIRA project for GShell? I've got a bunch of task/todo items that I would like to track in JIRA so it is easier to prioritize and plan. Thoughts? --jason -sachin
Re: Some features for 1.1.1 -- module/deployment extensions
Would this also enable the scenario of someone wanting to upgrade a minimal-tomcat-server with the unavailable-webservices-deployer to include the Axis and Axis-builder modules? -Donald Aaron Mulder wrote: FYI, I plan to address http://issues.apache.org/jira/browse/GERONIMO-1873 as soon as possible in 1.1.1. I'd like plugins to be able to define new deployment unit formats (e.g. JBI service assemblies, a Spring deployment unit, a Quartz job as a deployment unit, or a Jasper report as a deployment unit). Any of those will probably need a geronimo-XYZ.xml deployment plan, to supply a module ID and dependencies if nothing else. And currently, the deploy tool doesn't know how to crack open an arbitrary deployment unit and figure out its module ID, which is necessary to support redeployment when the plan is embedded in the archive (it has to know what existing module(s) to replace). There are two possible solutions: one is to stop using JSR-88 for deployment and just pass the archive to the server and let it do its thing; the other is to let each deployer indicate the name of its deployment plan (when the plan is packed in the module). I'd lean toward the second approach for 1.1.1, as it's a fairly trivial change. A related question is whether we should let you pack non-J2EE deployment units in an EAR. That is, if we define a JasperReports report deployment unit, should your EAR be able to contain a WAR, an EJB JAR, and 2 reports? I would think so, though we may choose to implement a wrapper that would hold the EAR and the 2 reports instead. I'm not sure how extensive a change this might require -- we seem to have some special handling for classpaths for modules within an EAR, and I don't know where that happens and what's likely to break. If we do nothing, the alternative is that you'd only be able to redeploy new types of modules if you pass either the module ID or the plan on the command line along with the archive (no packing plan in archive), and if you had a J2EE app and a handful of other modules that all work together, you would still have to deploy/redeploy them all individually. Thanks, Aaron smime.p7s Description: S/MIME Cryptographic Signature
[jira] Updated: (GERONIMO-1637) Add support for version ranges
[ http://issues.apache.org/jira/browse/GERONIMO-1637?page=all ]
Donald Woods updated GERONIMO-1637:
---
Component: Plugins
(was: kernel)
Fix Version: 1.1.1
Version: 1.1
If we release a 1.1.1, then we need a solution for this in 1.1.1.
How about the following slight modification, so it would also work for
-SNAPSHOT or private -REVISION builds?
if (version.equals(gerVersion) ||
(gerVersion.endsWith("*") &&
version.startsWith(gerVersion.substring(0, gerVersion.length()-1))) {
The other choice, would be to treat "." and "-" differently, as in
if ( version.equals(gerVersion) ||
((gerVersion.endsWith(".*") && version.startsWith(gerVersion.substring(0,
gerVersion.length()-2)) ||
((gerVersion.endsWith("-*") && version.startsWith(gerVersion.substring(0,
gerVersion.length()-2)) ) {
which has the requirement that plugins being developed and tested against
-SNAPSHOT builds be rereleased for the final .rcN or 1.N build
-Donald
Dain Sundstrom wrote:
> On Jun 9, 2006, at 2:13 PM, Aaron Mulder wrote:
>
>> My main objection to that is then there's no way to say "1.1 only".
>> We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
>> different. Or, I suppose, change your patch to gerVersion.length()-1
>> and encourage "1.1*" not "1.1.*"
>
>
>
> I guess my code was bad. My intention was you could call out specific
> versions. Here is a table of what I wanted to happen:
>
> Input Version Range
> - -
> 1.1 1.1
> 1.1.* [1.1-1.2)
> 1.1.1 1.1.1
> 1.1.1.* [1.1.1-1.1.2)
>
> and here is the code I posted for those that don't wan to read back in the
> thread:
>
> if (version.equals(gerVersion) ||
> (gerVersion.endsWith(".*" &&
> version.startsWith(gerVersion.substring(0, gerVersion.length () -
> 2))) {
>
> With that if statement, the "glob" part of the match only executes if the
> version ended with ".*" otherwise it must be an exact match.
>
> -dain
>
>
> Add support for version ranges
> --
>
> Key: GERONIMO-1637
> URL: http://issues.apache.org/jira/browse/GERONIMO-1637
> Project: Geronimo
> Type: Improvement
> Security: public(Regular issues)
> Components: Plugins
> Versions: 1.1
> Reporter: Dain Sundstrom
> Assignee: Dain Sundstrom
> Fix For: 1.2, 1.1.1
>
> Add support for the version ranges on dependencies. Should support the full
> syntax of maven version ranges.
--
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: [Build error] - I can not build a freash copy of r411545
Hi All...
I did what u told me Joe and guess what, at last I can say Geronim :), I got a successful build, I guess the whole problem was the length of the directory within which I put src code. Thanks a lot guys :)
On 6/8/06, Joe Bohn <[EMAIL PROTECTED]> wrote:
FWIW, I updated my 1.1 image earlier today (rev. 412818 along withopenejb) and did a successful online build on windows xp using "maven
m:clean new". It built on the first attempt with no problems (not evena download error which is really unusual in my experience). My rootpath is relatively short ("c:\geronimo1.1") so I didn't hit the
path-length errors. Of course all of this was after the specs,openejb, etc... had been updated. It might be worth-while to startover at this point, checkout geronimo 1.1 and openejb, and give itanother try.
JoeMatt Hogstrom wrote:> Unfortunately we've burned up a lot of real estate in Geronimo. Windows> users are adversely affected by this. The only way to address this> problem in the short term Mohammed is to shorten your path.
>> I'll checkout a fresh copy of 1.1 as I've seen other traffic on the list> indicating a build problem.>> Mohammed Nour wrote:>>> Hi All... I succeeded to pass the point of build error by bypassing building both *
>> daytrader* and *servlet-examples* projects. But I got another error in>> the>> assembly phase because of path is too long, which is a Windows>> problem. Is>> there any work-around to overcome this problem other than making another
>> copy of *G* source to be more shalow on the dir heirarchy of Windows>> directories ??? --->> "Never give up, Never..."
>> --->> *Thanks and best regards>> Mohammad Nour El-Din*>> On 6/8/06, Mohammed Nour <
[EMAIL PROTECTED]> wrote:> Hi Matt...>> I did what you told me to do, I ceched out the specs, built them>>> using *maven>>> install* command, tryied to build G again but failed with the same error
>>> of ClassNotFoundException.>> I am trying to trace this error, but anybody knows about the solution of>>> this problem please help?>> I would like to mention that I am using:
>> WindowsXP, Java 1.4.2_11, Maven 1.1b2>> --->>> "Never give up, Never...">>> ---
>>> *Thanks and best regards>>> Mohammad Nour El-Din>>> *> On 6/6/06, Matt Hogstrom <
[EMAIL PROTECTED]> wrote:>> > Mohammed,>>> > You need to checkout the spec independent of Geronimo. Do an
>>> > svn co http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1>>> > cd to that directory and execute:
>>> > mvn install>>> > This will update your specs and you should be good to go.>>> > Matt>>> >
>>> > Mohammed Nour wrote:>>> > > Hi All...>>> > > > I failed again to build a brand new fresh copy og *G,* and here>>> is the
>>> > link>>> > > of the build error>>> > > http://rifers.org/paste/show/886>>> > > > --
>>> > > "Never give up, Never...">>> > > -->>> > > *Thanks and best regards...*>>> > > *Mohammad Nour El-Din*
>>> > > > > > On 6/5/06, Bryan Noll <[EMAIL PROTECTED]> wrote:>>> > >
>>> > >> Mohammad,>>> > > > >> I was having the same issue you were just the other day. I got>>> it to>>> > >> work
>>> > >> by doing the following:>>> > > > >> maven -Dmaven.test.skip -Dmaven.itest.skip>>> > > > >>
>>> > > > > > >> David Jencks wrote:>>> > > > > > >> On Jun 4, 2006, at 6:58 AM, Mohammed Nour wrote:
>>> > > > >> Hi All...>>> > > > >> I've been struggling too long trying to building G, but all my>>> tries>>> > >> failed. I got a fresh copy of r411545 and got the following error
>>> > while>>> > >> trying to build it>>> > > > >> http://rifers.org/paste/show/877>>> > >>
>>> > >> I talked with djencks on IRC and he ask me to try building>>> TrnaQl and>>> > >> OEJB>>> > >> separatly and then try to build G again, but while I am trying to
>>> > >> build OEJB>>> > >> I got the following error>>> > > > >> http://rifers.org/paste/show/878
>>> > > > > > > > >> All the parts of openejb that are known to build, built for>>> you. We>>> > are
>>> > >> currently only using core, openejb-builder, and pkgen-builder. I'm>>> > >> afraid>>> > >> that I am so used to how I build openejb from within geronimo I
>>> > forget>>> > >> that>>> > >> there are other ways.>>> > > > > > >> What I do is check out openejb inside geronimo using
>>> > >> maven m:co>>> > > > > > >> which checks out the correct version (2.1-SNAPSHOT at the moment)>>> > >>
>>> > > > >> and build it using>>> > >> maven new2>>> > > > > > >> What command did you use?
>>> > > > > > >> In any case you should be able to proceed with your geronimo build>>> > now.>>> > > > >
Re: 1.1 Release plan
I think this is a good plan. Kevan and I have been working on what we eventually registered as GERONIMO-2100. This has been causing intermittent tck failures and as it is a security problem and the fix is pretty straightforward I think it's worth including in 1.1: thus I committed it. The other issue I think might be worth considering for 1.1 depending on whether it is actually fixed is GERONIMO-2079, a race condition on ejb startup. I've been studying dain's proposal and can't decide if it relies on double-checked locking. I'm going to try to run it under load and propose that if it works there we commit it. Who is tagging and releasing openejb? thanks david jencks On Jun 8, 2006, at 8:23 PM, Matt Hogstrom wrote: Final Items for 1.1 I would like to release Geronimo 1.1 on June 12th. Yes, that is three days away. If we can't make that date then it will be 72 hours away from each candidate build. Problem that are found need to be addressed if they are deemed critical. Otherwise they will be tracked and solved in a follow on release. That said. I sent a note earlier today announcing the freeze to branches/1.1. Changes to this branch should be limited to bug fixes only. The little changes are the ones that generally burn you. At 1400 ET the Inn is closed and I will spin up a release that will be our release candidate. The issues that have been raised from the previous build were Guillaume's observation of the problem when running Geronimo under CygWin as well as the license and Notice issues. Since Geronimo is a multifaceted project there are several things that need to be voted on. They are Geronimo itself, the specification jars and DayTrader. Geronimo itself is the significant component that will carry the other items so I believe a vote for Geronimo in this context is a vote for all three items. *There is a concern about the specification jars* David Jencks raised this issue in another note on the list. The jars have not been released but they have had a tag cut and the resulting compilation has been placed on http://people.apache.org/ repository. One of the issues I found with the spec is that there are different spec releases in the 1_1 tag. I would prefer that all jars have the same version suffix. Right now it includes 1.0, 1.0.1, 1.1 and others. I think this is confusing. We release Geronimo with all the same module versions even if nothing has changed. I would like to move that we recut a 1_2 tag with all spec jars having a 1.2 suffix. *DayTrader* Day Trader is currently a 1.1-SNAPSHOT as well. We will release the DayTrader Ear (separate from Geronimo) as a 1.1 version as well. This way the build will be in sync. *Issues* 1. It was noted earlier today that there is a problem with Geronimo under CygWin. Guillaume noted that an issue exists where a file is not renamed (config.xml). Given that CygWin is a hybrid environment I think we should investigate this problem but not hold up the release. 2. Guillaume also pointed out the lack of a License and Notices file. I will include the two files from the SVN geronimo/branches/ 1.1 in the build tomorrow. 3. Numerous bug fixes are being addressed. Excellent. Apart from Spec issue above I think we have most everything addressed. Does this list of outstanding items and release plan make sense? Matt
[jira] Closed: (GERONIMO-2100) Subject can remain attached to thread on return from web app request, causing problems later on subsequent use of that thread
[ http://issues.apache.org/jira/browse/GERONIMO-2100?page=all ]
David Jencks closed GERONIMO-2100:
--
Resolution: Fixed
Fixed in trunk (1.2) rev 413195
Fixed in 1.1 rev 413196
>From the stack trace I'm not convinced that defaultSubject is set properly
>while traversing the web services handler chain, but "null" is better than a
>random value for sure.
> Subject can remain attached to thread on return from web app request, causing
> problems later on subsequent use of that thread
> -
>
> Key: GERONIMO-2100
> URL: http://issues.apache.org/jira/browse/GERONIMO-2100
> Project: Geronimo
> Type: Bug
> Security: public(Regular issues)
> Components: web
> Versions: 1.2, 1.1
> Reporter: David Jencks
> Assignee: David Jencks
> Priority: Blocker
> Fix For: 1.2, 1.1
>
> there's no code to reset ContextManager.currentCaller in the jetty
> integration. It gets set o.m.j.servlet.WebApplicationHandler.dispatch
> checking security credentials >> InternalJAASJettyRealm, and also by
> JettyEJBWebServiceContext somewhat more directly.
> The problem appears to occur when a subject is left on a thread and the
> thread is used for an unauthenticated ejb web services call. The
> responsibility for setting the subject on unauthenticated ejb web services
> calls is too distributed, but what actually sets it is
> GenericEJBContainer.DefaultSubjectInterceptor, which only installs the
> defaultSubject if there is no subject already set.
> A minimal fix is to set the currentCaller to null if no authentication is
> needed in JettyEJBWebServiceContext:
> if (authenticator != null) {
> String pathInContext =
> org.mortbay.util.URI.canonicalPath(req.getPath());
> if (authenticator.authenticate(realm, pathInContext, req,
> res) == null) {
> throw new HttpException(403);
> }
> } else {
> //EJB will figure out correct defaultSubject shortly
> //TODO Need to check that the handler chain will see the
> correct defaultSubject
> ContextManager.setCurrentCaller(null);
> }
> However, it would be much better to make sure that in addition the subject
> can't escape back into the calling environment. This can be done easily in
> JettyEJBWebServiceContext but requires a simple subclass of
> o.m.j.servletWebApplicationHandler for normal servlet requests.
--
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 project for GShell?
GShell isn't gonna die... it will rule the world one day... its already kicking much ass. Unix geeks are gonna love us... :-] --jason On 6/9/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Jun 9, 2006, at 9:35 AM, Alan D. Cabrera wrote: > Jason Dillon wrote: >> Can we create a new JIRA project for GShell? I've got a bunch of >> task/todo items that I would like to track in JIRA so it is easier >> to prioritize and plan. >> >> Thoughts? >> >> --jason >> > IMO, if it gets out of the sandbox, it deserves a Jira project. I seen no reason not to give it a JIRA. If it dies in the sandbox, we can always delete the JIRA. -dain
[jira] Commented: (GERONIMO-2100) Subject can remain attached to thread on return from web app request, causing problems later on subsequent use of that thread
[
http://issues.apache.org/jira/browse/GERONIMO-2100?page=comments#action_12415626
]
Kevan Miller commented on GERONIMO-2100:
For posterity, here's the error that you get:
07:47:21,992 WARN [SystemExceptionInterceptor] MyEjbTest
java.lang.AssertionError: No registered context
at
org.apache.geronimo.security.ContextManager.getCurrentContext(ContextManager.java:129)
at
org.openejb.security.EJBSecurityInterceptor.invoke(EJBSecurityInterceptor.java:95)
at
org.openejb.slsb.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:98)
at
org.openejb.transaction.ContainerPolicy$TxSupports.invoke(ContainerPolicy.java:198)
at
org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:80)
at
org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82)
at
org.openejb.GenericEJBContainer$DefaultSubjectInterceptor.invoke(GenericEJBContainer.java:547)
at org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238)
at
org.openejb.GenericEJBContainer$$FastClassByCGLIB$$60a0c356.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.openejb.EJBContainer$$EnhancerByCGLIB$$19a9c94a.invoke()
at
org.openejb.server.axis.EJBContainerProvider.processMessage(EJBContainerProvider.java:103)
at
org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at
org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:454)
at
org.apache.geronimo.axis.server.AxisWebServiceContainer.invoke(AxisWebServiceContainer.java:119)
at
org.apache.geronimo.jetty.JettyEJBWebServiceContext.handle(JettyEJBWebServiceContext.java:153)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> Subject can remain attached to thread on return from web app request, causing
> problems later on subsequent use of that thread
> -
>
> Key: GERONIMO-2100
> URL: http://issues.apache.org/jira/browse/GERONIMO-2100
> Project: Geronimo
> Type: Bug
> Security: public(Regular issues)
> Components: web
> Versions: 1.2, 1.1
> Reporter: David Jencks
> Assignee: David Jencks
> Priority: Blocker
> Fix For: 1.2, 1.1
>
> there's no code to reset ContextManager.currentCaller in the jetty
> integration. It gets set o.m.j.servlet.WebApplicationHandler.dispatch
> checking security credentials >> InternalJAASJettyRealm, and also by
> JettyEJBWebServiceContext somewhat more directly.
> The problem appears to occur when a subject is left on a thread and the
> thread is used for an unauthenticated ejb web services call. The
> responsibility for setting the subject on unauthenticated ejb web services
> calls is too distributed, but what actually sets it is
> GenericEJBContainer.DefaultSubjectInterceptor, which only installs the
> defaultSubject if there is no subject already set.
> A minimal fix is to set the currentCaller to null if no authentication is
> needed in JettyEJBWebServiceContext:
> if (authenticator != null) {
> String pathInContext =
> org.mortbay.util.URI.canonicalPath(req.getPath());
> if (authenticator.authenticate(realm, pathInContext, req,
> res) == null) {
> throw new HttpException(403);
> }
> } else {
> //EJB will figure out correct defaultSubject shortly
>
[jira] Created: (GERONIMO-2100) Subject can remain attached to thread on return from web app request, causing problems later on subsequent use of that thread
Subject can remain attached to thread on return from web app request, causing
problems later on subsequent use of that thread
-
Key: GERONIMO-2100
URL: http://issues.apache.org/jira/browse/GERONIMO-2100
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Components: web
Versions: 1.2, 1.1
Reporter: David Jencks
Assigned to: David Jencks
Priority: Blocker
Fix For: 1.2, 1.1
there's no code to reset ContextManager.currentCaller in the jetty integration.
It gets set o.m.j.servlet.WebApplicationHandler.dispatch checking security
credentials >> InternalJAASJettyRealm, and also by
JettyEJBWebServiceContext somewhat more directly.
The problem appears to occur when a subject is left on a thread and the thread
is used for an unauthenticated ejb web services call. The responsibility for
setting the subject on unauthenticated ejb web services calls is too
distributed, but what actually sets it is
GenericEJBContainer.DefaultSubjectInterceptor, which only installs the
defaultSubject if there is no subject already set.
A minimal fix is to set the currentCaller to null if no authentication is
needed in JettyEJBWebServiceContext:
if (authenticator != null) {
String pathInContext =
org.mortbay.util.URI.canonicalPath(req.getPath());
if (authenticator.authenticate(realm, pathInContext, req,
res) == null) {
throw new HttpException(403);
}
} else {
//EJB will figure out correct defaultSubject shortly
//TODO Need to check that the handler chain will see the
correct defaultSubject
ContextManager.setCurrentCaller(null);
}
However, it would be much better to make sure that in addition the subject
can't escape back into the calling environment. This can be done easily in
JettyEJBWebServiceContext but requires a simple subclass of
o.m.j.servletWebApplicationHandler for normal servlet requests.
--
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: Frustrations of a Release Manager
On 6/9/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Sounds good. Can you put together a time table representation of this idea? It would help me understand the nuances. Hypothentically speaking, here's a 3.5-month schedule for 1.2: June 12: 1.1 released - select release manager for 1.2 - set goals for 1.2 July 1: 1.2-M1 released July 21: 1.2-M2 released August 14: 1.2-beta1 released Sep 1: 1.2-beta2 released, no new features Sep 14: 1.2-rc1 released, no non-critical bugs - 1.3-SNAPSHOT branch created Sep 21: 1.2-rc2 released Sep 27: vote on 1.2-rc2 as 1.2 Oct 1: release 1.2 Though perhaps we could move the feature/bug freezes down one release. And, of course, if a lot of problems were discovered in, say, 1.2-rc1 then perhaps we'd introduce an extra 1-2 week rc into the plan. What do you think? Thanks, Aaron
Re: Frustrations of a Release Manager
Dims,
Please don't imply that the PMC chair has sent an at-all useful
message. (Why is the PMC different today than 4 weeks ago? I don't
know -- you have made the first announcement of this just today.
What's the message?) You in your e-mail right here have said what you
though went wrong and how you think it could be corrected in the
future. One of my biggest complaints with the board and the PMC chair
is that they have done neither. In conversation with the PMC chair I
practically begged him to tell me I had done something wrong WRT the
JavaOne meeting and what should be done differently next time. He
declined. I asked him to provide concrete examples of behavior of any
kind that he thought needed to be changed. He declined. I think the
message you provided below "If I had known about the meeting I would
have done this... What Apache projects usually do is this... All it
would have taken was this..." was extremely useful. Please, please
encourage the PMC chair to take this approach in the future.
Thanks,
Aaron
On 6/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
Bruce,
If you are again asking for my input here it isIt's plain and
simple. If there is a forum for discussion, it should be open as much
as possible. If it's not possible because of either monetary or space
constraints, then at least there should be some notification whereby
one can give their input on topics at hand via email and/or IRC.
If i had known about significant discussions, i'd have brought up the
topic of how/what my thoughts are on a JAX-WS implementation and the
lack of a credible JAXB2 implementation. So the "Notes from JavaOne"
[1] would have brought out the problems we will be facing implementing
both JAX-WS and JAX-RPC (and using a single SAAJ impl) which could
have been discussed at this forum. I really have to thank David who
followed up by initiating discussion on axis-dev [2] after JavaOne.
Clearly there was a private list of people who were invited and an
agenda was drawn up which was not shared with the whole dev team
either privately or publicly. Typically in all Apache projects, we
call it a F2F, pre announce it, discuss via email/wiki some of the
items before hand and thrash out the rest in person.
All it would have taken is *ONE* lousy email asking for input on items
to be discussed either publicly or privately to all committers. Hiding
behind facade's like "oh, it was a vendor meeting" or "meeting
friends" or "We just left out just one person" or "Oh, There was a
BOF" or a thousand other excuses don't count. All you need to think
about is whether you are being fair to everyone who is engaged in the
project or not. By "bring the community together", hope you don't mean
that we just go back to our merry ways and not learn a lesson or two
from the strong actions by the pmc chair.
Guys, there is something wrong we are doing. Let's fix it
[1] http://marc.theaimsgroup.com/?l=geronimo-dev&m=114807250831613&w=2
[2] http://marc.theaimsgroup.com/?t=11484081113&r=1&w=2
thanks,
dims
On 6/9/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> On 6/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> > Sigh! :( Looks like all efforts are down the drain.
> >
> > On 6/9/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> > > I don't see what's wrong with a group of folks interested in Gernoimo
> > > getting together to talk about Geronimo. So long as it's positioned
> > > as discussion not decision-making, of course -- which, as I recall, it
> > > was.
>
> Dims, statements like that don't work to bring the community together,
> they only cause more animosity. Let's try to move beyond the jabs and
> let the people with unresolved issues air their concerns so that they
> can work together.
>
> Yet again I'm now thoroughly confused on this whole topic. Does this
> mean that nobody can even talk about Geronimo unless it's on-list in
> some way? Does this mean if someone at a client site or a local JUG or
> anywhere asks me questions about Geronimo that I must either tell them
> to ask on the list because I'm not allowed to talk about it or post my
> conversation to the list after the fact?
>
> I really am seriously confused because of so many mixed messages from
> so many people about this topic. Please help me understand.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E );'
>
> Apache Geronimo - http://geronimo.apache.org/
> Apache ActiveMQ - http://incubator.apache.org/activemq/
> Apache ServiceMix - http://incubator.apache.org/servicemix/
> Castor - http://castor.org/
>
--
Davanum Srinivas : http://wso2.com/blogs/
maven-itest-plugin
Hello all, I am trying to build 1.1 from source and I am running into an unfulfilled dependency: maven-itest-plugin-1.0.jar When I try to find it to manually download it (as some pages I found on google suggested) I find that it is apparently no longer a valid maven plugin. How do I get around this? Thanks in advance, Jay
Re: Database Pool Creation error
Aaron Mulder wrote: It looks like maybe you named the pool "PaLM/plc", is that right? If so, you shouldn't use slashes in the name of the pool. That should account for the invalid ID problems. If you still have the "Configuration already exists" problem, that's different. If the repository got confused, you may need to "rm -rf repository/console.dbpool/PaLM*" to make sure the new pool installs correctly. Thanks, Aaron On 6/9/06, Jay D. McHugh <[EMAIL PROTECTED]> wrote: Thank you for your quick response Aaron. I downloaded the unstable build and installed it. The previous error no longer comes up, and it looks like the pool will be deployed. But a different error gets logged and the adminstration page does not list the new pool. Also, if I try to deploy the pool - then I get an error that the pool already exists. And finally, if I try to redeploy the pool then I get an invalid ID error. Here is the error trying to deploy from the administration page with the wizard: - 16:39:41,931 ERROR [Deployer] Deployment failed due to java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:534) Deployer operation failed: java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar org.apache.geronimo.common.DeploymentException: java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:364) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:534) Caused by: java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325) ... 10 more Here are the errors trying to deploy and redeploy from the command line: [EMAIL PROTECTED]:/opt/geronimo$ java -jar bin/deployer.jar deploy /home/jmchugh/development/plc_data/plc_db.deploy.g1.1.xml repository/tranql/tranql-connector/1.2/tranql-connector-1.2.rar Username: system Password: Error: Unable to distribute tranql-connector-1.2.rar: org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException: Configuration already exists: console.dbpool/PaLM/plc/1.0/rar Configuration already exists: console.dbpool/PaLM/plc/1.0/rar [EMAIL PROTECTED]:/opt/geronimo$ java -jar bin/deployer.jar redeploy /home/jmchugh/development/plc_data/plc_db.deploy.g1.1.xml repository/tranql/tranql-connector/1.2/tranql-connector-1.2.rar Username: system Password: No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the plan. Attempting to use ModuleID 'console.dbpool/PaLM/plc/1.0/rar' Exception in thread "main" java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.
Re: Database Pool Creation error
It looks like maybe you named the pool "PaLM/plc", is that right? If so, you shouldn't use slashes in the name of the pool. That should account for the invalid ID problems. If you still have the "Configuration already exists" problem, that's different. If the repository got confused, you may need to "rm -rf repository/console.dbpool/PaLM*" to make sure the new pool installs correctly. Thanks, Aaron On 6/9/06, Jay D. McHugh <[EMAIL PROTECTED]> wrote: Thank you for your quick response Aaron. I downloaded the unstable build and installed it. The previous error no longer comes up, and it looks like the pool will be deployed. But a different error gets logged and the adminstration page does not list the new pool. Also, if I try to deploy the pool - then I get an error that the pool already exists. And finally, if I try to redeploy the pool then I get an invalid ID error. Here is the error trying to deploy from the administration page with the wizard: - 16:39:41,931 ERROR [Deployer] Deployment failed due to java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:534) Deployer operation failed: java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar org.apache.geronimo.common.DeploymentException: java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:364) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:534) Caused by: java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325) ... 10 more Here are the errors trying to deploy and redeploy from the command line: [EMAIL PROTECTED]:/opt/geronimo$ java -jar bin/deployer.jar deploy /home/jmchugh/development/plc_data/plc_db.deploy.g1.1.xml repository/tranql/tranql-connector/1.2/tranql-connector-1.2.rar Username: system Password: Error: Unable to distribute tranql-connector-1.2.rar: org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException: Configuration already exists: console.dbpool/PaLM/plc/1.0/rar Configuration already exists: console.dbpool/PaLM/plc/1.0/rar [EMAIL PROTECTED]:/opt/geronimo$ java -jar bin/deployer.jar redeploy /home/jmchugh/development/plc_data/plc_db.deploy.g1.1.xml repository/tranql/tranql-connector/1.2/tranql-connector-1.2.rar Username: system Password: No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the plan. Attempting to use ModuleID 'console.dbpool/PaLM/plc/1.0/rar' Exception in thread "main" java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apa
Re: Plugin versioning problems
How about the following slight modification, so it would also work for
-SNAPSHOT or private -REVISION builds?
if (version.equals(gerVersion) ||
(gerVersion.endsWith("*") &&
version.startsWith(gerVersion.substring(0, gerVersion.length()-1))) {
The other choice, would be to treat "." and "-" differently, as in
if ( version.equals(gerVersion) ||
((gerVersion.endsWith(".*") &&
version.startsWith(gerVersion.substring(0, gerVersion.length()-2)) ||
((gerVersion.endsWith("-*") &&
version.startsWith(gerVersion.substring(0, gerVersion.length()-2)) ) {
which has the requirement that plugins being developed and tested
against -SNAPSHOT builds be rereleased for the final .rcN or 1.N build
-Donald
Dain Sundstrom wrote:
On Jun 9, 2006, at 2:13 PM, Aaron Mulder wrote:
My main objection to that is then there's no way to say "1.1 only".
We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
different. Or, I suppose, change your patch to gerVersion.length()-1
and encourage "1.1*" not "1.1.*"
I guess my code was bad. My intention was you could call out specific
versions. Here is a table of what I wanted to happen:
Input Version Range
- -
1.1 1.1
1.1.* [1.1-1.2)
1.1.1 1.1.1
1.1.1.* [1.1.1-1.1.2)
and here is the code I posted for those that don't wan to read back in
the thread:
if (version.equals(gerVersion) ||
(gerVersion.endsWith(".*" &&
version.startsWith(gerVersion.substring(0, gerVersion.length ()
- 2))) {
With that if statement, the "glob" part of the match only executes if
the version ended with ".*" otherwise it must be an exact match.
-dain
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Plugin versioning problems
I think this is a good idea.
david jencks
On Jun 9, 2006, at 2:36 PM, Dain Sundstrom wrote:
On Jun 9, 2006, at 2:13 PM, Aaron Mulder wrote:
My main objection to that is then there's no way to say "1.1 only".
We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
different. Or, I suppose, change your patch to gerVersion.length()-1
and encourage "1.1*" not "1.1.*"
I guess my code was bad. My intention was you could call out
specific versions. Here is a table of what I wanted to happen:
Input Version Range
- -
1.1 1.1
1.1.* [1.1-1.2)
1.1.1 1.1.1
1.1.1.* [1.1.1-1.1.2)
and here is the code I posted for those that don't wan to read back
in the thread:
if (version.equals(gerVersion) ||
(gerVersion.endsWith(".*" &&
version.startsWith(gerVersion.substring(0, gerVersion.length
() - 2))) {
With that if statement, the "glob" part of the match only executes
if the version ended with ".*" otherwise it must be an exact match.
-dain
Re: Frustrations of a Release Manager
Bruce,
If you are again asking for my input here it isIt's plain and
simple. If there is a forum for discussion, it should be open as much
as possible. If it's not possible because of either monetary or space
constraints, then at least there should be some notification whereby
one can give their input on topics at hand via email and/or IRC.
If i had known about significant discussions, i'd have brought up the
topic of how/what my thoughts are on a JAX-WS implementation and the
lack of a credible JAXB2 implementation. So the "Notes from JavaOne"
[1] would have brought out the problems we will be facing implementing
both JAX-WS and JAX-RPC (and using a single SAAJ impl) which could
have been discussed at this forum. I really have to thank David who
followed up by initiating discussion on axis-dev [2] after JavaOne.
Clearly there was a private list of people who were invited and an
agenda was drawn up which was not shared with the whole dev team
either privately or publicly. Typically in all Apache projects, we
call it a F2F, pre announce it, discuss via email/wiki some of the
items before hand and thrash out the rest in person.
All it would have taken is *ONE* lousy email asking for input on items
to be discussed either publicly or privately to all committers. Hiding
behind facade's like "oh, it was a vendor meeting" or "meeting
friends" or "We just left out just one person" or "Oh, There was a
BOF" or a thousand other excuses don't count. All you need to think
about is whether you are being fair to everyone who is engaged in the
project or not. By "bring the community together", hope you don't mean
that we just go back to our merry ways and not learn a lesson or two
from the strong actions by the pmc chair.
Guys, there is something wrong we are doing. Let's fix it
[1] http://marc.theaimsgroup.com/?l=geronimo-dev&m=114807250831613&w=2
[2] http://marc.theaimsgroup.com/?t=11484081113&r=1&w=2
thanks,
dims
On 6/9/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:
On 6/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Sigh! :( Looks like all efforts are down the drain.
>
> On 6/9/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> > I don't see what's wrong with a group of folks interested in Gernoimo
> > getting together to talk about Geronimo. So long as it's positioned
> > as discussion not decision-making, of course -- which, as I recall, it
> > was.
Dims, statements like that don't work to bring the community together,
they only cause more animosity. Let's try to move beyond the jabs and
let the people with unresolved issues air their concerns so that they
can work together.
Yet again I'm now thoroughly confused on this whole topic. Does this
mean that nobody can even talk about Geronimo unless it's on-list in
some way? Does this mean if someone at a client site or a local JUG or
anywhere asks me questions about Geronimo that I must either tell them
to ask on the list because I'm not allowed to talk about it or post my
conversation to the list after the fact?
I really am seriously confused because of so many mixed messages from
so many people about this topic. Please help me understand.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
--
Davanum Srinivas : http://wso2.com/blogs/
Re: Database Pool Creation error
Thank you for your quick response Aaron. I downloaded the unstable build and installed it. The previous error no longer comes up, and it looks like the pool will be deployed. But a different error gets logged and the adminstration page does not list the new pool. Also, if I try to deploy the pool - then I get an error that the pool already exists. And finally, if I try to redeploy the pool then I get an invalid ID error. Here is the error trying to deploy from the administration page with the wizard: - 16:39:41,931 ERROR [Deployer] Deployment failed due to java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:534) Deployer operation failed: java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar org.apache.geronimo.common.DeploymentException: java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:364) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:534) Caused by: java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325) ... 10 more Here are the errors trying to deploy and redeploy from the command line: [EMAIL PROTECTED]:/opt/geronimo$ java -jar bin/deployer.jar deploy /home/jmchugh/development/plc_data/plc_db.deploy.g1.1.xml repository/tranql/tranql-connector/1.2/tranql-connector-1.2.rar Username: system Password: Error: Unable to distribute tranql-connector-1.2.rar: org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException: Configuration already exists: console.dbpool/PaLM/plc/1.0/rar Configuration already exists: console.dbpool/PaLM/plc/1.0/rar [EMAIL PROTECTED]:/opt/geronimo$ java -jar bin/deployer.jar redeploy /home/jmchugh/development/plc_data/plc_db.deploy.g1.1.xml repository/tranql/tranql-connector/1.2/tranql-connector-1.2.rar Username: system Password: No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the plan. Attempting to use ModuleID 'console.dbpool/PaLM/plc/1.0/rar' Exception in thread "main" java.lang.IllegalArgumentException: Invalid id: console.dbpool/PaLM/plc/1.0/rar at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:190) at org.apache.geronimo.deployment.cli.CommandRedeploy.execute(CommandRedeploy.java:137) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:312)
Re: 1.1 Release plan
I originally said I would release a new candidate after 1400 eastern time today. Truth is I'm pretty wiped out and would like to cut a release tomorrow (Saturday). We'll add some additional time for JSisson as he is clearly doing something other than working :) I propose that the next candidate is released on Sunday and allows 72 hours for feedback. Is everyone ok with that ? Aaron Mulder wrote: So as I understand this, the plan is: - new release candidate today, no more non-critical patches - begin voting for that release candidate today - if critical bugs are found within 72 hours, someone will -1 the vote, we will fix and cut a new release candidate, and start a new 72-hour vote I'm OK with that for this release (I don't think it's ideal, but I agree that it will be nice to get this release out the door, so I'm on board). I hope someone will look at the weird web services error during deployment, because I don't know what to make of that (if it's reproduceable and how significant it is). If I'm right about the release plan, I think we should create a SVN home for 1.1.1-SNAPSHOT now so there's a place to put non-critical patches. It will be annoying to put critical patches into 3 places, but we're hoping there aren't any of those. Thanks, Aaron On 6/8/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Final Items for 1.1 I would like to release Geronimo 1.1 on June 12th. Yes, that is three days away. If we can't make that date then it will be 72 hours away from each candidate build. Problem that are found need to be addressed if they are deemed critical. Otherwise they will be tracked and solved in a follow on release. That said. I sent a note earlier today announcing the freeze to branches/1.1. Changes to this branch should be limited to bug fixes only. The little changes are the ones that generally burn you. At 1400 ET the Inn is closed and I will spin up a release that will be our release candidate. The issues that have been raised from the previous build were Guillaume's observation of the problem when running Geronimo under CygWin as well as the license and Notice issues. Since Geronimo is a multifaceted project there are several things that need to be voted on. They are Geronimo itself, the specification jars and DayTrader. Geronimo itself is the significant component that will carry the other items so I believe a vote for Geronimo in this context is a vote for all three items. *There is a concern about the specification jars* David Jencks raised this issue in another note on the list. The jars have not been released but they have had a tag cut and the resulting compilation has been placed on http://people.apache.org/repository. One of the issues I found with the spec is that there are different spec releases in the 1_1 tag. I would prefer that all jars have the same version suffix. Right now it includes 1.0, 1.0.1, 1.1 and others. I think this is confusing. We release Geronimo with all the same module versions even if nothing has changed. I would like to move that we recut a 1_2 tag with all spec jars having a 1.2 suffix. *DayTrader* Day Trader is currently a 1.1-SNAPSHOT as well. We will release the DayTrader Ear (separate from Geronimo) as a 1.1 version as well. This way the build will be in sync. *Issues* 1. It was noted earlier today that there is a problem with Geronimo under CygWin. Guillaume noted that an issue exists where a file is not renamed (config.xml). Given that CygWin is a hybrid environment I think we should investigate this problem but not hold up the release. 2. Guillaume also pointed out the lack of a License and Notices file. I will include the two files from the SVN geronimo/branches/1.1 in the build tomorrow. 3. Numerous bug fixes are being addressed. Excellent. Apart from Spec issue above I think we have most everything addressed. Does this list of outstanding items and release plan make sense? Matt
Re: Frustrations of a Release Manager
Would it make any difference to anyone if IBM proposed that we put http://www.ibm.com/wasce/plugins as the default option. I think there would be many eye brows raised at that one. Let's be consistent in our interpretations. Jeff Genender wrote: Bruce Snyder wrote: On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: No Bruce, thats not it at all. Its simply discussing what he was going to do. This all comes back to the lack of communication issue. So you would have preferred that he send an email to the list explaining the work he was doing on the code? I think it was clear what was wanted and needed...communication. Lets go back to your statement that "we can agree to disagree"...we are beating a dead horse here... Bruce
Re: Frustrations of a Release Manager
Aaron Mulder wrote: On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: I brought this up as an issue originally as it bothered me. This has nothing to do with Erin, so let's not obfuscate the issue. The point here is there was absolutely no discussion about this, as this was clearly a fairly large decision that we, as a community, should have been involved in. Unless I missed something, I do not recall anyone talking about registering a site with Geronimo plugins before it occurred. Um... OK. I didn't think setting up a site to hold the plugins was that big a deal. If it bothered you, I'm sorry. Let's talk about it. What do you recommend? The constraints I see are that is should be able to host Apache, GPL, LGPL, and commercial code. Do you agree? Disagree? What do you recommend for a hosting site? This also bothered me as a peer, since a lot of the work I did on the Directory server integration was taken out of Geronimo, then wrapped up into a plugin and placed on this external site, without input from others, as well as those who did the hard work on integration. I find this extra-confusing. I took a piece of Geronimo which was hard-coded into the product (e.g. via our assembly system) and made it a modular part of the product (e.g. a plugin that you can install or not as you please). And you feel that as the primary author of the code, you should have been consulted? That I'm somehow using your own hard work to my advantage instead of to improve the product as a whole? I'm sorry for offending you. But I don't understand your objection. Although nothing in the Apache License prohibits you from doing this, it would have been prudent and shown respect to your peers who put together the example applications and the Directory integration, to have had some discussions about doing this and how they felt about it. Its more of a ethical and respect issue, IMHO. I think we agreed that it was a mistake to include so much (samples, LDAP, etc.) in the base Geronimo distribution. The Java 5 stack trace in Geronimo 1.0 was directly attributable to this, plus we've been working hard to slim down our distributions. I am pretty sure we agreed on that in discussions on the list, though it's been a while. But I still don't understand how changing or repackaging code is showing disrespect. We're all in this together, and it's not your code or my code, it's our code. I promise, if you make the console more modular so it runs in Little G just as well as Big G, I won't be offended, I'll buy you a beer. As for your question, my counter proposal is having significant discussion with others before taking action. Well, OK, as I said, let's have the discussion. Sorry it wasn't sooner, but better late than never, eh? Relative to the private emails, I received an email from you privately after I brought up the geronimoplugins that was very aggressive, along with verbiage that bordered on threatening language. Your private email to me started out with "Watch your tone". This is the intimidation stuff that I have referred to in the past, and it concerns me quite a bit. Yeah, I admit, I was a little fired up after you posted my address to the list. :) Sorry. I attended for a total of about an hour. I am speaking from hearsay here...but was Geir's presence, or lack-there-of discussed? I was told by someone that it was actually discussed at the meeting. This in-and-of-itself is the issue. Knowing Geir was in town, and especially knowing the fact that he was responsible for obtaining a speaker pass for you at JavaOne, I am having a difficult time understanding how or why he would be excluded from the event. JavaOne is a time many of us (Geronimo) come together, and I believe we all should have the opportunity to be together, regardless of our feelings (positive or negative) about each other. For those who could not attend, a dial-in probably could have been arranged. This should have been more open, and I am myself guilty for attending this when I noticed not everyone was there. We have all earned the privilege to be on Geronimo due to our dedication, contributions, and commitments we have made to Apache and Geronimo. We all should have the opportunity to engage as well. I am sure there were a number of people at JavaOne who were not invited, Geir and others. True, it would have been smart to arrange a dial-in. Ideally, many of the non-committers would have been involved as well, as their dedication and contributions should not be overlooked either. If the outcome of this is that no one should have a meeting unless the whole community is invited, I can work with that (but I don't think that's necessarily reasonable). I talked to another committer at a different conference recently, and we brainstormed some ideas for improving the product. Was that wrong? Where's the line? Is 5 people OK but 15 isn't? I think two or 50 is fine. The issue was that some people wanted to
Re: Plugin versioning problems
Heh heh... you're right.
Thanks,
Aaron
On 6/9/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On Jun 9, 2006, at 2:13 PM, Aaron Mulder wrote:
> My main objection to that is then there's no way to say "1.1 only".
> We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
> different. Or, I suppose, change your patch to gerVersion.length()-1
> and encourage "1.1*" not "1.1.*"
I guess my code was bad. My intention was you could call out
specific versions. Here is a table of what I wanted to happen:
Input Version Range
- -
1.1 1.1
1.1.* [1.1-1.2)
1.1.1 1.1.1
1.1.1.* [1.1.1-1.1.2)
and here is the code I posted for those that don't wan to read back
in the thread:
if (version.equals(gerVersion) ||
(gerVersion.endsWith(".*" &&
version.startsWith(gerVersion.substring(0, gerVersion.length
() - 2))) {
With that if statement, the "glob" part of the match only executes if
the version ended with ".*" otherwise it must be an exact match.
-dain
Re: Frustrations of a Release Manager
Bruce Snyder wrote: On 6/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Sigh! :( Looks like all efforts are down the drain. On 6/9/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > I don't see what's wrong with a group of folks interested in Gernoimo > getting together to talk about Geronimo. So long as it's positioned > as discussion not decision-making, of course -- which, as I recall, it > was. Dims, statements like that don't work to bring the community together, they only cause more animosity. Let's try to move beyond the jabs and let the people with unresolved issues air their concerns so that they can work together. Yet again I'm now thoroughly confused on this whole topic. Does this mean that nobody can even talk about Geronimo unless it's on-list in some way? Does this mean if someone at a client site or a local JUG or anywhere asks me questions about Geronimo that I must either tell them to ask on the list because I'm not allowed to talk about it or post my conversation to the list after the fact? I don't think that an all list requirement is appropriate. We have to allow for people having conversations that are not privy to everyone's consumption. However, where those discussion turn into a collusion about how the project should unfold then I think it has turned to an innapropriate level. I really am seriously confused because of so many mixed messages from so many people about this topic. Please help me understand. Bruce
Re: Plugin versioning problems
On Jun 9, 2006, at 2:13 PM, Aaron Mulder wrote:
My main objection to that is then there's no way to say "1.1 only".
We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
different. Or, I suppose, change your patch to gerVersion.length()-1
and encourage "1.1*" not "1.1.*"
I guess my code was bad. My intention was you could call out
specific versions. Here is a table of what I wanted to happen:
Input Version Range
- -
1.1 1.1
1.1.* [1.1-1.2)
1.1.1 1.1.1
1.1.1.* [1.1.1-1.1.2)
and here is the code I posted for those that don't wan to read back
in the thread:
if (version.equals(gerVersion) ||
(gerVersion.endsWith(".*" &&
version.startsWith(gerVersion.substring(0, gerVersion.length
() - 2))) {
With that if statement, the "glob" part of the match only executes if
the version ended with ".*" otherwise it must be an exact match.
-dain
Re: Frustrations of a Release Manager
On Jun 8, 2006, at 5:44 PM, Aaron Mulder wrote: I propose for 1.2 we drive it more by time than by features. That is, we lay out a schedule including builds every 2-3 weeks, initially milestone builds, becoming beta and RC builds. We try to get people to test and provide feedback on the builds as we go, and we expect that we'll have some issues early to mid-way through the process but have clear dates for feature freeze, no bugs fixes except blockers, branch for the next release, etc. We may have to adjust the schedule depending on what develops, but at least we'll know what we're targeting at all times. Then we'll have to huddle after the 1.2 release and decide whether this was an improvement over the 1.1 process or not, and decide how to go for 1.3/2.0. Sounds good. Can you put together a time table representation of this idea? It would help me understand the nuances. Thanks, -dain
Re: Some features for 1.1.1 -- module/deployment extensions
On Jun 9, 2006, at 1:51 PM, Aaron Mulder wrote: FYI, I plan to address http://issues.apache.org/jira/browse/GERONIMO-1873 as soon as possible in 1.1.1. I'd like plugins to be able to define new deployment unit formats (e.g. JBI service assemblies, a Spring deployment unit, a Quartz job as a deployment unit, or a Jasper report as a deployment unit). Depending on what this requires in terms of changes in Geronimo it sounds like a new feature. I know we haven't discussed it at all, but I assume that dot releases don't get new features. (I'm not saying it is a "feature" just sounds like one to me). Any of those will probably need a geronimo-XYZ.xml deployment plan, to supply a module ID and dependencies if nothing else. And currently, the deploy tool doesn't know how to crack open an arbitrary deployment unit and figure out its module ID, which is necessary to support redeployment when the plan is embedded in the archive (it has to know what existing module(s) to replace). That sucks. Is there something else we could do to avoid needing the module id? I'm guessing not. There are two possible solutions: one is to stop using JSR-88 for deployment and just pass the archive to the server and let it do its thing; the other is to let each deployer indicate the name of its deployment plan (when the plan is packed in the module). I'd lean toward the second approach for 1.1.1, as it's a fairly trivial change. I like the first one. JSR-88 seems to have to have a myopic view of the world and I really starting to feel constrained by the spec. Do you think it will be able to support everything we want to do in the future? A related question is whether we should let you pack non-J2EE deployment units in an EAR. That is, if we define a JasperReports report deployment unit, should your EAR be able to contain a WAR, an EJB JAR, and 2 reports? I would think so, though we may choose to implement a wrapper that would hold the EAR and the 2 reports instead. I'm not sure how extensive a change this might require -- we seem to have some special handling for classpaths for modules within an EAR, and I don't know where that happens and what's likely to break. I think we should allow arbitrary nesting, and I think it will require a major change to deployment. If we do nothing, the alternative is that you'd only be able to redeploy new types of modules if you pass either the module ID or the plan on the command line along with the archive (no packing plan in archive), and if you had a J2EE app and a handful of other modules that all work together, you would still have to deploy/redeploy them all individually. I would lean towards a multiphase rollout of this feature. A small work around for 1.1.1, and depending on timing maybe split the rest across 1.2 and 1.3. That is just my $0.02. -dain
Re: Geronimo doesn't startup if restart it using another JDK
BTW migrating to howl 1.0.1 is waiting on a maven upload request... http://jira.codehaus.org/browse/MAVENUPLOAD-930 As of a couple days ago these were stalled indefinitely. thanks david jencks On Jun 9, 2006, at 1:48 PM, Dain Sundstrom wrote: As jason pointed out using a hash code isn't portable. This is a known problem in Howl and IIRC they added an optional flag in howl to use a specified hash algorithm. Anyway, please create a JIRA (http://issues.apache.org/jira/browse/GERONIMO) for this issue. -dain On Jun 9, 2006, at 3:32 AM, Udovichenko, Nellya wrote: Hello, I have launched Geronimo on Sun JDK. Then I’ve tried to run it with Harmony class library and IBM VM j9. I’ve got the error log below. Also I’ve got the same result when launched Geronimo on Harmony and then - on Sun JDK. There is a bug in HOWL repaired in howl-1.0.1 by the new parameter (adler32Checksum) adding. At Geronimo startup it checks the log files' validity if they exist. One of verified parameters is the file content control sum. One value of this sum is read from file header and another is calculated by function java.nio.ByteBuffer.hashCode (). So if the algorithms of hash code functions of the JDKs are different Geronimo doesn’t startup. If the parameter adler32Checksum value is false the control sum is calculated by function java.nio.ByteBuffer.hashCode() otherwise it is calculated using ADLER-32 algorithm. Therefore, I think, it would be correct to add this parameter to configs/j2ee-server/src/plan/plan.xml and to gbean org.apache.geronimo.transaction.log.HOWLLog with value 'true'. Any thoughts? Thanks, Nellya Udovichenko, Intel Middleware Products Division Error log: $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.4.2_01)... Starting Geronimo Application Server v1.1-20060607 [**> ] 11% 6s Starting geronimo/j2ee-server/ 1...14:23:30,3 19 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED s tate: abstractName="geronimo/j2ee-server/1.1-20060607/car? ServiceModule=geronimo /j2ee-server/1.1-20060607/ car,j2eeType=TransactionLog,name=HOWLTransactionLog" org.objectweb.howl.log.InvalidLogBufferException: CHECKSUM Class: org.objectweb.howl.log.BlockLogBuffer workerID: LogFile: C:\Nellya\geronimo-1.1\var\txlog\howl_1.log HEADER HEADER_ID: 0x484f574c bsn: 0x1 size: 0x8000 should be: 0x8000 data used: 0x4f checkSum: 0x2227d tod: 0x10bb850e3b1 crlf: 0xd0a FOOTER FOOTER_ID: 0x4c574f48 bsn: 0x1 tod: 0x10bb850e3b1 crlf: 0xd0a at org.objectweb.howl.log.BlockLogBuffer.read (BlockLogBuffer.java:460) at org.objectweb.howl.log.LogFileManager.init (LogFileManager.java:821) at org.objectweb.howl.log.Logger.open(Logger.java:314) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:893) at org.apache.geronimo.transaction.log.HOWLLog.doStart (HOWLLog.java:217) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start (GBeanInstance.j ava:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency $1.running(GBeanDepe ndency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor $RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) at org.apache.geronimo.ke
Re: Frustrations of a Release Manager
Okay, after reading the e-mails thus far ( I haven't read through all of them yet ) here are my responses inline. Aaron Mulder wrote: On 6/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Aaron, Since you asked. First, Can you respond below if you will allow anyone that you have sent a private e-mail to to cut and paste the contents of those messages into other posts on this thread. I think that will help. Sure. Thanks. Second, the geronimoplugins.com which was injected into Geronimo is probably a good place to start. Here is a snip from whois of that domain. I removed the address specific information. Registrant: Address is provided *Removed* Domain Name: GERONIMOPLUGINS.COM Created on: 11-Apr-06 Expires on: 11-Apr-07 Last Updated on: 11-Apr-06 Administrative Contact: Mulder, Erin [EMAIL PROTECTED] Technical Contact: Mulder, Erin [EMAIL PROTECTED] Yes, of course, that's a domain we got, because the project needs one, and it can't be at Apache (due to the LGPL issue). I've offered a number of times to give people accounts to help manage the site, and so far, no one's taken me up on it. My goals are to provide a Maven repository (=HTTP site) that can hold *all* plugins, ASF, LGPL, GPL, proprietary. Since I didn't see one out there, Erin was gracious enoguh to provide one. And now you're jumping on her for it? That's gratitude! Also, recall that the file defining the available plugin repositories is hosted by the ASF, so the ASF can change the list of available sites away from geronimoplugins.com at any time. What is your counter-proposal? Create a zone at Apache that will service this concept. This would require talking to the infra team to do this. Perhaps this was already done and we didn't see the traffic on the dev list. If ther ewaw I apologize for the assertion. Next we can discuss the hijacking of JIRA for your own purposes. I was working to release 1.1 and you moved over 80 other JIRAs into the release. I don't think that we agreed on how to handle JIRAs but I think it was bad form to assume it was your prioritization mechanism since you were not releasing 1.1. Gosh, I didn't really think I was hijacking Jira. I thought I was using it for its intended purpose, which is to say, tracking the issues with the project, what should be worked on, and who was willing to work on what. Including, of course, a todo list for myself. I honestly had no idea that as release manager, you considered Jira to be your domain, and didn't want people using without what -- your approval? By all means, if you object to something I do like that, please say something! "Aaron, I'm trying to use Jira to track the tasks for 1.1, please don't put anything in there unless it's *definitely* going to happen in the next 2 weeks" or whatever. I don't remember having those discussions until well after the fact. Fair enough that you hadn't considered JIRA as a release management tool. We3 never discussed it and perhaps from my perspective it seemed obvious. Teh point is you used it for your purposes without a prior e-mail to the community about your intentions. When you did move things back in I assumed a different strategy on how to manage the release. Your intent being declared prior to moving the JIRAs would have allowed the community to interact and decided on a common course. We also discussed how to use JIRA more effectively and you post was all about what YOU wanted which may be unfair to post as you were presenting your opinion but the term I was introduced several times. I can find the post but I suspect its in most people's archives. Yes of course. I was explaining how I want to use an issue-tracking system. (Were your posts about how Jeff wants to use an issue tracking system?) I thought the point of the thread was for everyone to say what they're looking for so we can then decide the best way to do it as a group. Perhaps this was an unfair example. You used the terms I an I need so I took that to be more focused on your desires rather than community focused. If I mis-understood then I apologize. Shall we begin to discuss the meeting at Java One that you proposed that specifically excluded members of the community. I'd be happy to bring that discussion to the list if you like. Given that IBM paid for the room that the discussion occurred in we are somewhat culpable but given that you were the master mind behind the exclusionary wall I'm happy to have that discussion in the open as well. Well, actually, it was kind of a joint idea between myself and a few other people who thought there were some things we ought to talk about so long as we were all together. I'm sorry that there's a perception of an exclusionary wall. It was on us to pay for the food, which at hotel rates was $100 per person for the day, so naturally I wasn't able to invite the entire Geronimo community. I
Re: Plugin versioning problems
http://www.javaforge.com/ - It's another opensource based *forge hosting site, which seems to be open to anyone to use. The only reason I found it, was the Luntbuild project we use for building (http://www.javaforge.com/proj/summary.do?proj_id=70) started using it awhile back. I would rather use the more common sourceforge, even if its a little slow at times -Donald Aaron Mulder wrote: Sourceforge is kind of slow, which is my main objection. But perhaps we can use it as a start. What's Javaforge? Thanks, Aaron On 6/9/06, Donald Woods <[EMAIL PROTECTED]> wrote: Inline below. Aaron Mulder wrote: > On 6/8/06, Donald Woods <[EMAIL PROTECTED]> wrote: > >> BTW - How can we add new Plugins to the geronimoplugins website? Are we >> going to setup a Geronimo subproject (like Daytrader) with the site >> framework checked into svn, along with any scripts needed to build the >> plugins? It seems convoluted to have samples and plugin builds in the >> main Geronimo tree, which are not shipped with the server or >> automatically pushed to geronimoplugins. Wouldn't it be easier to >> maintain if we moved all the samples out to /trunk/samples/modules and >> all the equivalent plugin configs to /trunk/samples/plugins? That way, >> the Samples and plugins can be built, published and enhanced separate >> from the server development > > > Currently, to get a plugin added to the web site, you can mail it to > me. If you want to help out there, it would be great to have a script > that read the plugin.xml files and emitted the various PHP files with > all the plugin info! Currently it's a little more manual. :) > > We should definitely have a separate are in the SVN tree for the > samples. There's no reason they should be tied to the Geronimo > release schedule. > > We also need a non-Apache space where we can write the plugin wrappers > for various interesting LGPL projects. If you create a project on Sourceforge or Javaforge, I'll come and help. How about project=geronimoplugins to match the website name? -Donald > > Thanks, >Aaron > >> Aaron Mulder wrote: >> > On 6/7/06, Donald Woods <[EMAIL PROTECTED]> wrote: >> > >> >> Why shouldn't the Plugin support be as robust as module >> dependencies and >> >> allow the user providing the plugin to decide if they can support >> >> geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only >> support >> >> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to >> >> me and doesn't follow previous email threads about not deviating from >> >> Maven2 versioning behavior... >> > >> > >> > But what you've said here is "why shouldn't the plugin support be as >> > robust as A and allow B" where A != B. Module dependencies let you >> > specify an exact version or no version. Plugin dependencies also let >> > you specify an exact version or no version. Neither of these support >> > 1.* or 1.1*. >> > >> >> Just as with the Tomcat JSP/Servlet Examples, you could easily >> provide a >> >> Plugin which should work on all 1.x releases >> > >> > >> > My preference it to opt-in supported version, not opt-out unsupported >> > versions. So I'd like the plugin developer to try a plugin on a >> > Geronimo version and if it works, list that version as supported. The >> > alternative will most likely lead to Geronimo being willing to install >> > a plugin but the plugin not working. If we get fancier version >> > dependencies we can consider things like "1.1.*" but I'm not sure I >> > like that. I'm willing to be convinced, but I'd want to hear from >> > more plugin developers/maintainers. >> > >> > Thanks, >> >Aaron >> > >> > >> >> >> > > smime.p7s Description: S/MIME Cryptographic Signature
Re: 1.1 Release plan
On Jun 9, 2006, at 12:40 PM, Aaron Mulder wrote: If I'm right about the release plan, I think we should create a SVN home for 1.1.1-SNAPSHOT now so there's a place to put non-critical patches. It will be annoying to put critical patches into 3 places, but we're hoping there aren't any of those. I just attached mine to JIRAs assigned to 1.1.1. I know it's not idea but is it better than leaving them on my laptop. -dain
Re: 1.1 Release plan
On Jun 9, 2006, at 12:02 AM, John Sisson wrote: Matt Hogstrom wrote: Final Items for 1.1 I would like to release Geronimo 1.1 on June 12th. Yes, that is three days away. If we can't make that date then it will be 72 hours away from each candidate build. Problem that are found need to be addressed if they are deemed critical. Otherwise they will be tracked and solved in a follow on release. Unfortunately I will be off-line for the next three days. Not everybody has every weekend free, so how about another 3 days so everyone has plenty of notice and there will be less chance of complaints. The only thing that I had outstanding was changes to the scripts (GERONIMO-1638) as discussed at http://www.mail-archive.com/ dev@geronimo.apache.org/msg22807.html . Have made changes (not committed) but they need to be tested on windows, cygwin and unix, so with my time constraints it looks like this is going to be for 1.1.1 . Probably need something in the release notes saying that use of the GERONIMO_BASE environment variables probably won't work and the new org.apache.geronimo.server.dir and org.apache.geronimo.server.name system properties are subject to change as they are experimental. If they are experimental, they should start with a "X" character. Matt and John is that something we should change? -dain
Re: Plugin versioning problems
My main objection to that is then there's no way to say "1.1 only".
We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
different. Or, I suppose, change your patch to gerVersion.length()-1
and encourage "1.1*" not "1.1.*"
Thanks,
Aaron
On 6/9/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
If we really need it, I think the syntax 1.1.* would be ok since it
would easily be parseable and translated to [1.1-1.2) in a formal
version syntax. For the patch, I'm thinking of something like
if (version.equals(gerVersion) ||
(gerVersion.endsWith(".*" &&
version.startsWith(gerVersion.substring(0, gerVersion.length
() - 2))) {
match = true;
break;
}
Don't trust that code; I free styled it in this email, but you get
the idea.
I do think this is too risky for 1.1 since this code could easily
have unintended consequences.
-dain
On Jun 9, 2006, at 5:59 AM, Paul McMahan wrote:
> That's a good idea and it would be pretty straightforward. But now
> that Dain has brought our attention to GERONIMO-1637 I'm concerned
> about deviating from the G 1.2 activities where the full syntax of
> maven version ranges will be introduced. I don't know much about
> maven version ranges - there may be some subset that can be
> implemented during G 1.1.x that addresses our specific concerns about
> forcing plugins to continually update their geronimo-plugin.xml.
>
> Best wishes,
> Paul
>
> On 6/8/06, Donald Woods <[EMAIL PROTECTED]> wrote:
>> Paul, what if we tweaked your proposed patch and allowed the
>> plugin to
>> provide an optional attribute of exactVersion=required, which would
>> control the behavior?
>>
>> -Donald
>>
>> Paul McMahan wrote:
>> > I definitely agree that a full fledged solution for version
>> ranges is
>> > out of scope for G 1.1.x. I was thinking that a minor change to
>> the
>> > plugin installer's version checking could at least partially
>> address
>> > Donald's concerns and also avoid the version mismatch problem
>> Dave C.
>> > found in the candidate build. Here's a patch that makes the plugin
>> > installer only check the digits of geronimo's version that the
>> > plugin's xml specifies. So if the plugin specifies
>> > 1.1 then it can be
>> installed into
>> > 1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
>> >
>> > Best wishes,
>> > Paul
>> >
>> > Index:
>> > modules/system/src/java/org/apache/geronimo/system/plugin/
>> PluginInstallerGBean.java
>> >
>> > ===
>> > ---
>> > modules/system/src/java/org/apache/geronimo/system/plugin/
>> PluginInstallerGBean.java
>> > (revision
>> > 412744)
>> > +++
>> > modules/system/src/java/org/apache/geronimo/system/plugin/
>> PluginInstallerGBean.java
>> > (working
>> > copy)
>> > @@ -1409,7 +1409,7 @@
>> > if(gerVersion == null || gerVersion.equals("")) {
>> > throw new IllegalStateException("geronimo-version
>> > should not be empty!");
>> > }
>> > -if(gerVersion.equals(version)) {
>> > +if(version.startsWith(gerVersion)) {
>> > match = true;
>> > break;
>> > }
>> >
>> >
>> > On 6/8/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
>> >
>> >> Perhaps I was unclear; I didn't mean to say this was a bad
>> idea, only
>> >> that our code doesn't currently support it. I expect version
>> ranges
>> >> are on the road map, but if you want to work on them, you're
>> more than
>> >> welcome to. :)
>> >>
>> >> I don't think this is a G 1.1.x discussion, since AFAIK it would
>> >> require kernel changes.
>> >>
>> >> Thanks,
>> >> Aaron
>> >>
>> >> On 6/8/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> >> > On 6/8/06, Donald Woods <[EMAIL PROTECTED]> wrote:
>> >> > > What I meant by 1.1.* was the Maven behavior of private
>> builds like
>> >> > > 1.1-1 being taken as newer than 1.1. Also, being able to
>> use the
>> >> > > behavior of 1.1- is less than 1.1.
>> >> Basically,
>> >> > > I should be able to specify 1.1 in the plugin and have it
>> work on
>> >> > > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but
>> doesn't on
>> >> 1.1.1,
>> >> > > then I'd argue that we broke something in 1.1.1, given it
>> should
>> >> only be
>> >> > > a maintenance release and app/plan breaking changes should
>> only go
>> >> into 1.2.
>> >> >
>> >> > +1 This approach is similar to how eclipse plugin
>> versioning works.
>> >> >
>> >> > From http://www.eclipse.org/equinox/documents/plugin-
>> versioning.html :
>> >> > "How to specify plug-in requirements
>> >> > Plug-ins that require other plug-ins must qualify their
>> requirements
>> >> > with a version range since the absence of a version range
>> means that
>> >> > any version can satisfy the dependency. Given that all the
>> changes
>> >> > between the version x.0.0 and the version x+1.0.0 excluded
>> must be
>> >> > compatible (given the previous guidelines); the recommended
>> range
>> >> > includes the minimal requi
Re: Database Pool Creation error
Thanks for testing the pre-release! This bug was identified and fixed after the Wednesday build. You can get a build incorporating the fix here: http://people.apache.org/dist/geronimo/unstable/1.1-412854 (though that's an "unstable" build and I understand another release candidate will be coming quite soon). Alternately, if you don't want to reinstall all of Geronimo, you can undeploy the console (if you do it from the console itself you'll get a stack trace but it will work), and then get the latest console build from the plugin repository like this: java -jar bin/deployer.jar search-plugins http://www.geronimoplugins.com/repository/geronimo-1.1 Then pick the number for "Geronimo Admin Console", and it should download and install the most current console build and you can try again. Let me know if you need help with this. Thanks, Aaron On 6/9/06, Jay D. McHugh <[EMAIL PROTECTED]> wrote: Hello all, I don't know if anyone has had any issues creating database pools with the snapshot from Wednesday. But, began testing today and I cannot create a new database pool using the wizard (mySQL connection) Log output for 'show plan' and 'deploy plan' below. If anyone has a patch that corrects this please let me know. Thanks, Jay McHugh logs follow --- When I attempt to 'show plan' prior to deploying the plan (created with the wizard) I get the following log output: 15:53:22,969 ERROR [DatabasePoolPortlet] Unable to save connection pool java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:876) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
Re: Plugin versioning problems
If we really need it, I think the syntax 1.1.* would be ok since it
would easily be parseable and translated to [1.1-1.2) in a formal
version syntax. For the patch, I'm thinking of something like
if (version.equals(gerVersion) ||
(gerVersion.endsWith(".*" &&
version.startsWith(gerVersion.substring(0, gerVersion.length
() - 2))) {
match = true;
break;
}
Don't trust that code; I free styled it in this email, but you get
the idea.
I do think this is too risky for 1.1 since this code could easily
have unintended consequences.
-dain
On Jun 9, 2006, at 5:59 AM, Paul McMahan wrote:
That's a good idea and it would be pretty straightforward. But now
that Dain has brought our attention to GERONIMO-1637 I'm concerned
about deviating from the G 1.2 activities where the full syntax of
maven version ranges will be introduced. I don't know much about
maven version ranges - there may be some subset that can be
implemented during G 1.1.x that addresses our specific concerns about
forcing plugins to continually update their geronimo-plugin.xml.
Best wishes,
Paul
On 6/8/06, Donald Woods <[EMAIL PROTECTED]> wrote:
Paul, what if we tweaked your proposed patch and allowed the
plugin to
provide an optional attribute of exactVersion=required, which would
control the behavior?
-Donald
Paul McMahan wrote:
> I definitely agree that a full fledged solution for version
ranges is
> out of scope for G 1.1.x. I was thinking that a minor change to
the
> plugin installer's version checking could at least partially
address
> Donald's concerns and also avoid the version mismatch problem
Dave C.
> found in the candidate build. Here's a patch that makes the plugin
> installer only check the digits of geronimo's version that the
> plugin's xml specifies. So if the plugin specifies
> 1.1 then it can be
installed into
> 1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
>
> Best wishes,
> Paul
>
> Index:
> modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java
>
> ===
> ---
> modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java
> (revision
> 412744)
> +++
> modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java
> (working
> copy)
> @@ -1409,7 +1409,7 @@
> if(gerVersion == null || gerVersion.equals("")) {
> throw new IllegalStateException("geronimo-version
> should not be empty!");
> }
> -if(gerVersion.equals(version)) {
> +if(version.startsWith(gerVersion)) {
> match = true;
> break;
> }
>
>
> On 6/8/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
>
>> Perhaps I was unclear; I didn't mean to say this was a bad
idea, only
>> that our code doesn't currently support it. I expect version
ranges
>> are on the road map, but if you want to work on them, you're
more than
>> welcome to. :)
>>
>> I don't think this is a G 1.1.x discussion, since AFAIK it would
>> require kernel changes.
>>
>> Thanks,
>> Aaron
>>
>> On 6/8/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> > On 6/8/06, Donald Woods <[EMAIL PROTECTED]> wrote:
>> > > What I meant by 1.1.* was the Maven behavior of private
builds like
>> > > 1.1-1 being taken as newer than 1.1. Also, being able to
use the
>> > > behavior of 1.1- is less than 1.1.
>> Basically,
>> > > I should be able to specify 1.1 in the plugin and have it
work on
>> > > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but
doesn't on
>> 1.1.1,
>> > > then I'd argue that we broke something in 1.1.1, given it
should
>> only be
>> > > a maintenance release and app/plan breaking changes should
only go
>> into 1.2.
>> >
>> > +1 This approach is similar to how eclipse plugin
versioning works.
>> >
>> > From http://www.eclipse.org/equinox/documents/plugin-
versioning.html :
>> > "How to specify plug-in requirements
>> > Plug-ins that require other plug-ins must qualify their
requirements
>> > with a version range since the absence of a version range
means that
>> > any version can satisfy the dependency. Given that all the
changes
>> > between the version x.0.0 and the version x+1.0.0 excluded
must be
>> > compatible (given the previous guidelines); the recommended
range
>> > includes the minimal required version up-to but not including
the next
>> > major release."
>> >
>> > IMHO geronimo should adopt eclipse's strategy for plugin
versioning
>> > where possible since the two sets of base requirements are quite
>> > similar and eclipse is a few years ahead in this area. The
document
>> > referenced above spells out their strategy in detail.
>> >
>> > Best wishes,
>> > Paul
>> >
>>
>
>
Re: Frustrations of a Release Manager
Bruce Snyder wrote: > On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > >> No Bruce, thats not it at all. Its simply discussing what he was going >> to do. This all comes back to the lack of communication issue. > > So you would have preferred that he send an email to the list > explaining the work he was doing on the code? I think it was clear what was wanted and needed...communication. Lets go back to your statement that "we can agree to disagree"...we are beating a dead horse here... > > Bruce
Re: [jira] Updated: (GERONIMO-2099) Source for Console Oracle XA plugin
Very cool example of what can be done with plugins :-) Can we use G2099 to start creating a new subproject space for ASL 2.0 based Samples and Plugins in SVN? Something that fits into the normal Maven model of - /geronimo /samples /trunk /modules - dir would contain sample app dirs like magicgball /plugins - dir would contain config/plugin dirs for samples and other external ASL apps like DirectoryServer and JetSpeed2 Maybe we can start by creating the structure in Sandbox and then vote to move it over when everything is building? -Donald Aaron Mulder (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2099?page=all ] Aaron Mulder updated GERONIMO-2099: --- Description: Here's the "code" used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/(category)/(plugin)/trunk... in SVN It's a little cheesy in that it uses a couple class files from the console, but it seems like we need to move those classes out of the console WAR in order to refer to them from a child module classpath. was:Here's the code used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/... Source for Console Oracle XA plugin --- Key: GERONIMO-2099 URL: http://issues.apache.org/jira/browse/GERONIMO-2099 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: Plugins Versions: 1.1 Reporter: Aaron Mulder Attachments: console-tranql-oracle-xa-plugin.zip Here's the "code" used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/(category)/(plugin)/trunk... in SVN It's a little cheesy in that it uses a couple class files from the console, but it seems like we need to move those classes out of the console WAR in order to refer to them from a child module classpath. smime.p7s Description: S/MIME Cryptographic Signature
Re: Frustrations of a Release Manager
On 6/9/06, Bruce Snyder <[EMAIL PROTECTED]> wrote: On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > No Bruce, thats not it at all. Its simply discussing what he was going > to do. This all comes back to the lack of communication issue. So you would have preferred that he send an email to the list explaining the work he was doing on the code? But... there was no work on the code. All I did was add configs/src/plan/geronimo-plugin.xml to the 4 directory-related configs (directory, ldap-realm, ldap-demo-jetty and ldap-demo-tomcat). And then put the CAR files on the plugin site so instead of requiring someone to manually locate the various module files and deployment plans and 20 prerequisite JARs and apply them all in the correct order, you can click through the console (or deploy tool) and it does the heavy lifting for you. I guess I fixed a bug in the POM too where ldap-realm didn't depend on directory, or something like that. Thanks, Aaron
Re: Sandbox ACL question
FWIU, having commit access to svn at apache requires you to have an apache account which means you need to be a committer on some apache project. I believe that apache only has the one process to get committ access. Sorry, -dain On Jun 9, 2006, at 11:04 AM, Donald Woods wrote: Can we modify the Sandbox ACL so people in the contributors group can have svn write authority? It seems that allowing contributors into the sandbox would be a great way for us to provide more complex patches and enhancements while proving our worth towards becoming a committer -Donald
Database Pool Creation error
Hello all, I don't know if anyone has had any issues creating database pools with the snapshot from Wednesday. But, began testing today and I cannot create a new database pool using the wizard (mySQL connection) Log output for 'show plan' and 'deploy plan' below. If anyone has a patch that corrects this please let me know. Thanks, Jay McHugh logs follow --- When I attempt to 'show plan' prior to deploying the plan (created with the wizard) I get the following log output: 15:53:22,969 ERROR [DatabasePoolPortlet] Unable to save connection pool java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:876) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) 15:53:23,112 ERROR [DatabasePoolPortlet] Unable to render portlet java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderPlan(DatabasePoolPortlet.java:831) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:679) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpSe
Re: Anschluss - CORBA specs new home
Changing a released jar in the repository is a bad idea. There is no real down side to having some old releases with "incubator" in the name, and we when the project graduated we would just update the poms to their new name. Anyway, as Alan pointed out, it most likely isn't worth the effort to move the code now. -dain On Jun 8, 2006, at 11:38 PM, John Sisson wrote: Don't they have to have "incubator" as part of the file names and then when they exit the incubator they can remove "incubator" from the name. Sounds like it may create extra work changing Geronimo POMs to point to the correct files at different stages. Are the groupIDs changing too? John Dain Sundstrom wrote: Projects in the incubator can do releases. They do have a restriction until the IP is cleared, but once that is done they can release using the normal release process. -dain On Jun 5, 2006, at 6:29 PM, Matt Hogstrom wrote: I'm ok with it but would prefer to turn them over after Yoko graduates. My understanding is that an incubator project can't release anything. I expect they don't change a whole lot but that would be my only reservation. Alan D. Cabrera wrote: I think that it's time that we, Yoko, take responsibility for the CORBA spec jars. After Geronimo releases v1.1, let's plan on moving them over to Yoko. Thoughts? Regards, Alan
Re: Frustrations of a Release Manager
On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
No Bruce, thats not it at all. Its simply discussing what he was going
to do. This all comes back to the lack of communication issue.
So you would have preferred that he send an email to the list
explaining the work he was doing on the code?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Some features for 1.1.1 -- module/deployment extensions
FYI, I plan to address http://issues.apache.org/jira/browse/GERONIMO-1873 as soon as possible in 1.1.1. I'd like plugins to be able to define new deployment unit formats (e.g. JBI service assemblies, a Spring deployment unit, a Quartz job as a deployment unit, or a Jasper report as a deployment unit). Any of those will probably need a geronimo-XYZ.xml deployment plan, to supply a module ID and dependencies if nothing else. And currently, the deploy tool doesn't know how to crack open an arbitrary deployment unit and figure out its module ID, which is necessary to support redeployment when the plan is embedded in the archive (it has to know what existing module(s) to replace). There are two possible solutions: one is to stop using JSR-88 for deployment and just pass the archive to the server and let it do its thing; the other is to let each deployer indicate the name of its deployment plan (when the plan is packed in the module). I'd lean toward the second approach for 1.1.1, as it's a fairly trivial change. A related question is whether we should let you pack non-J2EE deployment units in an EAR. That is, if we define a JasperReports report deployment unit, should your EAR be able to contain a WAR, an EJB JAR, and 2 reports? I would think so, though we may choose to implement a wrapper that would hold the EAR and the 2 reports instead. I'm not sure how extensive a change this might require -- we seem to have some special handling for classpaths for modules within an EAR, and I don't know where that happens and what's likely to break. If we do nothing, the alternative is that you'd only be able to redeploy new types of modules if you pass either the module ID or the plan on the command line along with the archive (no packing plan in archive), and if you had a J2EE app and a handful of other modules that all work together, you would still have to deploy/redeploy them all individually. Thanks, Aaron
Re: JIRA project for GShell?
On Jun 9, 2006, at 9:35 AM, Alan D. Cabrera wrote: Jason Dillon wrote: Can we create a new JIRA project for GShell? I've got a bunch of task/todo items that I would like to track in JIRA so it is easier to prioritize and plan. Thoughts? --jason IMO, if it gets out of the sandbox, it deserves a Jira project. I seen no reason not to give it a JIRA. If it dies in the sandbox, we can always delete the JIRA. -dain
Re: Geronimo doesn't startup if restart it using another JDK
As jason pointed out using a hash code isn't portable. This is a known problem in Howl and IIRC they added an optional flag in howl to use a specified hash algorithm. Anyway, please create a JIRA (http:// issues.apache.org/jira/browse/GERONIMO) for this issue. -dain On Jun 9, 2006, at 3:32 AM, Udovichenko, Nellya wrote: Hello, I have launched Geronimo on Sun JDK. Then I’ve tried to run it with Harmony class library and IBM VM j9. I’ve got the error log below. Also I’ve got the same result when launched Geronimo on Harmony and then - on Sun JDK. There is a bug in HOWL repaired in howl-1.0.1 by the new parameter (adler32Checksum) adding. At Geronimo startup it checks the log files' validity if they exist. One of verified parameters is the file content control sum. One value of this sum is read from file header and another is calculated by function java.nio.ByteBuffer.hashCode (). So if the algorithms of hash code functions of the JDKs are different Geronimo doesn’t startup. If the parameter adler32Checksum value is false the control sum is calculated by function java.nio.ByteBuffer.hashCode() otherwise it is calculated using ADLER-32 algorithm. Therefore, I think, it would be correct to add this parameter to configs/j2ee-server/src/plan/plan.xml and to gbean org.apache.geronimo.transaction.log.HOWLLog with value 'true'. Any thoughts? Thanks, Nellya Udovichenko, Intel Middleware Products Division Error log: $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.4.2_01)... Starting Geronimo Application Server v1.1-20060607 [**> ] 11% 6s Starting geronimo/j2ee-server/ 1...14:23:30,3 19 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED s tate: abstractName="geronimo/j2ee-server/1.1-20060607/car? ServiceModule=geronimo /j2ee-server/1.1-20060607/ car,j2eeType=TransactionLog,name=HOWLTransactionLog" org.objectweb.howl.log.InvalidLogBufferException: CHECKSUM Class: org.objectweb.howl.log.BlockLogBuffer workerID: LogFile: C:\Nellya\geronimo-1.1\var\txlog\howl_1.log HEADER HEADER_ID: 0x484f574c bsn: 0x1 size: 0x8000 should be: 0x8000 data used: 0x4f checkSum: 0x2227d tod: 0x10bb850e3b1 crlf: 0xd0a FOOTER FOOTER_ID: 0x4c574f48 bsn: 0x1 tod: 0x10bb850e3b1 crlf: 0xd0a at org.objectweb.howl.log.BlockLogBuffer.read (BlockLogBuffer.java:460) at org.objectweb.howl.log.LogFileManager.init (LogFileManager.java:821) at org.objectweb.howl.log.Logger.open(Logger.java:314) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:893) at org.apache.geronimo.transaction.log.HOWLLog.doStart (HOWLLog.java:217) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start (GBeanInstance.j ava:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency $1.running(GBeanDepe ndency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor $RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:512) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:493) at org.apac
Re: Frustrations of a Release Manager
Comment below... Bruce Snyder wrote: > On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> >> >> Bruce Snyder wrote: >> > On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> > >> >> There is no obligation for you to consult me to take the Directory >> >> integration, re-package it, and place it on geronimoplugins.com. But >> >> out of basic respect, opening up the discussion of others on the idea, >> >> and then yes, as your friend, and colleague, asking me how I felt >> about >> >> taking the package and placing it on gp.com (which I did write and >> spend >> >> my time putting together), probably would have been most appropriate. >> >> It is kind of demoralizing for me to see the work that I did, end >> up on >> >> the geronoimplugins site w/o discussion from a colleague of mine. I >> >> hope that makes sense... >> > >> > Some code that you wrote and licensed using the Apache License got >> > reused and you find it demoralizing? This is completely in the letter >> > and the spirit of the Apace License. How is such reuse demoralizing? >> > Not only is this legal, it's encouraged. Please help me understand >> > this sentiment. >> >> >> >> Bruce, >> >> Perhaps I am not being very good at communicating...let me paste what I >> wrote before, and you can perhaps show me the error of my feelings... >> >> "Although nothing in the Apache License prohibits you from doing this, >> it would have been prudent and shown respect to your peers who put >> together the example applications and the Directory integration, to have >> had some discussions about doing this and how they felt about it. Its >> more of a ethical and respect issue, IMHO." >> >> The words I am trying to convey here are "ethical, respect, and >> prudent". Being that we are all friends, I think we can abide by the >> spirit of the law, rather than the letter. Would you agree? > > Well I think we're just going to have to agree to disagree on this > topic. I don't care if my code is reused, twisted, refactored, deleted > or otherwise. When I apply the Apache License to my code, I hope that > others reuse it in some way. I actually do consider this reuse ethical > and respectful. I take it as the highest complement that someone would > reuse my code because it means that I saved them the trouble of > reinventing the wheel. > > I think that it's our interpretations that differ. Are you simply > looking for a tip of the hat type of thing or something more? > No Bruce, thats not it at all. Its simply discussing what he was going to do. This all comes back to the lack of communication issue. > Bruce
Re: Frustrations of a Release Manager
On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Bruce Snyder wrote:
> On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
>
>> There is no obligation for you to consult me to take the Directory
>> integration, re-package it, and place it on geronimoplugins.com. But
>> out of basic respect, opening up the discussion of others on the idea,
>> and then yes, as your friend, and colleague, asking me how I felt about
>> taking the package and placing it on gp.com (which I did write and spend
>> my time putting together), probably would have been most appropriate.
>> It is kind of demoralizing for me to see the work that I did, end up on
>> the geronoimplugins site w/o discussion from a colleague of mine. I
>> hope that makes sense...
>
> Some code that you wrote and licensed using the Apache License got
> reused and you find it demoralizing? This is completely in the letter
> and the spirit of the Apace License. How is such reuse demoralizing?
> Not only is this legal, it's encouraged. Please help me understand
> this sentiment.
Bruce,
Perhaps I am not being very good at communicating...let me paste what I
wrote before, and you can perhaps show me the error of my feelings...
"Although nothing in the Apache License prohibits you from doing this,
it would have been prudent and shown respect to your peers who put
together the example applications and the Directory integration, to have
had some discussions about doing this and how they felt about it. Its
more of a ethical and respect issue, IMHO."
The words I am trying to convey here are "ethical, respect, and
prudent". Being that we are all friends, I think we can abide by the
spirit of the law, rather than the letter. Would you agree?
Well I think we're just going to have to agree to disagree on this
topic. I don't care if my code is reused, twisted, refactored, deleted
or otherwise. When I apply the Apache License to my code, I hope that
others reuse it in some way. I actually do consider this reuse ethical
and respectful. I take it as the highest complement that someone would
reuse my code because it means that I saved them the trouble of
reinventing the wheel.
I think that it's our interpretations that differ. Are you simply
looking for a tip of the hat type of thing or something more?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
[jira] Created: (SM-449) Create a set of annotations for a JBI binding for jaxws
Create a set of annotations for a JBI binding for jaxws --- Key: SM-449 URL: https://issues.apache.org/activemq/browse/SM-449 Project: ServiceMix Type: New Feature Components: servicemix-jsr181 Reporter: Guillaume Nodet It would require hacking a bit XFire to also generate the needed wsdl binding infos. Not sure if it is really needed however. We also need a wsdl->java which can handle a wsdl without a soap binding. -- 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: Frustrations of a Release Manager
Bruce Snyder wrote: > On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > >> There is no obligation for you to consult me to take the Directory >> integration, re-package it, and place it on geronimoplugins.com. But >> out of basic respect, opening up the discussion of others on the idea, >> and then yes, as your friend, and colleague, asking me how I felt about >> taking the package and placing it on gp.com (which I did write and spend >> my time putting together), probably would have been most appropriate. >> It is kind of demoralizing for me to see the work that I did, end up on >> the geronoimplugins site w/o discussion from a colleague of mine. I >> hope that makes sense... > > Some code that you wrote and licensed using the Apache License got > reused and you find it demoralizing? This is completely in the letter > and the spirit of the Apace License. How is such reuse demoralizing? > Not only is this legal, it's encouraged. Please help me understand > this sentiment. Bruce, Perhaps I am not being very good at communicating...let me paste what I wrote before, and you can perhaps show me the error of my feelings... "Although nothing in the Apache License prohibits you from doing this, it would have been prudent and shown respect to your peers who put together the example applications and the Directory integration, to have had some discussions about doing this and how they felt about it. Its more of a ethical and respect issue, IMHO." The words I am trying to convey here are "ethical, respect, and prudent". Being that we are all friends, I think we can abide by the spirit of the law, rather than the letter. Would you agree? Jeff > > Bruce
Re: Frustrations of a Release Manager
On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
There is no obligation for you to consult me to take the Directory
integration, re-package it, and place it on geronimoplugins.com. But
out of basic respect, opening up the discussion of others on the idea,
and then yes, as your friend, and colleague, asking me how I felt about
taking the package and placing it on gp.com (which I did write and spend
my time putting together), probably would have been most appropriate.
It is kind of demoralizing for me to see the work that I did, end up on
the geronoimplugins site w/o discussion from a colleague of mine. I
hope that makes sense...
Some code that you wrote and licensed using the Apache License got
reused and you find it demoralizing? This is completely in the letter
and the spirit of the Apace License. How is such reuse demoralizing?
Not only is this legal, it's encouraged. Please help me understand
this sentiment.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: [RTC] : Migrate remote-deploy to m2
Sounds good. As per your comments I have attached instructions in the comments and a patch (remote-deploy-v3.patch) that will also take into account m1 build. Please review and vote. Cheers Prasad On 6/9/06, David Jencks <[EMAIL PROTECTED]> wrote: I don't think this is quite ready for a vote yet, and I'm not convinced it requires a vote. First, it really should include more of a description of what the purpose of the change is, such as: "Due to bugs in the web app classloader in 1.0, the remote deploy war was split into 2 modules. Since that classloader bug has been resolved in 1.1 it's time to merge this stuff back into one module" Second, when a patch moves a file, it should not be applied as a patch. The patch might be OK to look at, but we have to preserve svn history, so whoever is going to "apply the patch" needs to know the svn commands that resulted in the patch. Here we need something like "Run these svn commands: svn mv modules/remote-deploy-lib/src/java/..java modules/remote- deploy/src/java/ ... svn rm modules/remote-deploy-lib " Other adjustments to make the build work again should be in a patch that does not include the effects of the svn commands. Thirdly I don't think this patch fixes the m1 build unfortunately we can't throw it out yet. The reason I don't think this requires a vote is that it does not change any java code and is part of the bug fix to the web app classloading. However I think since you proposed a vote and we haven't had much practice voting yet it would be a good idea to go through the vote process on this small uncontroversial change. Many thanks david jencks On Jun 9, 2006, at 9:23 AM, Prasad Kashyap wrote: > Merged remote-deploy-lib with remote-deploy. > Migrated remote-deploy to M2. > > http://issues.apache.org/jira/browse/GERONIMO-2098
Re: Frustrations of a Release Manager
Aaron Mulder wrote: > On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> I brought this up as an issue originally as it bothered me. This has >> nothing to do with Erin, so let's not obfuscate the issue. The point >> here is there was absolutely no discussion about this, as this was >> clearly a fairly large decision that we, as a community, should have >> been involved in. Unless I missed something, I do not recall anyone >> talking about registering a site with Geronimo plugins before it >> occurred. > > Um... OK. I didn't think setting up a site to hold the plugins was > that big a deal. If it bothered you, I'm sorry. Let's talk about it. > What do you recommend? The constraints I see are that is should be > able to host Apache, GPL, LGPL, and commercial code. Do you agree? > Disagree? What do you recommend for a hosting site? Lets make this another thread...I have several thoughts on this. Thanks for asking. > >> This also bothered me as a peer, since a lot of the work I did on the >> Directory server integration was taken out of Geronimo, then wrapped up >> into a plugin and placed on this external site, without input from >> others, as well as those who did the hard work on integration. > > I find this extra-confusing. I took a piece of Geronimo which was > hard-coded into the product (e.g. via our assembly system) and made it > a modular part of the product (e.g. a plugin that you can install or > not as you please). And you feel that as the primary author of the > code, you should have been consulted? That I'm somehow using your own > hard work to my advantage instead of to improve the product as a > whole? I'm sorry for offending you. But I don't understand your > objection. There is no obligation for you to consult me to take the Directory integration, re-package it, and place it on geronimoplugins.com. But out of basic respect, opening up the discussion of others on the idea, and then yes, as your friend, and colleague, asking me how I felt about taking the package and placing it on gp.com (which I did write and spend my time putting together), probably would have been most appropriate. It is kind of demoralizing for me to see the work that I did, end up on the geronoimplugins site w/o discussion from a colleague of mine. I hope that makes sense... > >> Although >> nothing in the Apache License prohibits you from doing this, it would >> have been prudent and shown respect to your peers who put together the >> example applications and the Directory integration, to have had some >> discussions about doing this and how they felt about it. Its more of a >> ethical and respect issue, IMHO. > > I think we agreed that it was a mistake to include so much (samples, > LDAP, etc.) in the base Geronimo distribution. The Java 5 stack trace > in Geronimo 1.0 was directly attributable to this, plus we've been > working hard to slim down our distributions. I am pretty sure we > agreed on that in discussions on the list, though it's been a while. > But I still don't understand how changing or repackaging code is > showing disrespect. We're all in this together, and it's not your > code or my code, it's our code. I promise, if you make the console > more modular so it runs in Little G just as well as Big G, I won't be > offended, I'll buy you a beer. > Yes...nothing wrong with the removal. It was the sudden appearance on geronimoplugins.com that I took issue with. This was purely a communication thing for me. >> As for your question, my counter proposal is having significant >> discussion with others before taking action. > > Well, OK, as I said, let's have the discussion. Sorry it wasn't > sooner, but better late than never, eh? > Yes, and thanks for acknowledging this. >> Relative to the private emails, I received an email from you privately >> after I brought up the geronimoplugins that was very aggressive, along >> with verbiage that bordered on threatening language. Your private email >> to me started out with "Watch your tone". This is the intimidation >> stuff that I have referred to in the past, and it concerns me quite a >> bit. > > Yeah, I admit, I was a little fired up after you posted my address to > the list. :) Sorry. > Its ok...we sometimes read into things deeper than we should. As I have told you on the side, and I will publicly state again...I meant nothing by this negatively. It was a cut and paste from the publicly available whois database, and assumed it was purely public...and I certainly did not know it was your address (I assumed it may have been an office or other), but in retrospect, I agree I shouldn't have done that and I apologized publicly for it. >> I attended for a total of about an hour. I am speaking from hearsay >> here...but was Geir's presence, or lack-there-of discussed? I was told >> by someone that it was actually discussed at the meeting. >> >> This in-and-of-itself is the issue. Knowing Geir was in town, and >>
Re: 1.1 Release plan
So as I understand this, the plan is: - new release candidate today, no more non-critical patches - begin voting for that release candidate today - if critical bugs are found within 72 hours, someone will -1 the vote, we will fix and cut a new release candidate, and start a new 72-hour vote I'm OK with that for this release (I don't think it's ideal, but I agree that it will be nice to get this release out the door, so I'm on board). I hope someone will look at the weird web services error during deployment, because I don't know what to make of that (if it's reproduceable and how significant it is). If I'm right about the release plan, I think we should create a SVN home for 1.1.1-SNAPSHOT now so there's a place to put non-critical patches. It will be annoying to put critical patches into 3 places, but we're hoping there aren't any of those. Thanks, Aaron On 6/8/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Final Items for 1.1 I would like to release Geronimo 1.1 on June 12th. Yes, that is three days away. If we can't make that date then it will be 72 hours away from each candidate build. Problem that are found need to be addressed if they are deemed critical. Otherwise they will be tracked and solved in a follow on release. That said. I sent a note earlier today announcing the freeze to branches/1.1. Changes to this branch should be limited to bug fixes only. The little changes are the ones that generally burn you. At 1400 ET the Inn is closed and I will spin up a release that will be our release candidate. The issues that have been raised from the previous build were Guillaume's observation of the problem when running Geronimo under CygWin as well as the license and Notice issues. Since Geronimo is a multifaceted project there are several things that need to be voted on. They are Geronimo itself, the specification jars and DayTrader. Geronimo itself is the significant component that will carry the other items so I believe a vote for Geronimo in this context is a vote for all three items. *There is a concern about the specification jars* David Jencks raised this issue in another note on the list. The jars have not been released but they have had a tag cut and the resulting compilation has been placed on http://people.apache.org/repository. One of the issues I found with the spec is that there are different spec releases in the 1_1 tag. I would prefer that all jars have the same version suffix. Right now it includes 1.0, 1.0.1, 1.1 and others. I think this is confusing. We release Geronimo with all the same module versions even if nothing has changed. I would like to move that we recut a 1_2 tag with all spec jars having a 1.2 suffix. *DayTrader* Day Trader is currently a 1.1-SNAPSHOT as well. We will release the DayTrader Ear (separate from Geronimo) as a 1.1 version as well. This way the build will be in sync. *Issues* 1. It was noted earlier today that there is a problem with Geronimo under CygWin. Guillaume noted that an issue exists where a file is not renamed (config.xml). Given that CygWin is a hybrid environment I think we should investigate this problem but not hold up the release. 2. Guillaume also pointed out the lack of a License and Notices file. I will include the two files from the SVN geronimo/branches/1.1 in the build tomorrow. 3. Numerous bug fixes are being addressed. Excellent. Apart from Spec issue above I think we have most everything addressed. Does this list of outstanding items and release plan make sense? Matt
Re: Frustrations of a Release Manager
On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: I brought this up as an issue originally as it bothered me. This has nothing to do with Erin, so let's not obfuscate the issue. The point here is there was absolutely no discussion about this, as this was clearly a fairly large decision that we, as a community, should have been involved in. Unless I missed something, I do not recall anyone talking about registering a site with Geronimo plugins before it occurred. Um... OK. I didn't think setting up a site to hold the plugins was that big a deal. If it bothered you, I'm sorry. Let's talk about it. What do you recommend? The constraints I see are that is should be able to host Apache, GPL, LGPL, and commercial code. Do you agree? Disagree? What do you recommend for a hosting site? This also bothered me as a peer, since a lot of the work I did on the Directory server integration was taken out of Geronimo, then wrapped up into a plugin and placed on this external site, without input from others, as well as those who did the hard work on integration. I find this extra-confusing. I took a piece of Geronimo which was hard-coded into the product (e.g. via our assembly system) and made it a modular part of the product (e.g. a plugin that you can install or not as you please). And you feel that as the primary author of the code, you should have been consulted? That I'm somehow using your own hard work to my advantage instead of to improve the product as a whole? I'm sorry for offending you. But I don't understand your objection. Although nothing in the Apache License prohibits you from doing this, it would have been prudent and shown respect to your peers who put together the example applications and the Directory integration, to have had some discussions about doing this and how they felt about it. Its more of a ethical and respect issue, IMHO. I think we agreed that it was a mistake to include so much (samples, LDAP, etc.) in the base Geronimo distribution. The Java 5 stack trace in Geronimo 1.0 was directly attributable to this, plus we've been working hard to slim down our distributions. I am pretty sure we agreed on that in discussions on the list, though it's been a while. But I still don't understand how changing or repackaging code is showing disrespect. We're all in this together, and it's not your code or my code, it's our code. I promise, if you make the console more modular so it runs in Little G just as well as Big G, I won't be offended, I'll buy you a beer. As for your question, my counter proposal is having significant discussion with others before taking action. Well, OK, as I said, let's have the discussion. Sorry it wasn't sooner, but better late than never, eh? Relative to the private emails, I received an email from you privately after I brought up the geronimoplugins that was very aggressive, along with verbiage that bordered on threatening language. Your private email to me started out with "Watch your tone". This is the intimidation stuff that I have referred to in the past, and it concerns me quite a bit. Yeah, I admit, I was a little fired up after you posted my address to the list. :) Sorry. I attended for a total of about an hour. I am speaking from hearsay here...but was Geir's presence, or lack-there-of discussed? I was told by someone that it was actually discussed at the meeting. This in-and-of-itself is the issue. Knowing Geir was in town, and especially knowing the fact that he was responsible for obtaining a speaker pass for you at JavaOne, I am having a difficult time understanding how or why he would be excluded from the event. JavaOne is a time many of us (Geronimo) come together, and I believe we all should have the opportunity to be together, regardless of our feelings (positive or negative) about each other. For those who could not attend, a dial-in probably could have been arranged. This should have been more open, and I am myself guilty for attending this when I noticed not everyone was there. We have all earned the privilege to be on Geronimo due to our dedication, contributions, and commitments we have made to Apache and Geronimo. We all should have the opportunity to engage as well. I am sure there were a number of people at JavaOne who were not invited, Geir and others. True, it would have been smart to arrange a dial-in. Ideally, many of the non-committers would have been involved as well, as their dedication and contributions should not be overlooked either. If the outcome of this is that no one should have a meeting unless the whole community is invited, I can work with that (but I don't think that's necessarily reasonable). I talked to another committer at a different conference recently, and we brainstormed some ideas for improving the product. Was that wrong? Where's the line? Is 5 people OK but 15 isn't? If there was some policy, believe me, I'd work with it. Perhaps we should organize a series of
[jira] Updated: (GERONIMO-2098) Application migration to Maven 2: remote-deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2098?page=all ] Prasad Kashyap updated GERONIMO-2098: - Attachment: remote-deploy-v3.patch Please apply remote-deploy-v3.patch. It takes care of the configs too in an m1 build. This has been deployed on an m1 server and it starts. > Application migration to Maven 2: remote-deploy > --- > > Key: GERONIMO-2098 > URL: http://issues.apache.org/jira/browse/GERONIMO-2098 > Project: Geronimo > Type: Sub-task > Security: public(Regular issues) > Components: application client > Versions: 1.2 > Reporter: Prasad Kashyap > Assignee: David Jencks > Fix For: 1.2 > Attachments: remote-deploy-v2.patch, remote-deploy-v3.patch, > remote-deploy.patch > > Merge remote-deploy-lib with remote-deploy > Migrate remote-deploy to M2. -- 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: Frustrations of a Release Manager
Aaron, Sure. I assumed for a bit that the RTC [1] and PMC Changes [2] instituted by our pmc chair had sent a strong signal and wrongfully thought that had its desired effect, which is to help improve collaboration and make sure there are no "exclusionary walls" w.r.t participating in Geronimo development. -- dims [1] http://marc.theaimsgroup.com/?l=geronimo-dev&m=114825592721785&w=2 [2] http://geronimo.apache.org/contributors.html On 6/9/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: On 6/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Sigh! :( Looks like all efforts are down the drain. I'm not sure what this means. Can you elaborate? Thanks, Aaron > On 6/9/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > > I don't see what's wrong with a group of folks interested in Gernoimo > > getting together to talk about Geronimo. So long as it's positioned > > as discussion not decision-making, of course -- which, as I recall, it > > was. > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Frustrations of a Release Manager
I just saw this thread and want to say my 2c, I haven't yet read the other threads and have to run out so sorry if this statement has been repeated. The most important thing we can do to make the project succeed is to ship, and to ship often. Moving forward we need to have a fixed interval of when we release and based on those intervals each of us need to be accountable on what we can commit. We desperately need to be able to "give-up" function, meaning we must be willing to modify our roadmap of contained items and defer items if they cannot be contained within the schedule, rather then push out the schedule which seems to be the easy answer. If we can prove to our users that they can constantly expect releases at consistent intervals this would be a huge win. Take a look at the Callisto effort in Eclipse. Not only has the Eclipse project not missed a release date in who knows how long (if ever), but now they are releasing 10 top level projects simultaneously. I say we learn from the eclipse model, follow it, and tweak the process to our needs. -sachin On Jun 9, 2006, at 9:34 AM, Aaron Mulder wrote: In the spirit of greater openness and communication, please elaborate on 'thing have been "quietly" injected into Geronimo'. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Bruce Snyder wrote: > On 6/8/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > >> I think it will help to have the schedule of the release. No one can >> claim IBM has a secret agenda if the time line is laid out there. And >> it's easy to wink if no one has any idea what the deadlines we're >> working toward are. > > I agree with Aaron here - publicity of not only the timeline (i.e., a > calendar of release schedules maybe) but also the Road Map may help on > all fronts. IMO we should consider publishing and continually > revisiting both of these items. I know that this won't be a popular > suggestion on the committer side of things because we are a volunteer > organization, but it would most certainly help our user community > immensely. I have to disagree here. Although I absolutely agree a roadmap is helpful and trackable, the timeline and release issues that Matt has talked about is clearly an issue. On these lists, Matt has made things extremely clear regarding when our releases should be, along with group consensus, and thing have been "quietly" injected into Geronimo. I share Matt's feelings and frustrations. Minimally, if we cannot hold to a simple date based on agreement on these lists, a roadmap, although helpful, will surely not be a panacea. It is also my hope that there are not private emails going around talking about "secret" agendas. This would dismay me as I fully expect that we are all adult enough to share our feelings with each other in these lists. If an email like this is being passed around, then we clearly need to be working on our communication skills and have a long way to go on learning to work with each other as a team. I think communication is
Re: Frustrations of a Release Manager
On 6/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
Sigh! :( Looks like all efforts are down the drain.
On 6/9/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> I don't see what's wrong with a group of folks interested in Gernoimo
> getting together to talk about Geronimo. So long as it's positioned
> as discussion not decision-making, of course -- which, as I recall, it
> was.
Dims, statements like that don't work to bring the community together,
they only cause more animosity. Let's try to move beyond the jabs and
let the people with unresolved issues air their concerns so that they
can work together.
Yet again I'm now thoroughly confused on this whole topic. Does this
mean that nobody can even talk about Geronimo unless it's on-list in
some way? Does this mean if someone at a client site or a local JUG or
anywhere asks me questions about Geronimo that I must either tell them
to ask on the list because I'm not allowed to talk about it or post my
conversation to the list after the fact?
I really am seriously confused because of so many mixed messages from
so many people about this topic. Please help me understand.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: Frustrations of a Release Manager
I have entered my own comments below... Aaron Mulder wrote: > On 6/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: >> Aaron, >> >> Since you asked. First, Can you respond below if you will allow >> anyone that you have sent a private >> e-mail to to cut and paste the contents of those messages into other >> posts on this thread. I think >> that will help. > > Sure. > >> Second, the geronimoplugins.com which was injected into Geronimo is >> probably a good place to start. >> Here is a snip from whois of that domain. I removed the address >> specific information. >> >> Registrant: >> Address is provided *Removed* >> Domain Name: GERONIMOPLUGINS.COM >>Created on: 11-Apr-06 >>Expires on: 11-Apr-07 >>Last Updated on: 11-Apr-06 >> >> Administrative Contact: >>Mulder, Erin [EMAIL PROTECTED] >> >> Technical Contact: >>Mulder, Erin [EMAIL PROTECTED] > > Yes, of course, that's a domain we got, because the project needs one, > and it can't be at Apache (due to the LGPL issue). I've offered a > number of times to give people accounts to help manage the site, and > so far, no one's taken me up on it. My goals are to provide a Maven > repository (=HTTP site) that can hold *all* plugins, ASF, LGPL, GPL, > proprietary. Since I didn't see one out there, Erin was gracious > enoguh to provide one. And now you're jumping on her for it? That's > gratitude! > > Also, recall that the file defining the available plugin repositories > is hosted by the ASF, so the ASF can change the list of available > sites away from geronimoplugins.com at any time. > > What is your counter-proposal? I brought this up as an issue originally as it bothered me. This has nothing to do with Erin, so let's not obfuscate the issue. The point here is there was absolutely no discussion about this, as this was clearly a fairly large decision that we, as a community, should have been involved in. Unless I missed something, I do not recall anyone talking about registering a site with Geronimo plugins before it occurred. This also bothered me as a peer, since a lot of the work I did on the Directory server integration was taken out of Geronimo, then wrapped up into a plugin and placed on this external site, without input from others, as well as those who did the hard work on integration. Although nothing in the Apache License prohibits you from doing this, it would have been prudent and shown respect to your peers who put together the example applications and the Directory integration, to have had some discussions about doing this and how they felt about it. Its more of a ethical and respect issue, IMHO. As for your question, my counter proposal is having significant discussion with others before taking action. Relative to the private emails, I received an email from you privately after I brought up the geronimoplugins that was very aggressive, along with verbiage that bordered on threatening language. Your private email to me started out with "Watch your tone". This is the intimidation stuff that I have referred to in the past, and it concerns me quite a bit. >> Shall we begin to discuss the meeting at Java One that you proposed >> that specifically excluded >> members of the community. I'd be happy to bring that discussion to >> the list if you like. Given >> that IBM paid for the room that the discussion occurred in we are >> somewhat culpable but given that >> you were the master mind behind the exclusionary wall I'm happy to >> have that discussion in the open >> as well. > > Well, actually, it was kind of a joint idea between myself and a few > other people who thought there were some things we ought to talk about > so long as we were all together. I'm sorry that there's a perception > of an exclusionary wall. It was on us to pay for the food, which at > hotel rates was $100 per person for the day, so naturally I wasn't > able to invite the entire Geronimo community. I apologize to everyone > in the community who wasn't able to be at JavaOne or who wasn't > invited, but it seemed like an ideal scenario for many of us to get > together and discuss some of the current issues and then take the > discussion points to the mailing list. If you objected, why am I > first hearing about it now? I attended for a total of about an hour. I am speaking from hearsay here...but was Geir's presence, or lack-there-of discussed? I was told by someone that it was actually discussed at the meeting. > > And anyway, what is the perception of the "right" thing to do? If > it's not economically feasible for every user, contributor, committer, > and PMC member to get together does that mean no meeting should > happen? If so, will IBM immediately cease having any meetings or > phone calls discussing Geronimo issues? Or are you going to provide > an international dial-in for every one, and hold them in the middle of > the night for the convenience of the Asian community? > > I do
Re: Frustrations of a Release Manager
On 6/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Sigh! :( Looks like all efforts are down the drain. I'm not sure what this means. Can you elaborate? Thanks, Aaron On 6/9/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > I don't see what's wrong with a group of folks interested in Gernoimo > getting together to talk about Geronimo. So long as it's positioned > as discussion not decision-making, of course -- which, as I recall, it > was.
[jira] Updated: (GERONIMO-2099) Source for Console Oracle XA plugin
[ http://issues.apache.org/jira/browse/GERONIMO-2099?page=all ] Aaron Mulder updated GERONIMO-2099: --- Description: Here's the "code" used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/(category)/(plugin)/trunk... in SVN It's a little cheesy in that it uses a couple class files from the console, but it seems like we need to move those classes out of the console WAR in order to refer to them from a child module classpath. was:Here's the code used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/... > Source for Console Oracle XA plugin > --- > > Key: GERONIMO-2099 > URL: http://issues.apache.org/jira/browse/GERONIMO-2099 > Project: Geronimo > Type: New Feature > Security: public(Regular issues) > Components: Plugins > Versions: 1.1 > Reporter: Aaron Mulder > Attachments: console-tranql-oracle-xa-plugin.zip > > Here's the "code" used to create the console TranQL/Oracle XA plugin. I'm > not sure where it should go, perhaps we should create > geronimo/plugins/(category)/(plugin)/trunk... in SVN > It's a little cheesy in that it uses a couple class files from the console, > but it seems like we need to move those classes out of the console WAR in > order to refer to them from a child module classpath. -- 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: Plugin versioning problems
Sourceforge is kind of slow, which is my main objection. But perhaps we can use it as a start. What's Javaforge? Thanks, Aaron On 6/9/06, Donald Woods <[EMAIL PROTECTED]> wrote: Inline below. Aaron Mulder wrote: > On 6/8/06, Donald Woods <[EMAIL PROTECTED]> wrote: > >> BTW - How can we add new Plugins to the geronimoplugins website? Are we >> going to setup a Geronimo subproject (like Daytrader) with the site >> framework checked into svn, along with any scripts needed to build the >> plugins? It seems convoluted to have samples and plugin builds in the >> main Geronimo tree, which are not shipped with the server or >> automatically pushed to geronimoplugins. Wouldn't it be easier to >> maintain if we moved all the samples out to /trunk/samples/modules and >> all the equivalent plugin configs to /trunk/samples/plugins? That way, >> the Samples and plugins can be built, published and enhanced separate >> from the server development > > > Currently, to get a plugin added to the web site, you can mail it to > me. If you want to help out there, it would be great to have a script > that read the plugin.xml files and emitted the various PHP files with > all the plugin info! Currently it's a little more manual. :) > > We should definitely have a separate are in the SVN tree for the > samples. There's no reason they should be tied to the Geronimo > release schedule. > > We also need a non-Apache space where we can write the plugin wrappers > for various interesting LGPL projects. If you create a project on Sourceforge or Javaforge, I'll come and help. How about project=geronimoplugins to match the website name? -Donald > > Thanks, >Aaron > >> Aaron Mulder wrote: >> > On 6/7/06, Donald Woods <[EMAIL PROTECTED]> wrote: >> > >> >> Why shouldn't the Plugin support be as robust as module >> dependencies and >> >> allow the user providing the plugin to decide if they can support >> >> geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only >> support >> >> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to >> >> me and doesn't follow previous email threads about not deviating from >> >> Maven2 versioning behavior... >> > >> > >> > But what you've said here is "why shouldn't the plugin support be as >> > robust as A and allow B" where A != B. Module dependencies let you >> > specify an exact version or no version. Plugin dependencies also let >> > you specify an exact version or no version. Neither of these support >> > 1.* or 1.1*. >> > >> >> Just as with the Tomcat JSP/Servlet Examples, you could easily >> provide a >> >> Plugin which should work on all 1.x releases >> > >> > >> > My preference it to opt-in supported version, not opt-out unsupported >> > versions. So I'd like the plugin developer to try a plugin on a >> > Geronimo version and if it works, list that version as supported. The >> > alternative will most likely lead to Geronimo being willing to install >> > a plugin but the plugin not working. If we get fancier version >> > dependencies we can consider things like "1.1.*" but I'm not sure I >> > like that. I'm willing to be convinced, but I'd want to hear from >> > more plugin developers/maintainers. >> > >> > Thanks, >> >Aaron >> > >> > >> >> >> > >
[jira] Updated: (GERONIMO-2099) Source for Console Oracle XA plugin
[ http://issues.apache.org/jira/browse/GERONIMO-2099?page=all ] Aaron Mulder updated GERONIMO-2099: --- Attachment: console-tranql-oracle-xa-plugin.zip > Source for Console Oracle XA plugin > --- > > Key: GERONIMO-2099 > URL: http://issues.apache.org/jira/browse/GERONIMO-2099 > Project: Geronimo > Type: New Feature > Security: public(Regular issues) > Components: Plugins > Versions: 1.1 > Reporter: Aaron Mulder > Attachments: console-tranql-oracle-xa-plugin.zip > > Here's the code used to create the console TranQL/Oracle XA plugin. I'm not > sure where it should go, perhaps we should create geronimo/plugins/... -- 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: Plugin versioning problems
Inline below. Aaron Mulder wrote: On 6/8/06, Donald Woods <[EMAIL PROTECTED]> wrote: BTW - How can we add new Plugins to the geronimoplugins website? Are we going to setup a Geronimo subproject (like Daytrader) with the site framework checked into svn, along with any scripts needed to build the plugins? It seems convoluted to have samples and plugin builds in the main Geronimo tree, which are not shipped with the server or automatically pushed to geronimoplugins. Wouldn't it be easier to maintain if we moved all the samples out to /trunk/samples/modules and all the equivalent plugin configs to /trunk/samples/plugins? That way, the Samples and plugins can be built, published and enhanced separate from the server development Currently, to get a plugin added to the web site, you can mail it to me. If you want to help out there, it would be great to have a script that read the plugin.xml files and emitted the various PHP files with all the plugin info! Currently it's a little more manual. :) We should definitely have a separate are in the SVN tree for the samples. There's no reason they should be tied to the Geronimo release schedule. We also need a non-Apache space where we can write the plugin wrappers for various interesting LGPL projects. If you create a project on Sourceforge or Javaforge, I'll come and help. How about project=geronimoplugins to match the website name? -Donald Thanks, Aaron Aaron Mulder wrote: > On 6/7/06, Donald Woods <[EMAIL PROTECTED]> wrote: > >> Why shouldn't the Plugin support be as robust as module dependencies and >> allow the user providing the plugin to decide if they can support >> geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only support >> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to >> me and doesn't follow previous email threads about not deviating from >> Maven2 versioning behavior... > > > But what you've said here is "why shouldn't the plugin support be as > robust as A and allow B" where A != B. Module dependencies let you > specify an exact version or no version. Plugin dependencies also let > you specify an exact version or no version. Neither of these support > 1.* or 1.1*. > >> Just as with the Tomcat JSP/Servlet Examples, you could easily provide a >> Plugin which should work on all 1.x releases > > > My preference it to opt-in supported version, not opt-out unsupported > versions. So I'd like the plugin developer to try a plugin on a > Geronimo version and if it works, list that version as supported. The > alternative will most likely lead to Geronimo being willing to install > a plugin but the plugin not working. If we get fancier version > dependencies we can consider things like "1.1.*" but I'm not sure I > like that. I'm willing to be convinced, but I'd want to hear from > more plugin developers/maintainers. > > Thanks, >Aaron > > smime.p7s Description: S/MIME Cryptographic Signature
[jira] Created: (GERONIMO-2099) Source for Console Oracle XA plugin
Source for Console Oracle XA plugin --- Key: GERONIMO-2099 URL: http://issues.apache.org/jira/browse/GERONIMO-2099 Project: Geronimo Type: New Feature Security: public (Regular issues) Components: Plugins Versions: 1.1 Reporter: Aaron Mulder Here's the code used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/... -- 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: Frustrations of a Release Manager
Sigh! :( Looks like all efforts are down the drain. On 6/9/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: I don't see what's wrong with a group of folks interested in Gernoimo getting together to talk about Geronimo. So long as it's positioned as discussion not decision-making, of course -- which, as I recall, it was.
Sandbox ACL question
Can we modify the Sandbox ACL so people in the contributors group can have svn write authority? It seems that allowing contributors into the sandbox would be a great way for us to provide more complex patches and enhancements while proving our worth towards becoming a committer -Donald smime.p7s Description: S/MIME Cryptographic Signature
Oracle XA Driver in Console (via Plugin)
Here's an attempt to do two things: - demonstrate plugins in action - provide easier access to the Oracle XA driver This will only work on 1.1, specifically http://people.apache.org/dist/geronimo/unstable/1.1-412854 or a future 1.1 build, and you'll need the full J2EE distribution because Little G does not include the console. If you install the plugin called "Oracle XA Driver for Console (Jetty/Tomcat)" then you'll get an Oracle XA (Test) entry in the console database pool database list. You'll also need to put an Oracle JDBC driver into the Geronimo repository (e.g. Oracle JDBC 9.0.5 for Java 1.4), since we can't redistribute the Oracle JDBC drivers, but the plugin will install the TranQL connector for you and make the configuration screen available. There's still the issue that the TranQL Oracle XA connector RAR does not include any documentation on the settings it uses, and there are a lot of them, so I'm not sure how you'll need to configure it, but hopefully someone here knows. :) Thanks, Aaron
Re: Anschluss - CORBA specs new home
Good point. Maybe we should wait till we graduate. Who knows, Yoko could be a TLP as well. Regards, Alan John Sisson wrote: Don't they have to have "incubator" as part of the file names and then when they exit the incubator they can remove "incubator" from the name. Sounds like it may create extra work changing Geronimo POMs to point to the correct files at different stages. Are the groupIDs changing too? John Dain Sundstrom wrote: Projects in the incubator can do releases. They do have a restriction until the IP is cleared, but once that is done they can release using the normal release process. -dain On Jun 5, 2006, at 6:29 PM, Matt Hogstrom wrote: I'm ok with it but would prefer to turn them over after Yoko graduates. My understanding is that an incubator project can't release anything. I expect they don't change a whole lot but that would be my only reservation. Alan D. Cabrera wrote: I think that it's time that we, Yoko, take responsibility for the CORBA spec jars. After Geronimo releases v1.1, let's plan on moving them over to Yoko. Thoughts? Regards, Alan
Re: Frustrations of a Release Manager
On 6/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Aaron, Since you asked. First, Can you respond below if you will allow anyone that you have sent a private e-mail to to cut and paste the contents of those messages into other posts on this thread. I think that will help. Sure. Second, the geronimoplugins.com which was injected into Geronimo is probably a good place to start. Here is a snip from whois of that domain. I removed the address specific information. Registrant: Address is provided *Removed* Domain Name: GERONIMOPLUGINS.COM Created on: 11-Apr-06 Expires on: 11-Apr-07 Last Updated on: 11-Apr-06 Administrative Contact: Mulder, Erin [EMAIL PROTECTED] Technical Contact: Mulder, Erin [EMAIL PROTECTED] Yes, of course, that's a domain we got, because the project needs one, and it can't be at Apache (due to the LGPL issue). I've offered a number of times to give people accounts to help manage the site, and so far, no one's taken me up on it. My goals are to provide a Maven repository (=HTTP site) that can hold *all* plugins, ASF, LGPL, GPL, proprietary. Since I didn't see one out there, Erin was gracious enoguh to provide one. And now you're jumping on her for it? That's gratitude! Also, recall that the file defining the available plugin repositories is hosted by the ASF, so the ASF can change the list of available sites away from geronimoplugins.com at any time. What is your counter-proposal? Next we can discuss the hijacking of JIRA for your own purposes. I was working to release 1.1 and you moved over 80 other JIRAs into the release. I don't think that we agreed on how to handle JIRAs but I think it was bad form to assume it was your prioritization mechanism since you were not releasing 1.1. Gosh, I didn't really think I was hijacking Jira. I thought I was using it for its intended purpose, which is to say, tracking the issues with the project, what should be worked on, and who was willing to work on what. Including, of course, a todo list for myself. I honestly had no idea that as release manager, you considered Jira to be your domain, and didn't want people using without what -- your approval? By all means, if you object to something I do like that, please say something! "Aaron, I'm trying to use Jira to track the tasks for 1.1, please don't put anything in there unless it's *definitely* going to happen in the next 2 weeks" or whatever. I don't remember having those discussions until well after the fact. We also discussed how to use JIRA more effectively and you post was all about what YOU wanted which may be unfair to post as you were presenting your opinion but the term I was introduced several times. I can find the post but I suspect its in most people's archives. Yes of course. I was explaining how I want to use an issue-tracking system. (Were your posts about how Jeff wants to use an issue tracking system?) I thought the point of the thread was for everyone to say what they're looking for so we can then decide the best way to do it as a group. Shall we begin to discuss the meeting at Java One that you proposed that specifically excluded members of the community. I'd be happy to bring that discussion to the list if you like. Given that IBM paid for the room that the discussion occurred in we are somewhat culpable but given that you were the master mind behind the exclusionary wall I'm happy to have that discussion in the open as well. Well, actually, it was kind of a joint idea between myself and a few other people who thought there were some things we ought to talk about so long as we were all together. I'm sorry that there's a perception of an exclusionary wall. It was on us to pay for the food, which at hotel rates was $100 per person for the day, so naturally I wasn't able to invite the entire Geronimo community. I apologize to everyone in the community who wasn't able to be at JavaOne or who wasn't invited, but it seemed like an ideal scenario for many of us to get together and discuss some of the current issues and then take the discussion points to the mailing list. If you objected, why am I first hearing about it now? And anyway, what is the perception of the "right" thing to do? If it's not economically feasible for every user, contributor, committer, and PMC member to get together does that mean no meeting should happen? If so, will IBM immediately cease having any meetings or phone calls discussing Geronimo issues? Or are you going to provide an international dial-in for every one, and hold them in the middle of the night for the convenience of the Asian community? I don't see what's wrong with a group of folks interested in Gernoimo getting together to talk about Geronimo. So long as it's positioned as discussion not decision-making, of course -- which, as I recall, it was. In the end all I need is a simple e-mail from you to this list allowing folks to p
[jira] Updated: (GERONIMO-2098) Application migration to Maven 2: remote-deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2098?page=all ] Prasad Kashyap updated GERONIMO-2098: - Attachment: remote-deploy-v2.patch Instriuctions: - 1. svn mv geronimo\applications\remote-deploy-lib\src\java\org\apache\geronimo\deployment\remote\*.java geronimo\applications\remote-deploy\src\java\org\apache\geronimo\deployment\remote 2. svn rm geronimo\applications\remote-deploy-lib 3. apply patch remote-deploy-v2.patch from geronimo dir. > Application migration to Maven 2: remote-deploy > --- > > Key: GERONIMO-2098 > URL: http://issues.apache.org/jira/browse/GERONIMO-2098 > Project: Geronimo > Type: Sub-task > Security: public(Regular issues) > Components: application client > Versions: 1.2 > Reporter: Prasad Kashyap > Assignee: David Jencks > Fix For: 1.2 > Attachments: remote-deploy-v2.patch, remote-deploy.patch > > Merge remote-deploy-lib with remote-deploy > Migrate remote-deploy to M2. -- 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] : Migrate remote-deploy to m2
I don't think this is quite ready for a vote yet, and I'm not convinced it requires a vote. First, it really should include more of a description of what the purpose of the change is, such as: "Due to bugs in the web app classloader in 1.0, the remote deploy war was split into 2 modules. Since that classloader bug has been resolved in 1.1 it's time to merge this stuff back into one module" Second, when a patch moves a file, it should not be applied as a patch. The patch might be OK to look at, but we have to preserve svn history, so whoever is going to "apply the patch" needs to know the svn commands that resulted in the patch. Here we need something like "Run these svn commands: svn mv modules/remote-deploy-lib/src/java/..java modules/remote- deploy/src/java/ ... svn rm modules/remote-deploy-lib " Other adjustments to make the build work again should be in a patch that does not include the effects of the svn commands. Thirdly I don't think this patch fixes the m1 build unfortunately we can't throw it out yet. The reason I don't think this requires a vote is that it does not change any java code and is part of the bug fix to the web app classloading. However I think since you proposed a vote and we haven't had much practice voting yet it would be a good idea to go through the vote process on this small uncontroversial change. Many thanks david jencks On Jun 9, 2006, at 9:23 AM, Prasad Kashyap wrote: Merged remote-deploy-lib with remote-deploy. Migrated remote-deploy to M2. http://issues.apache.org/jira/browse/GERONIMO-2098
Re: Frustrations of a Release Manager
I like that model too, as long as we can still deliver more than one release a year and we allow more people to have commit access to the sandbox area for more collaboration on major enhancements and changes... -Donald Jason Dillon wrote: I think SuSE-like would be a good idea too. --jason -Original Message- From: "Aaron Mulder" <[EMAIL PROTECTED]> Date: Fri, 9 Jun 2006 09:34:39 To:dev@geronimo.apache.org Subject: Re: Frustrations of a Release Manager In the spirit of greater openness and communication, please elaborate on 'thing have been "quietly" injected into Geronimo'. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Bruce Snyder wrote: On 6/8/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: I think it will help to have the schedule of the release. No one can claim IBM has a secret agenda if the time line is laid out there. And it's easy to wink if no one has any idea what the deadlines we're working toward are. I agree with Aaron here - publicity of not only the timeline (i.e., a calendar of release schedules maybe) but also the Road Map may help on all fronts. IMO we should consider publishing and continually revisiting both of these items. I know that this won't be a popular suggestion on the committer side of things because we are a volunteer organization, but it would most certainly help our user community immensely. I have to disagree here. Although I absolutely agree a roadmap is helpful and trackable, the timeline and release issues that Matt has talked about is clearly an issue. On these lists, Matt has made things extremely clear regarding when our releases should be, along with group consensus, and thing have been "quietly" injected into Geronimo. I share Matt's feelings and frustrations. Minimally, if we cannot hold to a simple date based on agreement on these lists, a roadmap, although helpful, will surely not be a panacea. It is also my hope that there are not private emails going around talking about "secret" agendas. This would dismay me as I fully expect that we are all adult enough to share our feelings with each other in these lists. If an email like this is being passed around, then we clearly need to be working on our communication skills and have a long way to go on learning to work with each other as a team. I think communication is the primary thing we need to deal with. Jeff A wiki page of the Road Map along with a rough timeline would be a good start. I also think that tying the Road Map to a timeline will cause people to more closely examine the time a particular feature might require. But like the Linux kernel release schedule, determining any kind of regular release schedule may prove to be quite difficult. But IMO it can't hurt to have goals. Just my $0.02. Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Daily post of IRC log to dev?
If you want to start a new list, that would be cool. I would prefer not to have the posting on the dev list. Regards, Alan Jason Dillon wrote: So far I have not had time to look into this further. I personally want to get a daily email, so when I have time I will set this up. At that time we can discus having it also go to the dev list or not. No worries about tardy replies :-) --jason -Original Message- From: "Alan D. Cabrera" <[EMAIL PROTECTED]> Date: Thu, 08 Jun 2006 11:01:57 To:dev@geronimo.apache.org Subject: Re: Daily post of IRC log to dev? Sorry about the tardy reply. I do not think that this is a good idea. It's just noise and I think that people should give appropriate summaries as to what was discussed. Having IRC logs posted to this group is like listening to a recording of a crowded rook w/ multiple conversations going on at the same time. Regards, Alan Jason Dillon wrote: Okay, well so far no one objected... so I am going to look into how we can get this setup. --jason On 5/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Since Apache tends to prefer mailing lists... but IRC is so convent for effective communication. Maybe we should have a daily post of the last days IRC log to the dev list. That was the list can still be used for oversight of stuff that goes on in #geronimo that may have some impact on the project and its health. Just a thought... --jason
Re: 1.1 Release plan
I agree that setting the Specs version to 1.2 for the Geronimo 1.1 release would be more confusing than the current mix of 1.0/1.0.1/1.1. It seems that we have 2 options: Option #1 - 1) Create a specs/branches/1.1 from the current tags/1_1 2) Merge the updates from Trunk to add the LICENSE and NOTICES files in 3) Do not update any of the versions (keep the 1.0/1.0.1/1.1 mix) 4) Delete and recreate the 1.1 tag 5) Build and publish the Specs with their current versions to the repos Option#2 - Only #3 differs - Update ALL versions to 1.1 Given the past history of creating/deleting and recreating the 1.0 tag for Geronimo, why could we not do that again for the Specs? Given the potential dependency version impacts to other projects (like OpenEJB, TranQL, Daytrader) that could delay the 1.1 release even longer, I would offer a non-binding vote for #1 and leave the whole "mixed versions or not" discussion up to a separate thread and vote. -Donald John Sisson wrote: Matt Hogstrom wrote: Final Items for 1.1 I would like to release Geronimo 1.1 on June 12th. Yes, that is three days away. If we can't make that date then it will be 72 hours away from each candidate build. Problem that are found need to be addressed if they are deemed critical. Otherwise they will be tracked and solved in a follow on release. Unfortunately I will be off-line for the next three days. Not everybody has every weekend free, so how about another 3 days so everyone has plenty of notice and there will be less chance of complaints. The only thing that I had outstanding was changes to the scripts (GERONIMO-1638) as discussed at http://www.mail-archive.com/dev@geronimo.apache.org/msg22807.html . Have made changes (not committed) but they need to be tested on windows, cygwin and unix, so with my time constraints it looks like this is going to be for 1.1.1 . Probably need something in the release notes saying that use of the GERONIMO_BASE environment variables probably won't work and the new org.apache.geronimo.server.dir and org.apache.geronimo.server.name system properties are subject to change as they are experimental. It would have been nice if I had a few more days to test and the effectiveness of having a release candidate has already been proven.. Maybe we should be giving the users a bit more time to test.. That said. I sent a note earlier today announcing the freeze to branches/1.1. Changes to this branch should be limited to bug fixes only. The little changes are the ones that generally burn you. At 1400 ET the Inn is closed and I will spin up a release that will be our release candidate. The issues that have been raised from the previous build were Guillaume's observation of the problem when running Geronimo under CygWin as well as the license and Notice issues. Since Geronimo is a multifaceted project there are several things that need to be voted on. They are Geronimo itself, the specification jars and DayTrader. Geronimo itself is the significant component that will carry the other items so I believe a vote for Geronimo in this context is a vote for all three items. *There is a concern about the specification jars* David Jencks raised this issue in another note on the list. The jars have not been released but they have had a tag cut and the resulting compilation has been placed on http://people.apache.org/repository. One of the issues I found with the spec is that there are different spec releases in the 1_1 tag. I would prefer that all jars have the same version suffix. Right now it includes 1.0, 1.0.1, 1.1 and others. I think this is confusing. We release Geronimo with all the same module versions even if nothing has changed. I would like to move that we recut a 1_2 tag with all spec jars having a 1.2 suffix. In theory the version suffix should match up with the JIRA records for it, but it seems we don't have a separate JIRA project set up for specs, but having a 1.2 suffix seems just as confusing to me since the specs from a JIRA perspective are managed as part of Geronimo's JIRA and we are releasing 1.1. *DayTrader* Day Trader is currently a 1.1-SNAPSHOT as well. We will release the DayTrader Ear (separate from Geronimo) as a 1.1 version as well. This way the build will be in sync. *Issues* 1. It was noted earlier today that there is a problem with Geronimo under CygWin. Guillaume noted that an issue exists where a file is not renamed (config.xml). Given that CygWin is a hybrid environment I think we should investigate this problem but not hold up the release. I could reproduce the problem and fixed it. See GERONIMO-2095. 2. Guillaume also pointed out the lack of a License and Notices file. I will include the two files from the SVN geronimo/branches/1.1 in the build tomorrow. 3. Numerous bug fixes are being addressed. Excellent. Apart from Spec issue above I think we have most everything addressed. Does thi
Re: Daily post of IRC log to dev?
So far I have not had time to look into this further. I personally want to get a daily email, so when I have time I will set this up. At that time we can discus having it also go to the dev list or not. No worries about tardy replies :-) --jason -Original Message- From: "Alan D. Cabrera" <[EMAIL PROTECTED]> Date: Thu, 08 Jun 2006 11:01:57 To:dev@geronimo.apache.org Subject: Re: Daily post of IRC log to dev? Sorry about the tardy reply. I do not think that this is a good idea. It's just noise and I think that people should give appropriate summaries as to what was discussed. Having IRC logs posted to this group is like listening to a recording of a crowded rook w/ multiple conversations going on at the same time. Regards, Alan Jason Dillon wrote: > Okay, well so far no one objected... so I am going to look into how we > can get this setup. > > --jason > > > On 5/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> Since Apache tends to prefer mailing lists... but IRC is so convent >> for effective communication. Maybe we should have a daily post of the >> last days IRC log to the dev list. That was the list can still be >> used for oversight of stuff that goes on in #geronimo that may have >> some impact on the project and its health. >> >> Just a thought... >> >> --jason >>
Re: DayTrader: Dynamic Ajax-based Web frontend --- update
Cool. :-) --jason -Original Message- From: "J. Stan Cox" <[EMAIL PROTECTED]> Date: Thu, 08 Jun 2006 14:14:22 To:dev@geronimo.apache.org Subject: DayTrader: Dynamic Ajax-based Web frontend --- update Hey, I just wanted to send a quick follow up on previous note I sent out about adding a dynamic "Web 2.0" interface to DayTrader. Progress has been slow due to other emergencies, but I should have some demo-able code to offer within a couple of weeks. The "stock trading" theme of DayTrader is perfect for a rich, asynchronous, AJAX based front end. The idea got good support before and I think this will add alot to Geronimo as a sample application. I'm specifically interested in doing some performance analysis to compare the overhead of "Web 2.0" over standard request/response style. The original note with the basic design is below. Again, I hope to have some code soon. Stan. J. Stan Cox [EMAIL PROTECTED] Original note: -- Geronimos, I'm one of the original developers of the benchmark "Trade" that has been donated to Geronimo and is now known as "DayTrader". It's amazing what this benchmark has been able to achieve over the last few years and we are very much looking forward to seeing it grow and flourish in the Open Source Geronimo environment. We think it can become a real showcase for Geronimo's performance and capabilities. We are interested in adding a rich, AJAX based Web interface for the DayTrader stock trading services. DayTrader is a perfect type of application to leverage AJAX capablities. We plan to collapse all of the current web pages into a single rich page with dynamic and asynchronous updates of stock prices, user holdings, buys/sells, etc. We would leverage the DoJo AJAX toolkit which is being pulled into Apache MyFaces. So, the basic architecture would look like: browser<--- REST---> DayTrader---SOAP---> DayTrader--- Java---> DayTrader (dojo libs, proxy servlet Web services J2EE App javascript) soap/rest transform |--GERONIMO ---| Stan. J. Stan Cox [EMAIL PROTECTED]
Re: Frustrations of a Release Manager
Aaron, Since you asked. First, Can you respond below if you will allow anyone that you have sent a private e-mail to to cut and paste the contents of those messages into other posts on this thread. I think that will help. Second, the geronimoplugins.com which was injected into Geronimo is probably a good place to start. Here is a snip from whois of that domain. I removed the address specific information. Registrant: Address is provided *Removed* Domain Name: GERONIMOPLUGINS.COM Created on: 11-Apr-06 Expires on: 11-Apr-07 Last Updated on: 11-Apr-06 Administrative Contact: Mulder, Erin [EMAIL PROTECTED] Technical Contact: Mulder, Erin [EMAIL PROTECTED] Next we can discuss the hijacking of JIRA for your own purposes. I was working to release 1.1 and you moved over 80 other JIRAs into the release. I don't think that we agreed on how to handle JIRAs but I think it was bad form to assume it was your prioritization mechanism since you were not releasing 1.1. We also discussed how to use JIRA more effectively and you post was all about what YOU wanted which may be unfair to post as you were presenting your opinion but the term I was introduced several times. I can find the post but I suspect its in most people's archives. Shall we begin to discuss the meeting at Java One that you proposed that specifically excluded members of the community. I'd be happy to bring that discussion to the list if you like. Given that IBM paid for the room that the discussion occurred in we are somewhat culpable but given that you were the master mind behind the exclusionary wall I'm happy to have that discussion in the open as well. In the end all I need is a simple e-mail from you to this list allowing folks to paste their private notes from you and we can have it all in the open which was your request. I'm happy to oblige. Bring it on. Matt Aaron Mulder wrote: In the spirit of greater openness and communication, please elaborate on 'thing have been "quietly" injected into Geronimo'. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Bruce Snyder wrote: > On 6/8/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > >> I think it will help to have the schedule of the release. No one can >> claim IBM has a secret agenda if the time line is laid out there. And >> it's easy to wink if no one has any idea what the deadlines we're >> working toward are. > > I agree with Aaron here - publicity of not only the timeline (i.e., a > calendar of release schedules maybe) but also the Road Map may help on > all fronts. IMO we should consider publishing and continually > revisiting both of these items. I know that this won't be a popular > suggestion on the committer side of things because we are a volunteer > organization, but it would most certainly help our user community > immensely. I have to disagree here. Although I absolutely agree a roadmap is helpful and trackable, the timeline and release issues that Matt has talked about is clearly an issue. On these lists, Matt
Re: JIRA project for GShell?
Jason Dillon wrote: Can we create a new JIRA project for GShell? I've got a bunch of task/todo items that I would like to track in JIRA so it is easier to prioritize and plan. Thoughts? --jason IMO, if it gets out of the sandbox, it deserves a Jira project. Regards, Alan
Re: Geronimo doesn't startup if restart it using another JDK
Using the ADLER-32 makes much more sence than a hash code. --jason -Original Message- From: "Udovichenko, Nellya" <[EMAIL PROTECTED]> Date: Fri, 9 Jun 2006 14:32:43 To: Subject: Geronimo doesn't startup if restart it using another JDK Hello, I have launched Geronimo on Sun JDK. Then I’ve tried to run it with Harmony class library and IBM VM j9. I’ve got the error log below. Also I’ve got the same result when launched Geronimo on Harmony and then - on Sun JDK.š There is a bug in HOWL repaired in howl-1.0.1 by the new parameter (adler32Checksum) adding. At Geronimo startup it checks the log files' validity if they exist. One of verified parameters is the file content control sum. One value of this sum is read from file header and another is calculated by function java.nio.ByteBuffer.hashCode(). So if the algorithms of hash code functions of the JDKs are different Geronimo doesn’t startup. If the parameter adler32Checksum value is false the control sum is calculated by function java.nio.ByteBuffer.hashCode() otherwise it is calculated using ADLER-32 algorithm. Therefore, I think, it would be correct to add this parameter to configs/j2ee-server/src/plan/plan.xml and to gbean org.apache.geronimo.transaction.log.HOWLLog with value 'true'.š Any thoughts? š Thanks, Nellya Udovichenko, Intel Middleware Products Division Error log: $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.4.2_01)... Starting Geronimo Application Server v1.1-20060607 [**> ] 11%šš 6s Starting geronimo/j2ee-server/1...14:23:30,3 19 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED s tate: abstractName="geronimo/j2ee-server/1.1-20060607/car?ServiceModule=geronimo /j2ee-server/1.1-20060607/car,j2eeType=TransactionLog,name=HOWLTransactionLog" org.objectweb.howl.log.InvalidLogBufferException: CHECKSUM Class: org.objectweb.howl.log.BlockLogBuffer š workerID: š LogFile: C:\Nellya\geronimo-1.1\var\txlog\howl_1.log š HEADER ššš HEADER_ID: 0x484f574c ššš bsn: 0x1 ššš size: 0x8000š should be: 0x8000 ššš data used: 0x4f ššš checkSum: 0x2227d ššš tod: 0x10bb850e3b1 ššš crlf: 0xd0a š FOOTER ššš FOOTER_ID: 0x4c574f48 ššš bsn: 0x1 ššš tod: 0x10bb850e3b1 ššš crlf: 0xd0a ššš at org.objectweb.howl.log.BlockLogBuffer.read(BlockLogBuffer.java:460) ššš at org.objectweb.howl.log.LogFileManager.init(LogFileManager.java:821) ššš at org.objectweb.howl.log.Logger.open(Logger.java:314) ššš at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:893) ššš at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:217) ššš at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:981) ššš at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:267) ššš at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) ššš at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j ava:526) ššš at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) ššš at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) ššš at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe ndency.java:120) ššš at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:173) ššš at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:41) ššš at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) ššš at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:292) ššš at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) ššš at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) ššš at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:540) ššš at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) ššš at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:374) ššš at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) ššš at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:512) ššš at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:493) ššš at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastCla ssByCG
Re: Frustrations of a Release Manager
I think SuSE-like would be a good idea too. --jason -Original Message- From: "Aaron Mulder" <[EMAIL PROTECTED]> Date: Fri, 9 Jun 2006 09:34:39 To:dev@geronimo.apache.org Subject: Re: Frustrations of a Release Manager In the spirit of greater openness and communication, please elaborate on 'thing have been "quietly" injected into Geronimo'. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > > > Bruce Snyder wrote: > > On 6/8/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > > > >> I think it will help to have the schedule of the release. No one can > >> claim IBM has a secret agenda if the time line is laid out there. And > >> it's easy to wink if no one has any idea what the deadlines we're > >> working toward are. > > > > I agree with Aaron here - publicity of not only the timeline (i.e., a > > calendar of release schedules maybe) but also the Road Map may help on > > all fronts. IMO we should consider publishing and continually > > revisiting both of these items. I know that this won't be a popular > > suggestion on the committer side of things because we are a volunteer > > organization, but it would most certainly help our user community > > immensely. > > I have to disagree here. Although I absolutely agree a roadmap is > helpful and trackable, the timeline and release issues that Matt has > talked about is clearly an issue. On these lists, Matt has made things > extremely clear regarding when our releases should be, along with group > consensus, and thing have been "quietly" injected into Geronimo. I > share Matt's feelings and frustrations. > > Minimally, if we cannot hold to a simple date based on agreement on > these lists, a roadmap, although helpful, will surely not be a panacea. > > It is also my hope that there are not private emails going around > talking about "secret" agendas. This would dismay me as I fully expect > that we are all adult enough to share our feelings with each other in > these lists. If an email like this is being passed around, then we > clearly need to be working on our communication skills and have a long > way to go on learning to work with each other as a team. I think > communication is the primary thing we need to deal with. > > Jeff > > > > > A wiki page of the Road Map along with a rough timeline would be a > > good start. I also think that tying the Road Map to a timeline will > > cause people to more closely examine the time a particular feature > > might require. But like the Linux kernel release schedule, determining > > any kind of regular release schedule may prove to be quite difficult. > > But IMO it can't hurt to have goals. > > > > Just my $0.02. > > > > Bruce >
[RTC] : Migrate remote-deploy to m2
Merged remote-deploy-lib with remote-deploy. Migrated remote-deploy to M2. http://issues.apache.org/jira/browse/GERONIMO-2098
[jira] Assigned: (GERONIMO-2098) Application migration to Maven 2: remote-deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2098?page=all ] Prasad Kashyap reassigned GERONIMO-2098: Assign To: David Jencks > Application migration to Maven 2: remote-deploy > --- > > Key: GERONIMO-2098 > URL: http://issues.apache.org/jira/browse/GERONIMO-2098 > Project: Geronimo > Type: Sub-task > Security: public(Regular issues) > Components: application client > Versions: 1.2 > Reporter: Prasad Kashyap > Assignee: David Jencks > Fix For: 1.2 > Attachments: remote-deploy.patch > > Merge remote-deploy-lib with remote-deploy > Migrate remote-deploy to M2. -- 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
