Re: Weekly conference call - thoughts
On Oct 28, 2005, at 1:29 PM, Rodent of Unusual Size wrote: Matt Hogstrom wrote: I was thinking that it might be worthwhile to have a regular weekly conference call for those on the dev list. It would not be mandatory at all but we could all put it on our calendars and use it as a time to talk over issues rather than rely totally on e-mail. We'd get someone to take notes and post them to the dev list and solicit agenda items from there as well. A very strong -1. This discriminates against and disenfranchises those who can't make it for whatever reason, not least those in timezones far removed from the majority. And it leaves no trace other than hearsay. IRC is frowned upon as a formal discussion mechanism for the same reason, although it's easier to log. Nevertheless, discussions about development are supposed to happen in the wide-open, where other developers *and non-developers* can see them now and in the future. I.e., email. This has come up repeatedly in the last several years, and the conclusion has always been the same: the convenience of the few never dominates the visibility to the many. There are exceptional circumstances, such as the ApacheCon hackathons, but they a infrequent and the attendees are typically expected to recap any proposals in front of the mailing list before anything happens. As an occasional way to get through a lot quickly it's acceptable; as an institutionalised medium, -1. Seems fair, IMHO. Not a real big fan of being on con-calls any kind, so I'm biased If we had two or three (with minutes posted to dev@) in the weeks leading up to the big 1.0 we want to get out by ApacheCon and didn't use that crutch again for a long while, certainly not as a regular release practice, would that kind of fit the pragmatic profile? If not, I'm happy to let it drop. -David
Re: Wiki reorganization proposal
me too. what camera? On Oct 28, 2005, at 6:47 PM, Dain Sundstrom wrote: On Oct 28, 2005, at 3:41 PM, Geir Magnusson Jr. wrote: Don't let us stand in your way... looks good to me... My only comment after a quick read through is to put the stuff to help people get started right at the top. Sorta like when you get a camera or something it has a 1 page "Instructions for the Impatient" or something. Big +1 I just got a new camera the other day, and that was the only section I read. -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Wiki reorganization proposal
On Oct 28, 2005, at 3:41 PM, Geir Magnusson Jr. wrote: Don't let us stand in your way... looks good to me... My only comment after a quick read through is to put the stuff to help people get started right at the top. Sorta like when you get a camera or something it has a 1 page "Instructions for the Impatient" or something. Big +1 I just got a new camera the other day, and that was the only section I read. -dain
Re: Wiki reorganization proposal
Don't let us stand in your way... looks good to me... My only comment after a quick read through is to put the stuff to help people get started right at the top. Sorta like when you get a camera or something it has a 1 page "Instructions for the Impatient" or something. I'd also rather see project overview be the website. I first thought about two groupings - user/admin and developer, but it's not really clear how things would fall - ex, does app migration go to user or dev? Anyway, soemthing like Installation Administration Hints and Tips Architecture Dev ... I think what you have for each bucket is great, btw... Nice. geir On Oct 28, 2005, at 5:52 PM, Hernan Cunico wrote: Hi All, Independently of whether we will ever move wiki to confluence or not (there is a lot of discussion on this) still the Apache wiki needs some serious reorganization today. I think it should be restructured into something easier to browse, making a stronger focus on the Geronimo documentation. We could have sections at the bottom (sort of Appendixes) for all non- documentation related topics (people, contests, etc). This is the content as it is today: About Logo Contest Downloads Documentation Mailing Lists Issue Tracking Related Sites Project Status & Management Developer Information ObjectWeb Collaboration People Wiki Sand Box Most of this information is either redundant on the geronimo.apache.org front page or not relevant (like "Related sites"). My suggestion is to provide a logical flow, from "the generic" to "the specific". Start with a "Project overview", then go with the "Geronimo architecture" and continue with a breakdown of that architecture, ... The structure I propose may look like a TOC for a book but, dreaming about a perfect world, it would be great if Geronimo can have a sound starting point for our documentation. I see other wiki- like sites and are a lot more organized. Here is my proposed content for the wiki: - Apache Geronimo project overview - About ASF - Licensing - Architecture - GBeans - Geronimo kernel - Naming - Tomcat - Jetty - Derby - Axis - TranQL - OpenEJB - MX4J - ActiveMQ - ApacheDS - ... - Installation - Platforms supported - Hardware and software prerequisites - Getting the source code - Build from the source - Installation - Administration - Tools start and stop services/servers, deployer.jar, etc - Geronimo Web Console - Configure resources - JavaMail - Database - ... - Logging - Backup and recovery - Maintenance - Development - Eclipse tools - Simple servlet and JSP applications - Web applications - EJB applications - Security applications - Web services applications - Client applications - ... - Deployment - Deployer tool - Deployment plans - Deploying applications - Deploying configurations/resources - Security - Implementation overview - Authentication - Authorization - Security modules - Security realms - Enabling SSL - Programatic security - Enabling security for applications - LDAP - Applications migration - Performance and high availability - Scalability - Clustering - Hints and Tips - Troubleshooting - Sample applications - Other interesting resources - Wiki SandBox - People I know I'm missing a lot but still wanted to give this first step. I'm sure with a better structure we can get more people easily invovled on both, producing and consuming, documentation. Thank you all. Cheers! Hernan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Applications directory structure
Dain Sundstrom wrote:
On Oct 26, 2005, at 3:56 PM, Dave Colasurdo wrote:
There have been several previous conversations regarding the
structure of the geronimo/applications directory. It seems that there
should be some way to differentiate the various categories of
applications?
Perhaps something like:
geronimo/applications/samples/ would contain:
-demo
-servlets-examples
-jsp-examples
-magicGball
-dayTrader
-bigPetEJBSess
-petStore
Which directory do you mean?
http://svn.apache.org/repos/asf/geronimo/trunk/applications/samples
or
http://svn.apache.org/repos/asf/geronimo/applications/samples
I would prefer that the samples be outside located off of the geronimo
svn root and not in trunk. This will allow them to be developed and
released independently of the mail line server.
A few points/questions..
I suspect we will want to pull a few of the samples (servlets-examples,
jsp-examples, ejb-examples) into the generated G images (definitely into
the installer as selectable options and arguably into the zipped binary
images). This means that the main G tree will have dependencies on
things that are now outside of main trunk (geronimo/trunk). Will the
restructure somehow address getting them pulled into the main G
distributions? Does this imply that developers need to also download
the samples source when doing a build of the main trunk? Or is the
assumption that full builds require the full geronimo root checkout?
Perhaps we move a few select select samples (servlets-examples,
jsp-examples, ejb-examples)into the main trunk and leave the others
outside.
In a separate thread you suggested versioning the samples.. Are you
suggesting versioning the individual samples? Or are you saying that
the group of samples would be versioned as applicable to a specific G
release?
geronimo/applications/system would contain:
-console*
-jmxdebug
-uddi-server
-welcome
I was thinking more along the lines of
geronimo/trunk/applications/console-${part} --> geronimo/trunk/
console/${part}
geronimo/trunk/applications/welcome --> geronimo/trunk/ welcome
(not sure... is this the tomcat/jetty welcome app?)
geronimo/trunk/applications/uddi-server --> geronimo/applications/
uddi-server
geronimo/trunk/applications/jmxdebug--> geronimo/sandbox/
jmxdebug/trunk (I think this need more work or we should simply drop it)
Should we consider putting these applications under a common directory
(e.g. system) that groups them and signifies their strong ties to the G
system?
Also, the same point as above applies about the main tree build
dependency on the system applications. I see you included console and
welcome in the trunk. I suspect uddi-server and jmxdebug also belong in
trunk as they are likely part of the default binary distribution. I
did hear that the jmxdebug app is being reworked..
-dain
Wiki reorganization proposal
Hi All, Independently of whether we will ever move wiki to confluence or not (there is a lot of discussion on this) still the Apache wiki needs some serious reorganization today. I think it should be restructured into something easier to browse, making a stronger focus on the Geronimo documentation. We could have sections at the bottom (sort of Appendixes) for all non-documentation related topics (people, contests, etc). This is the content as it is today: About Logo Contest Downloads Documentation Mailing Lists Issue Tracking Related Sites Project Status & Management Developer Information ObjectWeb Collaboration People Wiki Sand Box Most of this information is either redundant on the geronimo.apache.org front page or not relevant (like "Related sites"). My suggestion is to provide a logical flow, from "the generic" to "the specific". Start with a "Project overview", then go with the "Geronimo architecture" and continue with a breakdown of that architecture, ... The structure I propose may look like a TOC for a book but, dreaming about a perfect world, it would be great if Geronimo can have a sound starting point for our documentation. I see other wiki-like sites and are a lot more organized. Here is my proposed content for the wiki: - Apache Geronimo project overview - About ASF - Licensing - Architecture - GBeans - Geronimo kernel - Naming - Tomcat - Jetty - Derby - Axis - TranQL - OpenEJB - MX4J - ActiveMQ - ApacheDS - ... - Installation - Platforms supported - Hardware and software prerequisites - Getting the source code - Build from the source - Installation - Administration - Tools start and stop services/servers, deployer.jar, etc - Geronimo Web Console - Configure resources - JavaMail - Database - ... - Logging - Backup and recovery - Maintenance - Development - Eclipse tools - Simple servlet and JSP applications - Web applications - EJB applications - Security applications - Web services applications - Client applications - ... - Deployment - Deployer tool - Deployment plans - Deploying applications - Deploying configurations/resources - Security - Implementation overview - Authentication - Authorization - Security modules - Security realms - Enabling SSL - Programatic security - Enabling security for applications - LDAP - Applications migration - Performance and high availability - Scalability - Clustering - Hints and Tips - Troubleshooting - Sample applications - Other interesting resources - Wiki SandBox - People I know I'm missing a lot but still wanted to give this first step. I'm sure with a better structure we can get more people easily invovled on both, producing and consuming, documentation. Thank you all. Cheers! Hernan
Re: Weekly conference call - thoughts
Wonder what it would take archive those calls if need be. Cheers Prasad On 10/28/05, Barry van Someren <[EMAIL PROTECTED]> wrote: Well both SIP and VOIP can call to standard numbers.Wouldn't know of a service though, sorry.I Have to agree with some opinions that calls might not be the best of mediums. Emails I can read any time of the day, to participate in a conferencecall I'd need to be home.I'm sure many others here have that problem.It might work for 1 on 1 discussions though (in which case Google talk or Skype is great)Greetings,BarryOn 10/28/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:> Skype or SIP would be very cool. Is there a conference service that > can be access directly with both Skype/SIP and plain old phone lines?>> -dain>> On Oct 28, 2005, at 1:20 PM, Barry van Someren wrote:>> > Would this be over normal phone or some kind of VOIP conference > > (Skype/SIP)?> > Sounds good, I'd just listen (and participate if I happen to be home)> >> > On 10/28/05, Aaron Mulder <[EMAIL PROTECTED] > wrote:> >> >> Sounds good to me> >>> >> Aaron> >>> >> On 10/28/05, Matt Hogstrom <[EMAIL PROTECTED] > wrote:> >>> >>> I was thinking that it might be worthwhile to have a regular> >>> weekly conference> >>> call for those on the dev list. It would not be mandatory at all > >>> but we could> >>> all put it on our calendars and use it as a time to talk over> >>> issues rather than> >>> rely totally on e-mail. We'd get someone to take notes and post > >>> them to the dev> >>> list and solicit agenda items from there as well.> >>> I'll look into how we could do this and what the cost issues> >>> are. I was > >>> thinking something like Thursdays at noon EST (most favorable to> >>> cover those> >>> that might be interested from Europe).> >>> Thoughts on the idea, frequency, etc. > >>> Cheers,> >>> Matt> >>> >>>
Re: New Solaris Zones
Great. That's two :) Once I'm in, I'll get you guys in, and we'll take it from there. geir On Oct 28, 2005, at 4:51 PM, Jeff Genender wrote: I think DB and I could help out ;-) I think we should give all committers accounts. As for sudo access, I think we should give it to a couple of committers that have a good unix background and are willing to help. I'm willing to help, but my unix skills are weak. I'm personally hoping that David Blevins (hint) and Jeff Genender volunteer (hint) as both of them have mad unix admin skills :) I think we should apply the same rules to the geronimo-tck zone except that only NDA signers would get access. -dain On Oct 28, 2005, at 12:41 PM, Geir Magnusson Jr. wrote: The solaris zones for Geronimo are being created, one for general project use and one for tck use. How shall we administer them? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: New Solaris Zones
That's one... On Oct 28, 2005, at 4:43 PM, David Blevins wrote: Happy to volunteer to admin our stuff. -David On Oct 28, 2005, at 1:34 PM, Dain Sundstrom wrote: I think we should give all committers accounts. As for sudo access, I think we should give it to a couple of committers that have a good unix background and are willing to help. I'm willing to help, but my unix skills are weak. I'm personally hoping that David Blevins (hint) and Jeff Genender volunteer (hint) as both of them have mad unix admin skills :) I think we should apply the same rules to the geronimo-tck zone except that only NDA signers would get access. -dain On Oct 28, 2005, at 12:41 PM, Geir Magnusson Jr. wrote: The solaris zones for Geronimo are being created, one for general project use and one for tck use. How shall we administer them? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: New Solaris Zones
I think DB and I could help out ;-) > I think we should give all committers accounts. As for sudo access, > I think we should give it to a couple of committers that have a good > unix background and are willing to help. I'm willing to help, but my > unix skills are weak. I'm personally hoping that David Blevins > (hint) and Jeff Genender volunteer (hint) as both of them have mad > unix admin skills :) > > I think we should apply the same rules to the geronimo-tck zone > except that only NDA signers would get access. > > -dain > > On Oct 28, 2005, at 12:41 PM, Geir Magnusson Jr. wrote: > >> The solaris zones for Geronimo are being created, one for general >> project use and one for tck use. >> >> How shall we administer them? >> >> geir >> >> -- >> Geir Magnusson Jr +1-203-665-6437 >> [EMAIL PROTECTED] >> >> >
Re: gbuild subproject?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: > +1 > > Lets figure out how to manage these distributed builds and then help > other ASF projects take advantage of it. I suggest talking with the Gump project, since they've been all about automatic and distributed and coordinated building since day one. Maybe they have some useful knowledge. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ2KODJrNPMCpn3XdAQLvbAP+MMN1AYctu5gc4AVcDbU4kb6hI4TtDhU8 YrQUVTY1c/QYX9KExQ9ZkpcrG4wmCbIcA0ujYN7F6Kk/OdHsQ4b0zbjohdWRYxUz Zi6qd9tR0m+PWdjrB9tr7lptfJxo5FmYPXxCio56Nx9THwHVJhRUdenftiHWGPft ZSwiJ2KtWvs= =KjGY -END PGP SIGNATURE-
Re: New Solaris Zones
Happy to volunteer to admin our stuff. -David On Oct 28, 2005, at 1:34 PM, Dain Sundstrom wrote: I think we should give all committers accounts. As for sudo access, I think we should give it to a couple of committers that have a good unix background and are willing to help. I'm willing to help, but my unix skills are weak. I'm personally hoping that David Blevins (hint) and Jeff Genender volunteer (hint) as both of them have mad unix admin skills :) I think we should apply the same rules to the geronimo-tck zone except that only NDA signers would get access. -dain On Oct 28, 2005, at 12:41 PM, Geir Magnusson Jr. wrote: The solaris zones for Geronimo are being created, one for general project use and one for tck use. How shall we administer them? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Weekly conference call - thoughts
Well both SIP and VOIP can call to standard numbers. Wouldn't know of a service though, sorry. I Have to agree with some opinions that calls might not be the best of mediums. Emails I can read any time of the day, to participate in a conference call I'd need to be home. I'm sure many others here have that problem. It might work for 1 on 1 discussions though (in which case Google talk or Skype is great) Greetings, Barry On 10/28/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Skype or SIP would be very cool. Is there a conference service that > can be access directly with both Skype/SIP and plain old phone lines? > > -dain > > On Oct 28, 2005, at 1:20 PM, Barry van Someren wrote: > > > Would this be over normal phone or some kind of VOIP conference > > (Skype/SIP)? > > Sounds good, I'd just listen (and participate if I happen to be home) > > > > On 10/28/05, Aaron Mulder <[EMAIL PROTECTED]> wrote: > > > >> Sounds good to me > >> > >> Aaron > >> > >> On 10/28/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >> > >>> I was thinking that it might be worthwhile to have a regular > >>> weekly conference > >>> call for those on the dev list. It would not be mandatory at all > >>> but we could > >>> all put it on our calendars and use it as a time to talk over > >>> issues rather than > >>> rely totally on e-mail. We'd get someone to take notes and post > >>> them to the dev > >>> list and solicit agenda items from there as well. > >>> > >>> I'll look into how we could do this and what the cost issues > >>> are. I was > >>> thinking something like Thursdays at noon EST (most favorable to > >>> cover those > >>> that might be interested from Europe). > >>> > >>> Thoughts on the idea, frequency, etc. > >>> > >>> Cheers, > >>> > >>> Matt > >>> > >>> > >>> > >> > > > >
Re: New Solaris Zones
I think we should give all committers accounts. As for sudo access, I think we should give it to a couple of committers that have a good unix background and are willing to help. I'm willing to help, but my unix skills are weak. I'm personally hoping that David Blevins (hint) and Jeff Genender volunteer (hint) as both of them have mad unix admin skills :) I think we should apply the same rules to the geronimo-tck zone except that only NDA signers would get access. -dain On Oct 28, 2005, at 12:41 PM, Geir Magnusson Jr. wrote: The solaris zones for Geronimo are being created, one for general project use and one for tck use. How shall we administer them? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Weekly conference call - thoughts
Skype or SIP would be very cool. Is there a conference service that can be access directly with both Skype/SIP and plain old phone lines? -dain On Oct 28, 2005, at 1:20 PM, Barry van Someren wrote: Would this be over normal phone or some kind of VOIP conference (Skype/SIP)? Sounds good, I'd just listen (and participate if I happen to be home) On 10/28/05, Aaron Mulder <[EMAIL PROTECTED]> wrote: Sounds good to me Aaron On 10/28/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I was thinking that it might be worthwhile to have a regular weekly conference call for those on the dev list. It would not be mandatory at all but we could all put it on our calendars and use it as a time to talk over issues rather than rely totally on e-mail. We'd get someone to take notes and post them to the dev list and solicit agenda items from there as well. I'll look into how we could do this and what the cost issues are. I was thinking something like Thursdays at noon EST (most favorable to cover those that might be interested from Europe). Thoughts on the idea, frequency, etc. Cheers, Matt
Re: Weekly conference call - thoughts
I worry about the same problem that we have with IRC - that while it's a very convenient way to communicate, not everyone can make it and participate in the discussion, and also despite the best of intentions, summaries result in not everything discussed making it to the "institutional memory" that is the dev@ list. It's true that e- mail is slow, but it does allow the time-shifting and "inclusivity", to coin a word... Sorry to be a wet blanket, but it's just my $0.02 geir On Oct 28, 2005, at 3:00 PM, Matt Hogstrom wrote: I was thinking that it might be worthwhile to have a regular weekly conference call for those on the dev list. It would not be mandatory at all but we could all put it on our calendars and use it as a time to talk over issues rather than rely totally on e- mail. We'd get someone to take notes and post them to the dev list and solicit agenda items from there as well. I'll look into how we could do this and what the cost issues are. I was thinking something like Thursdays at noon EST (most favorable to cover those that might be interested from Europe). Thoughts on the idea, frequency, etc. Cheers, Matt -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Weekly conference call - thoughts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote: > I was thinking that it might be worthwhile to have a regular weekly > conference call for those on the dev list. It would not be mandatory at > all but we could all put it on our calendars and use it as a time to > talk over issues rather than rely totally on e-mail. We'd get someone > to take notes and post them to the dev list and solicit agenda items > from there as well. A very strong -1. This discriminates against and disenfranchises those who can't make it for whatever reason, not least those in timezones far removed from the majority. And it leaves no trace other than hearsay. IRC is frowned upon as a formal discussion mechanism for the same reason, although it's easier to log. Nevertheless, discussions about development are supposed to happen in the wide-open, where other developers *and non-developers* can see them now and in the future. I.e., email. This has come up repeatedly in the last several years, and the conclusion has always been the same: the convenience of the few never dominates the visibility to the many. There are exceptional circumstances, such as the ApacheCon hackathons, but they a infrequent and the attendees are typically expected to recap any proposals in front of the mailing list before anything happens. As an occasional way to get through a lot quickly it's acceptable; as an institutionalised medium, -1. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ2KKGprNPMCpn3XdAQL44QQAoyv7miLoYXMlvJecEm8WJNt355wSDjW7 l5iibG0QBzGowqbyj0B0Udz0lrl7jzw6lSwf6KJn8/pf/Rt9pmSDopGD6UKR2GyS lwhh56edhvTA7qhehJtKb1vu6QrM55JStDALf8vUoaHJTmyRM1pv52igSl4Q40Ch kBw3a44gEwo= =LqS+ -END PGP SIGNATURE-
Cluster Testing
Hi, I'd like to offer resources to test clustering of Geronimo with the Tomcat web container. We have a near term need for this at an end user site. Is there code available to test and can someone provide direction on what to get and how to configure? Michael Malgeri Mgr Gluecode Client Technical Services CELLULAR: 310-704-6403
Re: Weekly conference call - thoughts
Would this be over normal phone or some kind of VOIP conference (Skype/SIP)? Sounds good, I'd just listen (and participate if I happen to be home) On 10/28/05, Aaron Mulder <[EMAIL PROTECTED]> wrote: > Sounds good to me > > Aaron > > On 10/28/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > > I was thinking that it might be worthwhile to have a regular weekly > > conference > > call for those on the dev list. It would not be mandatory at all but we > > could > > all put it on our calendars and use it as a time to talk over issues rather > > than > > rely totally on e-mail. We'd get someone to take notes and post them to > > the dev > > list and solicit agenda items from there as well. > > > > I'll look into how we could do this and what the cost issues are. I was > > thinking something like Thursdays at noon EST (most favorable to cover those > > that might be interested from Europe). > > > > Thoughts on the idea, frequency, etc. > > > > Cheers, > > > > Matt > > > > >
Re: Trunk Cleanup?
I don't have any objection to this, but changing the SVN layout diesn't really excite me either. Whatever layout "others" prefer is fine and I can work with it. That said, it wouldn't break my heart to reduce the amount of stuff in our main IntelliJ project. :) Aaron On 10/28/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > I sent this proposal a while back and simply forgot about it until > Alan started working on the specs cleanup. I think the problem was I > presented it as one huge change, so this time I'm going to try to > break it up into tasks I can put into JIRA once approved. > > In general the overall structure would be: > > geronimo/trunk - Stuff needed for the J2EE server > geronimo/specs/trunk - Specification API implementations > geronimo/trunk/console - The J2ee web admin console > geronimo/examples/*/trunk - Example apps for new users (do we want to > version these?) > geronimo/applications/*/trunk - Standalone applications such as > dayTrader and uddi-server > geronimo/sandbox/*/ - Play area > geronimo/contrib/*/ - Tags of the initial import from a donation > > * Note the last two don't need to be versioned > > What do you think? > > -dain > > Sandbox > --- > I think this should be moved to the root of the tree and be a place > where any committer can play or experiment freely. The contrib > directory in the sandbox seems like it was created as an initial home > for the initial import new contributions (i.e., a tag of the initial > import). I like this idea and think we should move contrib to root > and attempt to back fill the big initial imports like the console and > the eclipse plugin. The other sandbox directory I have questions on > it petstore. If it works, I think we should move it to an examples > directory off of root. > geronimo/trunk/sandbox --> geronimo/sandbox > geronimo/trunk/sandbox/contrib --> geronimo/contrib > geronimo/trunk/sandbox/mail --> geronimo/sandbox/mail > geronimo/trunk/sandbox/petstore --> geronimo/examples/petstore > geronimo/trunk/sandbox/spring-assembly --> geronimo/sandbox/spring- > assembly > geronimo/trunk/applications/jmxdebug--> geronimo/sandbox/ > jmxdebug (I think this need more work or we should simply drop it) > > > Console > --- > Aaron correct me if I'm wrong... I assume that the console is tied to > the version of the Geronimo server it is included with, so it would > be unreasonable to ship it separately. Therefore, I think we should > make move it to the root of trunk > geronimo/trunk/applications/console-core --> geronimo/trunk/ > console/core > geronimo/trunk/applications/console-ear--> geronimo/trunk/ > console/ear > geronimo/trunk/applications/console-framework --> geronimo/trunk/ > console/framework > geronimo/trunk/applications/console-standard --> geronimo/trunk/ > console/standard > > > Specs > - > Alan is on this one > > > Applications > > There is another thread on this, "Applications directory structure", > started by Dave Colasurdo. Whatever comes out of that would be this > task. > > >
Re: Weekly conference call - thoughts
Sounds good to me Aaron On 10/28/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > I was thinking that it might be worthwhile to have a regular weekly conference > call for those on the dev list. It would not be mandatory at all but we could > all put it on our calendars and use it as a time to talk over issues rather > than > rely totally on e-mail. We'd get someone to take notes and post them to the > dev > list and solicit agenda items from there as well. > > I'll look into how we could do this and what the cost issues are. I was > thinking something like Thursdays at noon EST (most favorable to cover those > that might be interested from Europe). > > Thoughts on the idea, frequency, etc. > > Cheers, > > Matt > >
Re: Applications directory structure
On Oct 26, 2005, at 3:56 PM, Dave Colasurdo wrote:
There have been several previous conversations regarding the
structure of the geronimo/applications directory. It seems that
there should be some way to differentiate the various categories of
applications?
Perhaps something like:
geronimo/applications/samples/ would contain:
-demo
-servlets-examples
-jsp-examples
-magicGball
-dayTrader
-bigPetEJBSess
-petStore
Which directory do you mean?
http://svn.apache.org/repos/asf/geronimo/trunk/applications/samples
or
http://svn.apache.org/repos/asf/geronimo/applications/samples
I would prefer that the samples be outside located off of the
geronimo svn root and not in trunk. This will allow them to be
developed and released independently of the mail line server.
geronimo/applications/system would contain:
-console*
-jmxdebug
-uddi-server
-welcome
I was thinking more along the lines of
geronimo/trunk/applications/console-${part} --> geronimo/trunk/
console/${part}
geronimo/trunk/applications/welcome --> geronimo/trunk/
welcome (not sure... is this the tomcat/jetty welcome app?)
geronimo/trunk/applications/uddi-server --> geronimo/applications/
uddi-server
geronimo/trunk/applications/jmxdebug--> geronimo/sandbox/
jmxdebug/trunk (I think this need more work or we should simply drop
it)
-dain
Trunk Cleanup?
I sent this proposal a while back and simply forgot about it until Alan started working on the specs cleanup. I think the problem was I presented it as one huge change, so this time I'm going to try to break it up into tasks I can put into JIRA once approved. In general the overall structure would be: geronimo/trunk - Stuff needed for the J2EE server geronimo/specs/trunk - Specification API implementations geronimo/trunk/console - The J2ee web admin console geronimo/examples/*/trunk - Example apps for new users (do we want to version these?) geronimo/applications/*/trunk - Standalone applications such as dayTrader and uddi-server geronimo/sandbox/*/ - Play area geronimo/contrib/*/ - Tags of the initial import from a donation * Note the last two don't need to be versioned What do you think? -dain Sandbox --- I think this should be moved to the root of the tree and be a place where any committer can play or experiment freely. The contrib directory in the sandbox seems like it was created as an initial home for the initial import new contributions (i.e., a tag of the initial import). I like this idea and think we should move contrib to root and attempt to back fill the big initial imports like the console and the eclipse plugin. The other sandbox directory I have questions on it petstore. If it works, I think we should move it to an examples directory off of root. geronimo/trunk/sandbox --> geronimo/sandbox geronimo/trunk/sandbox/contrib --> geronimo/contrib geronimo/trunk/sandbox/mail --> geronimo/sandbox/mail geronimo/trunk/sandbox/petstore --> geronimo/examples/petstore geronimo/trunk/sandbox/spring-assembly --> geronimo/sandbox/spring- assembly geronimo/trunk/applications/jmxdebug--> geronimo/sandbox/ jmxdebug (I think this need more work or we should simply drop it) Console --- Aaron correct me if I'm wrong... I assume that the console is tied to the version of the Geronimo server it is included with, so it would be unreasonable to ship it separately. Therefore, I think we should make move it to the root of trunk geronimo/trunk/applications/console-core --> geronimo/trunk/ console/core geronimo/trunk/applications/console-ear--> geronimo/trunk/ console/ear geronimo/trunk/applications/console-framework --> geronimo/trunk/ console/framework geronimo/trunk/applications/console-standard --> geronimo/trunk/ console/standard Specs - Alan is on this one Applications There is another thread on this, "Applications directory structure", started by Dave Colasurdo. Whatever comes out of that would be this task.
Re: Contributors permission in JIRA
Anyone that is a contributor and asks for karma. Alternatively, we could just give everyone access and ask that they be respectful of others. Actually, I'd prefer we start with this option and fall back to just people that asked if it turns out to be a problem. -dain On Oct 28, 2005, at 11:13 AM, Geir Magnusson Jr. wrote: who would be in that group? On Oct 28, 2005, at 2:11 PM, Dain Sundstrom wrote: I'd like to create a geronimo-contributors group in jira. We would give contributors permission to assign, move, and resolve issues but not close them. This will let the committers know what everyone is working on, and will hopefully help those working on earning commit get used to JIRA. What do you think? -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Closed: (GERONIMO-1008) Leading blank lines in
[ http://issues.apache.org/jira/browse/GERONIMO-1008?page=all ] David Jencks closed GERONIMO-1008: -- Fix Version: 1.0 Resolution: Fixed Assign To: David Jencks Added lotsa trim()s to the urlPatterns. Have not verified that the tck is ok with this. Sending modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java Sending modules/tomcat-builder/src/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java Transmitting file data .. Committed revision 329279. > Leading blank lines in > > > Key: GERONIMO-1008 > URL: http://issues.apache.org/jira/browse/GERONIMO-1008 > Project: Geronimo > Type: Bug > Components: web > Versions: 1.0-M4 > Environment: all > Reporter: anita kulshreshtha > Assignee: David Jencks > Priority: Minor > Fix For: 1.0 > >This issue was discussed in GERONIMO-654. Leading blank lines in the > element of the deployment descriptor are not stripped. Hence > the deployer gives the following error : > Error: Unable to distribute jsp-examples.war: must not > contain LF(#xA) > Servlet 2.4 spec, SRV 13.2 says : > . Web containers must remove all leading and trailing whitespace, which is > defined as "S(white space)" in XML 1.0 > (http://www.w3.org/TR/2000/WD-xml-2e-2814), for the element content of > the text nodes of a deployment descriptor. > ... > ... > . URI paths specified in the deployment descriptor are assumed to be in > URLdecoded form. The containers must inform the developer with a descriptive > error message when URL contains CR(#xD) or LF(#xA). The containers must > preserve all other characters including whitespace in URL. > After talking to Tomcat folks and IMHO we should allow > >/foo > > and give error message for : > > /foo > /bar > >This applies to both web containers. -- 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: Tranql not building?
gs.com> In-Reply-To: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1 X-MMS-Smtp-Auth: Authenticated As [EMAIL PROTECTED] X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1 I'm on SuSE Linux so maybe thats a difference? I can try a build later this weekend...I'll have to setup a Windows Environment. Alan D. Cabrera wrote: > Yes. I'm on WinXP/JDK142. How about you? > > > Regards, > Alan > > On 10/26/2005 6:40 PM, Matt Hogstrom wrote: > >> Hi Alan, >> >> I just did a fresh-checkout and TranQL built ok. Are you still having >> the same problem? >> >> Alan D. Cabrera wrote: >> >>> Yeah, I refreshed this and I still get the same error. >>> >>> >>> Regards, >>> Alan >>> >>> Matt Hogstrom wrote, On 10/26/2005 12:46 PM: >>> I fixed a typo in one of the test modules. I just did a fresh-checkout and rebuilt so it looks clean at this point. Let me know if your still broken Alan. Matt Alan D. Cabrera wrote: > I'm getting this error when I build on WinXP, JDK142: > > Testsuite: org.tranql.ddl.DDLGeneratorTest > Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.15 sec > > Testcase: testGenerate(org.tranql.ddl.DDLGeneratorTest):FAILED > expected:<13> but was:<10> > junit.framework.AssertionFailedError: expected:<13> but was:<10> >at > org.tranql.ddl.DDLGeneratorTest.testGenerate(DDLGeneratorTest.java:67) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > >at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185) >at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) >at > org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) >at > org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) >at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) >at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) >at > org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) >at > org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) > > >at > org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) > > >at com.werken.werkz.Goal.fire(Goal.java:639) >at com.werken.werkz.Goal.attain(Goal.java:575) >at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) >at com.werken.werkz.Goal.attain(Goal.java:573) >at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) >at com.werken.werkz.Goal.attain(Goal.java:573) >at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) >at > org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) > > >at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) >at > org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) >at > org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) > > >at > org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) > > >at com.werken.werkz.Goal.fire(Goal.java:639) >at com.werken.werkz.Goal.attain(Goal.java:575) >at > org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) > >at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) >at org.apache.maven.cli.App.doMain(App.java:488) >at org.apache.maven.cli.App.main(App.java:1239) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > >at com.werken.forehead.Forehead.run(Forehead.java:551) >at com.werken.forehead.Forehead.main(Forehead.java:581) > > > > > Matt Hogstrom wrote, On 10/26/2005 12:17 PM: > >> My bad...fixed a typo :) >> >> David Blevins wrote: >> >>> Matt, Gianny, did we catch you in the middle of a checkin? >>> >>> http://ci.gbuild.org/continuum/servlet/continuum/target/ >>> ProjectBuild.vm?view=ProjectBuild&buildId=141&id=8 >>> >>> If so, just click the "Build Now" link next to tranql on this page: >>> >>> >>> http://ci.gbuild.org/continuum/servlet/continuum/target/Summary.vm/
New Solaris Zones
The solaris zones for Geronimo are being created, one for general project use and one for tck use. How shall we administer them? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Help ... proxy problem with tomcat web connectors
I'm trying to fix a problem with in the web console where it is supposed to list the connections ... but instead gets an error (at the bottom of this note). It seems to be a problem actually generating the proxy for the class and I lose touch of things when it gets into cglib. In short ... here is the scenario: - Discover via the KernelManagementHelper that there are 3 connections and gets the object the names of those connections - TomcatAJPConnector (class is ConnectorGBean) - TomcatWebConnector (class is ConnectorGBean) - TomcatWebSSLConnector (class is HttpsConnectorGBean) - Attempt to create proxies for the 3 connections. This works for for the first two listed about but fails building the proxy for the TomcatWebSSLConnector GBean. - Looking at the BasicProxyManager I can see it creating the Enhancer and associating all of the interfaces. This GBean has 5 interfaces which are reduced to 3 in the ManagedProxyFactory (the ones with the * are the ones that remain after reduction) - o.a.g.management.geronimo.NetworkConnector * o.a.g.management.geronimo.SecureConnector * o.a.g.tomcat.TomcatWebConnector - o.a.g.management.WebConnector * o.a.g.kernel.proxy.GeronimoManagedBean - These remaining 3 interfaces are used to set the Enhanced interfaces (which seems strange to me because I would think that we would have wanted all 5 interfaces in the proxy ... is this a problem?) and, since there is more than 1 interface left, Object is set as the superClass. - When we finally invoke the enhancer.createClass() we get a NoClassDefFoundError exception for the TomcatWebConnector interface. This is also strange because at lease one of the other connector GBeans (TomcatWebConnector) also implements this interface and it was successful creating that proxy. Any ideas? stack trace: 08:52:55,740 ERROR [KernelManagementHelper] Unable to look up related GBeannet.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException-->null at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317) at org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.(BasicProxyManager.java:222) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxyFactory(BasicProxyManager.java:92) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:119) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxies(BasicProxyManager.java:156) at org.apache.geronimo.console.util.KernelManagementHelper.getWebConnectors(KernelManagementHelper.java:339) at org.apache.geronimo.console.util.PortletManager.getWebConnectors(PortletManager.java:150) at org.apache.geronimo.console.webmanager.ConnectorPortlet.doList(ConnectorPortlet.java:375) at org.apache.geronimo.console.webmanager.ConnectorPortlet.doView(ConnectorPortlet.java:360) 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(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.render(PortletInvokerImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp:65) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.ja
[jira] Updated: (GERONIMO-1117) [Build break] junit tests in openejb failed.
[ http://issues.apache.org/jira/browse/GERONIMO-1117?page=all ] Prasad Kashyap updated GERONIMO-1117: - Attachment: build-all2.log > [Build break] junit tests in openejb failed. > > > Key: GERONIMO-1117 > URL: http://issues.apache.org/jira/browse/GERONIMO-1117 > Project: Geronimo > Type: Bug > Components: OpenEJB > Versions: 1.0-M5 > Environment: Windows XP, Pentium 4 3Ghz, 2 GB RAM > Reporter: Prasad Kashyap > Attachments: build-all2.log > > [junit] [ERROR] TEST > org.openejb.test.security.slsb.BasicStatelessScenario002Tests FAILED > [junit] Running org.openejb.test.stateful.StatefulTestSuite > Error closing connection with server: null > . > . > Error closing connection with server: null > [junit] Tests run: 0, Failures: 0, Errors: 13, Time elapsed: 0.251 sec > [junit] [ERROR] TEST org.openejb.test.stateful.StatefulTestSuite FAILED > [junit] Running org.openejb.test.stateless.StatelessTestSuite > Error closing connection with server: null > ... > ... > Error closing connection with server: null > [junit] Tests run: 0, Failures: 0, Errors: 14, Time elapsed: 0.631 sec > [junit] [ERROR] TEST org.openejb.test.stateless.StatelessTestSuite FAILED > Completed > Module org/openejb/cmp2/CMRMapping uninstalled. > Completed > Completed > Module org/openejb/cmp2/Storage uninstalled. > Completed > Completed > Module org/openejb/cmp2/petstore uninstalled. > Completed > Completed > Module org/openejb/cmp2/Prefetch uninstalled. > Completed > Completed > Completed > Module org/openejb/scenario002 uninstalled. > Completed > 12:09:38,135 ERROR [GBeanInstance] GBeanInstance should already be stopped > before die() is called: > objectName=geronimo.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=BasicStatelessBean > state=stopping > Completed > Completed > Module org/openejb/Itests uninstalled. > Completed > itest:teardown: > [echo] undeployed ejbs > 12:10:28,467 ERROR [GBeanInstance] GBeanInstance should already be stopped > before die() is called: > objectName=geronimo.server:J2EEApplication=null,J2EEModule=org/openejb/Security,J2EEServer=geronimo,j2eeType=CORBACSS,name=IOR7 > state=starting > 12:10:28,477 ERROR [GBeanInstance] GBeanInstance should already be stopped > before die() is called: > objectName=geronimo.server:J2EEApplication=null,J2EEModule=org/openejb/Security,J2EEServer=geronimo,j2eeType=CORBATSS,name=org/openejb/Itests > state=starting > [echo] server has stopped > BUILD FAILED > File.. C:\Documents and > Settings\Administrator\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.jelly > Element... maven:reactor > Line.. 217 > Column 9 > Unable to obtain goal [ejb:install] -- C:\Documents and > Settings\Administrator\.maven\cache\maven-itest-plugin-1.0\plugin.jelly:166:64: > There were test failures. > Server shutdown begun -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1117) [Build break] junit tests in openejb failed.
[Build break] junit tests in openejb failed. Key: GERONIMO-1117 URL: http://issues.apache.org/jira/browse/GERONIMO-1117 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M5 Environment: Windows XP, Pentium 4 3Ghz, 2 GB RAM Reporter: Prasad Kashyap [junit] [ERROR] TEST org.openejb.test.security.slsb.BasicStatelessScenario002Tests FAILED [junit] Running org.openejb.test.stateful.StatefulTestSuite Error closing connection with server: null . . Error closing connection with server: null [junit] Tests run: 0, Failures: 0, Errors: 13, Time elapsed: 0.251 sec [junit] [ERROR] TEST org.openejb.test.stateful.StatefulTestSuite FAILED [junit] Running org.openejb.test.stateless.StatelessTestSuite Error closing connection with server: null ... ... Error closing connection with server: null [junit] Tests run: 0, Failures: 0, Errors: 14, Time elapsed: 0.631 sec [junit] [ERROR] TEST org.openejb.test.stateless.StatelessTestSuite FAILED Completed Module org/openejb/cmp2/CMRMapping uninstalled. Completed Completed Module org/openejb/cmp2/Storage uninstalled. Completed Completed Module org/openejb/cmp2/petstore uninstalled. Completed Completed Module org/openejb/cmp2/Prefetch uninstalled. Completed Completed Completed Module org/openejb/scenario002 uninstalled. Completed 12:09:38,135 ERROR [GBeanInstance] GBeanInstance should already be stopped before die() is called: objectName=geronimo.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=BasicStatelessBean state=stopping Completed Completed Module org/openejb/Itests uninstalled. Completed itest:teardown: [echo] undeployed ejbs 12:10:28,467 ERROR [GBeanInstance] GBeanInstance should already be stopped before die() is called: objectName=geronimo.server:J2EEApplication=null,J2EEModule=org/openejb/Security,J2EEServer=geronimo,j2eeType=CORBACSS,name=IOR7 state=starting 12:10:28,477 ERROR [GBeanInstance] GBeanInstance should already be stopped before die() is called: objectName=geronimo.server:J2EEApplication=null,J2EEModule=org/openejb/Security,J2EEServer=geronimo,j2eeType=CORBATSS,name=org/openejb/Itests state=starting [echo] server has stopped BUILD FAILED File.. C:\Documents and Settings\Administrator\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.jelly Element... maven:reactor Line.. 217 Column 9 Unable to obtain goal [ejb:install] -- C:\Documents and Settings\Administrator\.maven\cache\maven-itest-plugin-1.0\plugin.jelly:166:64: There were test failures. Server shutdown begun -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo specs break out
+1 On Oct 28, 2005, at 12:59 AM, David Jencks wrote: +1 I think the spec version should be part of the artifactId and then we need a version as well, e.g. servlet-2.4 rc4 I think we should talk to all the other apache projects with specs and make an apache specs project that we all use. BTW, am I correct in thinking that the approved style of M2 groupIds would be e.g. org.apache.geronimo.specs for the specs and org.apache.geronimo for our modules? Many thanks david jencks On Oct 27, 2005, at 9:46 PM, Alan D. Cabrera wrote: Someone, at some time, proposed that we breakout specs from our regular build. I think that this is a good idea. I'd like to move it out to its own root called "specs". I will also convert it to m2 while I'm at it? What do you think? Regards, Alan
Weekly conference call - thoughts
I was thinking that it might be worthwhile to have a regular weekly conference call for those on the dev list. It would not be mandatory at all but we could all put it on our calendars and use it as a time to talk over issues rather than rely totally on e-mail. We'd get someone to take notes and post them to the dev list and solicit agenda items from there as well. I'll look into how we could do this and what the cost issues are. I was thinking something like Thursdays at noon EST (most favorable to cover those that might be interested from Europe). Thoughts on the idea, frequency, etc. Cheers, Matt
[jira] Closed: (GERONIMO-754) Move from HOWL version 0.1.8 to HOWL version 0.1.9
[ http://issues.apache.org/jira/browse/GERONIMO-754?page=all ] David Jencks closed GERONIMO-754: - Resolution: Fixed We moved to 0.11, so this is superseded > Move from HOWL version 0.1.8 to HOWL version 0.1.9 > -- > > Key: GERONIMO-754 > URL: http://issues.apache.org/jira/browse/GERONIMO-754 > Project: Geronimo > Type: Task > Components: dependencies > Reporter: John Sisson > Priority: Minor > Fix For: 1.0 > > Two bugs have been fixed since 0.1.8. See http://howl.objectweb.org/ > We should try to get ActiveMQ to upgrade to the same version to simplify the > number of dependencies. > Try for M5 release? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-409) SQLSecurityRealm/SQLLoginModule needs overhaul
[ http://issues.apache.org/jira/browse/GERONIMO-409?page=all ] David Jencks closed GERONIMO-409: - Resolution: Fixed Assign To: David Jencks Applied the query patch, changed test to use it. We could open a separate issue for using an existing pooled connection. Sending modules/security/src/java/org/apache/geronimo/security/realm/providers/SQLLoginModule.java Sending modules/security/src/test/org/apache/geronimo/security/jaas/LoginSQLTest.java Transmitting file data .. Committed revision 329268. > SQLSecurityRealm/SQLLoginModule needs overhaul > -- > > Key: GERONIMO-409 > URL: http://issues.apache.org/jira/browse/GERONIMO-409 > Project: Geronimo > Type: Bug > Components: security > Versions: 1.0-M2 > Reporter: Aaron Mulder > Assignee: David Jencks > Priority: Critical > Fix For: 1.0 > Attachments: sqlwithusernamepar.patch > > The SQLSecurityRealm and SQLLoginModule do not scale. In particular, they > load all users and all groups in the security realm once when the realm is > started, and again for every login request. Imagine a database of thousands > of users/groups. > There should instead be required SQL queries to load a single password given > a username, and to load a list of groups for a single user given a username. > Then there can be optional SQL queries to load a list of all users or to load > a list of all groups, though we still shouldn't care who the group members > are. > Also, it appears that the digesting features provided by > SQLSecurityRealmPasswordDigested are never invoked, so that class has no > effect. It seems like the best way to implement digesting would be to make > the basic SQLLoginModule take a digest algorithm argument. If present, the > SQLLoginModule could instantiate and use a digester on the incoming password > (and if not, not). Then we don't need any extra class for it, and you could > enable digesting simply by adding a login module configuration option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-1111) Use Trifork CORBA (freeorb)
On Oct 28, 2005, at 9:59 AM, Alan Cabrera (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-? page=comments#action_12356222 ] Alan Cabrera commented on GERONIMO-: Maybe you could send the IDL files for us to compile. I think that we already have an IDL compiler from a previous donation. hmm, I thought we were using the sun idl compiler. Anyway the IDL should be sufficient. We should be able to add it to the corba spec module. Packing up jar files from another project is not the way to go. I definitely agree. thanks david jencks Use Trifork CORBA (freeorb) --- Key: GERONIMO- URL: http://issues.apache.org/jira/browse/GERONIMO- Project: Geronimo Type: New Feature Components: CORBA Versions: 1.1 Reporter: Kresten Krab Thorup Assignee: Alan Cabrera Attachments: freeorb-contrib.tgz As has been discussed previously, Trifork wants to donate a CORBA implementation. This message is to get things really started in context of Geronimo. Along with this message is a tar ball of the initial contribution, and I want to take this opportunity to describe what we are donating and how we would like to do this. To set things straight, will not be donating a full CORBA implementation up front. What we are proposing is to donate the resources (read: developers) that it takes to do a full CORBA implementation in context of Apache Geronimo. Our concern with donating the full code is that we want to ensure that this is built as a community effort, so when we're done we are not the "single point of failure" for this to succeed as we go forward. We would like to avoid being the only ones to know the code, so that the CORBA implementation that comes out of this is something that can have a life without us pushing it forward. This is really the principal value that we see in contributing to this project. We want to have a free and independent CORBA implementation too, but we would like to avoid being stuck on it as we go forward. Having said all that, we do have a CORBA implementation; and in our effort to bring this forward we will definitively use bits, pieces or even large chunks of this to make the Apache Geronimo CORBA implementation be complete and successful. We know that there is eagerness in the Geronimo community to get things started in building a CORBA solution, and so hopefully this first contribution will be accepted as a starting point from which we will build a world-class CORBA system. What is in this package is the foundation of a new I/O subsystem that I have previously talked about, and some of the code to hook that up with the client-side of the CORBA stack. As such, thins chunk of code is not in even self-contained nor complete. It's just the state of the code in our lab right now, and we want to move this into Geronimo space before we get too far along. The mile stones that I imagine moving forward from here would be something like this: 1. Client-side stream-based invocation. 2. Value semantics (object serialization) 3. Server-side stream-based invocation handling, including POA implementation. 4. Dynamic stubs. 5. Local invocations. There are a ton of sub-projects that I would love to see someone starting on; some of which already have place holders or stubs in the code that is part of the tar ball attached to this. -- 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: Contributors permission in JIRA
who would be in that group? On Oct 28, 2005, at 2:11 PM, Dain Sundstrom wrote: I'd like to create a geronimo-contributors group in jira. We would give contributors permission to assign, move, and resolve issues but not close them. This will let the committers know what everyone is working on, and will hopefully help those working on earning commit get used to JIRA. What do you think? -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Contributors permission in JIRA
I'd like to create a geronimo-contributors group in jira. We would give contributors permission to assign, move, and resolve issues but not close them. This will let the committers know what everyone is working on, and will hopefully help those working on earning commit get used to JIRA. What do you think? -dain
Change of Apache Geronimo PMC Chair
All, Earlier this month, I submitted my resignation as PMC Chair of the Apache Geronimo project. There are many reasons why I chose to do so, but given that we'd just achieved the major milestone of the certified J2EE 1.4 server with the M5 release, I felt that the timing was right. I'm pleased to announce that on wednesday, the Apache Board accepted my resignation and has designated Ken Coar as the new PMC chair. Ken is a founder of the ASF, currently a director, and has broad experience here at the ASF and in other open source communities. This is an administrative change and will have no impact on project progress or activity whatsoever. Personally, I'm not going anywhere :) and am still interested in all areas of this project. In the future, I may be working at a reduced energy level on some aspects, but with the addition of Ken's participation, this is a net gain for the project. As a community, we have achieved an incredible amount over the last two years, and I'm very proud of having the opportunity to help us get where we are. We undertook a momentous task back in August 2003 and it's a credit to all involved that we completed it so quickly. It's been an interesting project to this point, and I look forward to what our future brings. J2EE 1.4 clearly isn't the final chapter in enterprise middleware, and this project is in a great position to take on whatever comes next. But that's next. For now, on to Apache Geronimo 1.0 :) geir P.S. Although Ken goes by the name of "Rodent of Unusual Size", I don't expect that you should call him "Rodent" -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Tranql not building?
Yes. I'm on WinXP/JDK142. How about you? Regards, Alan On 10/26/2005 6:40 PM, Matt Hogstrom wrote: Hi Alan, I just did a fresh-checkout and TranQL built ok. Are you still having the same problem? Alan D. Cabrera wrote: Yeah, I refreshed this and I still get the same error. Regards, Alan Matt Hogstrom wrote, On 10/26/2005 12:46 PM: I fixed a typo in one of the test modules. I just did a fresh-checkout and rebuilt so it looks clean at this point. Let me know if your still broken Alan. Matt Alan D. Cabrera wrote: I'm getting this error when I build on WinXP, JDK142: Testsuite: org.tranql.ddl.DDLGeneratorTest Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.15 sec Testcase: testGenerate(org.tranql.ddl.DDLGeneratorTest):FAILED expected:<13> but was:<10> junit.framework.AssertionFailedError: expected:<13> but was:<10> at org.tranql.ddl.DDLGeneratorTest.testGenerate(DDLGeneratorTest.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:488) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Matt Hogstrom wrote, On 10/26/2005 12:17 PM: My bad...fixed a typo :) David Blevins wrote: Matt, Gianny, did we catch you in the middle of a checkin? http://ci.gbuild.org/continuum/servlet/continuum/target/ ProjectBuild.vm?view=ProjectBuild&buildId=141&id=8 If so, just click the "Build Now" link next to tranql on this page: http://ci.gbuild.org/continuum/servlet/continuum/target/Summary.vm/ fid/continuumProject Just setup the automatic notifications today, so doing this one by hand :) -David
[jira] Commented: (GERONIMO-1111) Use Trifork CORBA (freeorb)
[ http://issues.apache.org/jira/browse/GERONIMO-?page=comments#action_12356222 ] Alan Cabrera commented on GERONIMO-: Maybe you could send the IDL files for us to compile. I think that we already have an IDL compiler from a previous donation. Packing up jar files from another project is not the way to go. > Use Trifork CORBA (freeorb) > --- > > Key: GERONIMO- > URL: http://issues.apache.org/jira/browse/GERONIMO- > Project: Geronimo > Type: New Feature > Components: CORBA > Versions: 1.1 > Reporter: Kresten Krab Thorup > Assignee: Alan Cabrera > Attachments: freeorb-contrib.tgz > > As has been discussed previously, Trifork wants to donate a CORBA > implementation. This message is to get things really started in context of > Geronimo. Along with this message is a tar ball of the initial contribution, > and I want to take this opportunity to describe what we are donating and how > we would like to do this. > To set things straight, will not be donating a full CORBA implementation up > front. What we are proposing is to donate the resources (read: developers) > that it takes to do a full CORBA implementation in context of Apache > Geronimo. Our concern with donating the full code is that we want to ensure > that this is built as a community effort, so when we're done we are not the > "single point of failure" for this to succeed as we go forward. We would > like to avoid being the only ones to know the code, so that the CORBA > implementation that comes out of this is something that can have a life > without us pushing it forward. This is really the principal value that we > see in contributing to this project. We want to have a free and independent > CORBA implementation too, but we would like to avoid being stuck on it as we > go forward. > Having said all that, we do have a CORBA implementation; and in our effort to > bring this forward we will definitively use bits, pieces or even large chunks > of this to make the Apache Geronimo CORBA implementation be complete and > successful. > We know that there is eagerness in the Geronimo community to get things > started in building a CORBA solution, and so hopefully this first > contribution will be accepted as a starting point from which we will build a > world-class CORBA system. > What is in this package is the foundation of a new I/O subsystem that I have > previously talked about, and some of the code to hook that up with the > client-side of the CORBA stack. As such, thins chunk of code is not in even > self-contained nor complete. It's just the state of the code in our lab > right now, and we want to move this into Geronimo space before we get too far > along. > The mile stones that I imagine moving forward from here would be something > like this: > 1. Client-side stream-based invocation. > 2. Value semantics (object serialization) > 3. Server-side stream-based invocation handling, including POA implementation. > 4. Dynamic stubs. > 5. Local invocations. > There are a ton of sub-projects that I would love to see someone starting on; > some of which already have place holders or stubs in the code that is part of > the tar ball attached to this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo specs break out
+1
-dain
On Oct 28, 2005, at 6:33 AM, Bruce Snyder wrote:
On 10/27/05, David Jencks <[EMAIL PROTECTED]> wrote:
I think the spec version should be part of the artifactId and then we
need a version as well,
e.g. servlet-2.4
rc4
I think we should talk to all the other apache projects with specs
and
make an apache specs project that we all use.
That's a brilliant idea, David.
BTW, am I correct in thinking that the approved style of M2 groupIds
would be e.g. org.apache.geronimo.specs for the specs and
org.apache.geronimo for our modules?
Sounds good to me.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61EG;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: gbuild subproject?
+1 Lets figure out how to manage these distributed builds and then help other ASF projects take advantage of it. -dain On Oct 28, 2005, at 1:53 AM, David Blevins wrote: What do you guys think about a gbuild subproject? I'd really like at least a category in jira and at least a spot in svn where we can check in scripts and docco. We could move the scripts directory I created months back into it and work on cleaning and organizing this stuff. I guess I'd really like to start formalizing this thing so that when someone wants to throw a box in the mix the standard answer could be something like check out these things from svn, follow these instructions, send us your keys, etc. I know there are non-geronimo specific facets (openejb, activemq building code, etc) which could make it odd as a subproject. But those complexities are there in our build anyway and Geronimo is the primary focus, so it might be better go keep things close to home. Thoughts? -David
Re: Combine common code in jetty and tomcat module builders?
If you have a working version, please submit it! This is great news! I think I should wait on combining them until your code is in. If you want to do the refactoring that would also be great! thanks david jencks On Oct 28, 2005, at 6:11 AM, anita kulshreshtha wrote: Good idea. As discussed with Jeff offline I have been working on G-1035. I have made changes to the existing TomcatModuleBuilder to make it almost identical to JettyModuleBuilder except for the very small container specific part. Please let me know if you would like me to submit this at this stage. Thanks Anita --- Jeff Genender <[EMAIL PROTECTED]> wrote: +1...this is very good. Jeff David Jencks wrote: I think there's a lot of code copied from the jetty to the tomcat module builder. Now that both are somewhere near the verge of stability, I'd like to refactor the common parts into a common superclass. Any objections? thanks david jencks -- Jeff Genender http://geronimo.apache.org __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
Re: gbuild subproject?
+1 excellent idea david jencks On Oct 28, 2005, at 1:53 AM, David Blevins wrote: What do you guys think about a gbuild subproject? I'd really like at least a category in jira and at least a spot in svn where we can check in scripts and docco. We could move the scripts directory I created months back into it and work on cleaning and organizing this stuff. I guess I'd really like to start formalizing this thing so that when someone wants to throw a box in the mix the standard answer could be something like check out these things from svn, follow these instructions, send us your keys, etc. I know there are non-geronimo specific facets (openejb, activemq building code, etc) which could make it odd as a subproject. But those complexities are there in our build anyway and Geronimo is the primary focus, so it might be better go keep things close to home. Thoughts? -David
Re: gbuild subproject?
On 10/28/2005 1:53 AM, David Blevins wrote: What do you guys think about a gbuild subproject? I'd really like at least a category in jira and at least a spot in svn where we can check in scripts and docco. We could move the scripts directory I created months back into it and work on cleaning and organizing this stuff. I guess I'd really like to start formalizing this thing so that when someone wants to throw a box in the mix the standard answer could be something like check out these things from svn, follow these instructions, send us your keys, etc. I know there are non-geronimo specific facets (openejb, activemq building code, etc) which could make it odd as a subproject. But those complexities are there in our build anyway and Geronimo is the primary focus, so it might be better go keep things close to home. Thoughts? -David 0 This strikes me as an infra thing. It would be nice to offer this to other projects as well. Regards, Alan
Re: Combine common code in jetty and tomcat module builders?
+1 This is great anita kulshreshtha wrote: Good idea. As discussed with Jeff offline I have been working on G-1035. I have made changes to the existing TomcatModuleBuilder to make it almost identical to JettyModuleBuilder except for the very small container specific part. Please let me know if you would like me to submit this at this stage. Thanks Anita --- Jeff Genender <[EMAIL PROTECTED]> wrote: +1...this is very good. Jeff David Jencks wrote: I think there's a lot of code copied from the jetty to the tomcat module builder. Now that both are somewhere near the verge of stability, I'd like to refactor the common parts into a common superclass. Any objections? thanks david jencks -- Jeff Genender http://geronimo.apache.org __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
Re: gbuild subproject?
+1
Bruce Snyder wrote:
On 10/28/05, David Blevins <[EMAIL PROTECTED]> wrote:
What do you guys think about a gbuild subproject?
I'd really like at least a category in jira and at least a spot in
svn where we can check in scripts and docco. We could move the
scripts directory I created months back into it and work on cleaning
and organizing this stuff. I guess I'd really like to start
formalizing this thing so that when someone wants to throw a box in
the mix the standard answer could be something like check out these
things from svn, follow these instructions, send us your keys, etc.
I know there are non-geronimo specific facets (openejb, activemq
building code, etc) which could make it odd as a subproject. But
those complexities are there in our build anyway and Geronimo is the
primary focus, so it might be better go keep things close to home.
Thoughts?
A very good idea. Being able to tell someone to check out a project
from SVN is a great way to ramp up a box in the farm.
+1
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Apologies in advance
All, My SMTP server has started inserting some odd text when I'm replying which I can imagine is quite annoying. I'll take a look at it next week when I get back (I'm travelling). Apologies in advance and I just wanted to let you know I'm aware of the issue. Matt Here is what seems to be getting prepended on messages. I assume y'all see them as well. pache.org> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1 X-MMS-Smtp-Auth: Authenticated As [EMAIL PROTECTED] X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1
[jira] Updated: (GERONIMO-1108) CertManagerPortlet is being loaded for the SecurityRealms portlet
[ http://issues.apache.org/jira/browse/GERONIMO-1108?page=all ] Matt Hogstrom updated GERONIMO-1108: Fix Version: 1.0 Need to fix the broken link. > CertManagerPortlet is being loaded for the SecurityRealms portlet > - > > Key: GERONIMO-1108 > URL: http://issues.apache.org/jira/browse/GERONIMO-1108 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0 > Environment: WinXP w/ 1.4.2 JDK > Reporter: Donald Woods > Priority: Minor > Fix For: 1.0 > Attachments: Geronimo-1108.patch > > The console-standard web.xml is loading the CertManagerPortlet class instead > of the EmptyPortlet class for the SecurityRealms portlet (since there > currently is no All Realms/Security Realm portlet implementation in the > working 1.0 trunk.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1109) Need class for server shutdown
[ http://issues.apache.org/jira/browse/GERONIMO-1109?page=all ] Matt Hogstrom updated GERONIMO-1109: Fix Version: 1.1 (was: 1.0) I expect that 1.0 will most likely be running single server installations. I'm deferring the fix for this to 1.1. > Need class for server shutdown > -- > > Key: GERONIMO-1109 > URL: http://issues.apache.org/jira/browse/GERONIMO-1109 > Project: Geronimo > Type: New Feature > Components: startup/shutdown > Versions: 1.0 > Reporter: Sachin Patel > Priority: Minor > Fix For: 1.1 > Attachments: StopServer.java > > Attached is a class that shut's down the server. Unlike the existing > StopRemoteServer it handles shutting down the correct server if multiple > server instances are running. This class could be called from a script or > even a windows service. > - I'm not exactly sure where this class should be loaded, wether it should be > embedded into server.jar or somewhere else. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1113) WWW site: Add Apache Directory to list of related projects
[ http://issues.apache.org/jira/browse/GERONIMO-1113?page=all ] Matt Hogstrom updated GERONIMO-1113: Fix Version: 1.x This can be done anytime. I'm deferring the implmenetation to 1.x to move it out of the critical path for 1.0. > WWW site: Add Apache Directory to list of related projects > -- > > Key: GERONIMO-1113 > URL: http://issues.apache.org/jira/browse/GERONIMO-1113 > Project: Geronimo > Type: Wish > Reporter: Stefan Zoerner > Priority: Trivial > Fix For: 1.x > > Great to see that Apache Directory Server is embeded in the current > geronimo-1.0-M5. Thank you for making it availlable in such a confortable way > (GBean configuration, start/stop)! Especially new users will like that! > Although I do not know what your definition of "dependency" is, it would be > nice if you could add the project to you mosaic list here: > http://geronimo.apache.org/dependencies.html > Thanks for considering it, we at Directory project would appreciate to be > listed (good promotion for us). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo specs break out
On 10/27/05, David Jencks <[EMAIL PROTECTED]> wrote:
> I think the spec version should be part of the artifactId and then we
> need a version as well,
>
> e.g. servlet-2.4
> rc4
>
> I think we should talk to all the other apache projects with specs and
> make an apache specs project that we all use.
That's a brilliant idea, David.
> BTW, am I correct in thinking that the approved style of M2 groupIds
> would be e.g. org.apache.geronimo.specs for the specs and
> org.apache.geronimo for our modules?
Sounds good to me.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Geronimo specs break out
On 10/27/05, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> Someone, at some time, proposed that we breakout specs from our regular
> build. I think that this is a good idea. I'd like to move it out to
> its own root called "specs". I will also convert it to m2 while I'm at it?
+1
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: gbuild subproject?
On 10/28/05, David Blevins <[EMAIL PROTECTED]> wrote:
> What do you guys think about a gbuild subproject?
>
> I'd really like at least a category in jira and at least a spot in
> svn where we can check in scripts and docco. We could move the
> scripts directory I created months back into it and work on cleaning
> and organizing this stuff. I guess I'd really like to start
> formalizing this thing so that when someone wants to throw a box in
> the mix the standard answer could be something like check out these
> things from svn, follow these instructions, send us your keys, etc.
>
> I know there are non-geronimo specific facets (openejb, activemq
> building code, etc) which could make it odd as a subproject. But
> those complexities are there in our build anyway and Geronimo is the
> primary focus, so it might be better go keep things close to home.
>
> Thoughts?
A very good idea. Being able to tell someone to check out a project
from SVN is a great way to ramp up a box in the farm.
+1
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Combine common code in jetty and tomcat module builders?
Good idea. As discussed with Jeff offline I have been working on G-1035. I have made changes to the existing TomcatModuleBuilder to make it almost identical to JettyModuleBuilder except for the very small container specific part. Please let me know if you would like me to submit this at this stage. Thanks Anita --- Jeff Genender <[EMAIL PROTECTED]> wrote: > +1...this is very good. > > Jeff > > David Jencks wrote: > > I think there's a lot of code copied from the > jetty to the tomcat module > > builder. Now that both are somewhere near the > verge of stability, I'd > > like to refactor the common parts into a common > superclass. Any > > objections? > > > > thanks > > david jencks > > -- > Jeff Genender > http://geronimo.apache.org > > __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
Re: gbuild subproject?
Works for me Aaron On 10/28/05, Jeff Genender <[EMAIL PROTECTED]> wrote: > David, > > +1 from me. This is an excellent idea. > > Jeff > > David Blevins wrote: > > What do you guys think about a gbuild subproject? > > > > I'd really like at least a category in jira and at least a spot in svn > > where we can check in scripts and docco. We could move the scripts > > directory I created months back into it and work on cleaning and > > organizing this stuff. I guess I'd really like to start formalizing > > this thing so that when someone wants to throw a box in the mix the > > standard answer could be something like check out these things from > > svn, follow these instructions, send us your keys, etc. > > > > I know there are non-geronimo specific facets (openejb, activemq > > building code, etc) which could make it odd as a subproject. But those > > complexities are there in our build anyway and Geronimo is the primary > > focus, so it might be better go keep things close to home. > > > > Thoughts? > > > > -David >
Re: Combine common code in jetty and tomcat module builders?
Sounds great to me Aaron On 10/28/05, Jeff Genender <[EMAIL PROTECTED]> wrote: > +1...this is very good. > > Jeff > > David Jencks wrote: > > I think there's a lot of code copied from the jetty to the tomcat module > > builder. Now that both are somewhere near the verge of stability, I'd > > like to refactor the common parts into a common superclass. Any > > objections? > > > > thanks > > david jencks > > -- > Jeff Genender > http://geronimo.apache.org > >
Re: gbuild subproject?
David, +1 from me. This is an excellent idea. Jeff David Blevins wrote: What do you guys think about a gbuild subproject? I'd really like at least a category in jira and at least a spot in svn where we can check in scripts and docco. We could move the scripts directory I created months back into it and work on cleaning and organizing this stuff. I guess I'd really like to start formalizing this thing so that when someone wants to throw a box in the mix the standard answer could be something like check out these things from svn, follow these instructions, send us your keys, etc. I know there are non-geronimo specific facets (openejb, activemq building code, etc) which could make it odd as a subproject. But those complexities are there in our build anyway and Geronimo is the primary focus, so it might be better go keep things close to home. Thoughts? -David
Re: Combine common code in jetty and tomcat module builders?
+1...this is very good. Jeff David Jencks wrote: I think there's a lot of code copied from the jetty to the tomcat module builder. Now that both are somewhere near the verge of stability, I'd like to refactor the common parts into a common superclass. Any objections? thanks david jencks -- Jeff Genender http://geronimo.apache.org
Re: Geronimo specs break out
+1 On Oct 28, 2005, at 12:46 AM, Alan D. Cabrera wrote: Someone, at some time, proposed that we breakout specs from our regular build. I think that this is a good idea. I'd like to move it out to its own root called "specs". I will also convert it to m2 while I'm at it? What do you think? Regards, Alan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Trifork CORBA
At 09:39 AM 10/28/2005, Kresten Krab Thorup wrote: The Trifork RMI/IIOP has a quite decent implementation of all of the javax.rmi.CORBA stuff that we can bring right in with little modification, so I was thinking that we should use that. However, if you know that those ValueHandlers are good, we can definitively make things less complicated by using them. I'm merely advocating walking before running ;). The only real reason for not using these pieces is performance, and even then the performance of the underlying streams is far more important. We don't even use our own ValueHandler for FVD serialization, just because its complicated, slow and not worth reinventing the wheel for. If you get run over by a bus, its going to be non-trivial for someone to figure out issues with a home-grown ValueHandler... andy
gbuild subproject?
What do you guys think about a gbuild subproject? I'd really like at least a category in jira and at least a spot in svn where we can check in scripts and docco. We could move the scripts directory I created months back into it and work on cleaning and organizing this stuff. I guess I'd really like to start formalizing this thing so that when someone wants to throw a box in the mix the standard answer could be something like check out these things from svn, follow these instructions, send us your keys, etc. I know there are non-geronimo specific facets (openejb, activemq building code, etc) which could make it odd as a subproject. But those complexities are there in our build anyway and Geronimo is the primary focus, so it might be better go keep things close to home. Thoughts? -David
Re: [jira] Commented: (GERONIMO-1111) Use Trifork CORBA (freeorb)
On Oct 28, 2005, at 3:37 AM, Alan Cabrera (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-? page=comments#action_12356157 ] Alan Cabrera commented on GERONIMO-: Kresten, bits of this code doesn't compile. IOSemaphoreClosedException seems to be missing, as are the CSIv2/ IIOP CORBA classes. I wasn't sure how to package this for G project setup. What's missing is a bunch of compiled standard IDL, like CSIv2. We need to decide on how to organize that; as I said previously I have been using the JacORB IDL compiler to generate these in the past. For now, I can construct a jar file with all the generated classes in it if you wish; but we need to choose a build strategy to have them be generated from IDL. Kresten Krab Thorup [EMAIL PROTECTED] "We do not inherit the Earth from our parents, we borrow it from our children." Saint Exupery Use Trifork CORBA (freeorb) --- Key: GERONIMO- URL: http://issues.apache.org/jira/browse/GERONIMO- Project: Geronimo Type: New Feature Components: CORBA Versions: 1.1 Reporter: Kresten Krab Thorup Assignee: Alan Cabrera Attachments: freeorb-contrib.tgz As has been discussed previously, Trifork wants to donate a CORBA implementation. This message is to get things really started in context of Geronimo. Along with this message is a tar ball of the initial contribution, and I want to take this opportunity to describe what we are donating and how we would like to do this. To set things straight, will not be donating a full CORBA implementation up front. What we are proposing is to donate the resources (read: developers) that it takes to do a full CORBA implementation in context of Apache Geronimo. Our concern with donating the full code is that we want to ensure that this is built as a community effort, so when we're done we are not the "single point of failure" for this to succeed as we go forward. We would like to avoid being the only ones to know the code, so that the CORBA implementation that comes out of this is something that can have a life without us pushing it forward. This is really the principal value that we see in contributing to this project. We want to have a free and independent CORBA implementation too, but we would like to avoid being stuck on it as we go forward. Having said all that, we do have a CORBA implementation; and in our effort to bring this forward we will definitively use bits, pieces or even large chunks of this to make the Apache Geronimo CORBA implementation be complete and successful. We know that there is eagerness in the Geronimo community to get things started in building a CORBA solution, and so hopefully this first contribution will be accepted as a starting point from which we will build a world-class CORBA system. What is in this package is the foundation of a new I/O subsystem that I have previously talked about, and some of the code to hook that up with the client-side of the CORBA stack. As such, thins chunk of code is not in even self-contained nor complete. It's just the state of the code in our lab right now, and we want to move this into Geronimo space before we get too far along. The mile stones that I imagine moving forward from here would be something like this: 1. Client-side stream-based invocation. 2. Value semantics (object serialization) 3. Server-side stream-based invocation handling, including POA implementation. 4. Dynamic stubs. 5. Local invocations. There are a ton of sub-projects that I would love to see someone starting on; some of which already have place holders or stubs in the code that is part of the tar ball attached to this. -- 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: Trifork CORBA
At 08:07 PM 10/27/2005, Matt Hogstrom wrote: I think for those platforms you mention below the IBM is the only JDK to choose from. Although, on Windows and Linux its a pretty good choice too :) Of course I would beg to differ ;) Have you fired G up on JRockit yet? I'd be curious to compare performance data. I know it works. I don't have any hard numbers that I can share. andy
Re: Trifork CORBA
On Oct 27, 2005, at 5:06 PM, Andy Piper wrote: The latest JRockit implements the appropriate parts of Unsafe - I know because I made them put it in so that I could implement the WebLogic ValueHandler on top of it. But why not just use the VM's ValueHandler? The Sun and IBM one's are both pretty reasonable now. The Trifork RMI/IIOP has a quite decent implementation of all of the javax.rmi.CORBA stuff that we can bring right in with little modification, so I was thinking that we should use that. However, if you know that those ValueHandlers are good, we can definitively make things less complicated by using them. Kresten
[jira] Updated: (GERONIMO-956) Remove "global JNDI space"
[ http://issues.apache.org/jira/browse/GERONIMO-956?page=all ] David Jencks updated GERONIMO-956: -- Fix Version: 1.x (was: 1.0) > Remove "global JNDI space" > -- > > Key: GERONIMO-956 > URL: http://issues.apache.org/jira/browse/GERONIMO-956 > Project: Geronimo > Type: Improvement > Components: connector, naming > Versions: 1.0-M4 > Reporter: Aaron Mulder > Assignee: David Jencks > Fix For: 1.x > > Geronimo has a "global" JNDI space under "geronimo:". However: > - it's only used by connectors, not EJBs > - it's not visible outside the current VM > It doesn't seem like this is really benefitting anyone. The effort necessary > to make it behave like JNDI behaves in other popular app servers seems to be > significant. After talking on IRC, David J and I are soliciting feedback on > removing this feature entirely for now. > Note: this is different than the JNDI space that OpenEJB uses to expose EJBs > to remote clients, which takes EJBs only and is obviously accessible to > remote clients. We are not proposing to change that at this time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-906) Component references involved in transaction recovery are too complicated
[ http://issues.apache.org/jira/browse/GERONIMO-906?page=all ] David Jencks updated GERONIMO-906: -- Fix Version: Wish List (was: 1.0) > Component references involved in transaction recovery are too complicated > - > > Key: GERONIMO-906 > URL: http://issues.apache.org/jira/browse/GERONIMO-906 > Project: Geronimo > Type: Bug > Versions: 1.0-M5 > Reporter: David Jencks > Assignee: David Jencks > Fix For: Wish List > > The connection manager gets a reference to the TransactionContextManager, > which ought to be enough. However, the TransactionManagerImpl has a > reference collection that the MCFWrapper registers with, the TM then calls > the recovery methods. > We should be able to move the recovery methods to TCM and have the connection > manager call them after it has started. We'll also have to look into what to > do with the MDB/inbound recovery. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-799) distributed transactions not yet implemented
[ http://issues.apache.org/jira/browse/GERONIMO-799?page=all ] David Jencks updated GERONIMO-799: -- Fix Version: Wish List (was: 1.0) > distributed transactions not yet implemented > > > Key: GERONIMO-799 > URL: http://issues.apache.org/jira/browse/GERONIMO-799 > Project: Geronimo > Type: Bug > Components: transaction manager > Versions: 1.0-M4 > Reporter: David Jencks > Assignee: David Jencks > Fix For: Wish List > > We don't transfer transactions between vms. This prevents actual corba tx > interop and app client UserTransaction for remote calls. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-872) Jetty does not verify servlet mapping against the servlets
[ http://issues.apache.org/jira/browse/GERONIMO-872?page=all ] David Jencks updated GERONIMO-872: -- Fix Version: 1.x (was: 1.0) > Jetty does not verify servlet mapping against the servlets > -- > > Key: GERONIMO-872 > URL: http://issues.apache.org/jira/browse/GERONIMO-872 > Project: Geronimo > Type: Bug > Components: web > Versions: 1.0-M4 > Reporter: Jeff Genender > Assignee: David Jencks > Fix For: 1.x > > The in the web.xml are not verified against > the . > As it stands, the servlet-mapping can reference a servlet that does not exist. > The JettyModuleBuilder should throw an exception with this condition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-250) Connector tries to commit after connection error
[ http://issues.apache.org/jira/browse/GERONIMO-250?page=all ] David Jencks updated GERONIMO-250: -- Fix Version: 1.x (was: 1.0) > Connector tries to commit after connection error > > > Key: GERONIMO-250 > URL: http://issues.apache.org/jira/browse/GERONIMO-250 > Project: Geronimo > Type: Bug > Components: connector > Versions: 1.0-M2 > Reporter: Simon Godik > Assignee: David Jencks > Fix For: 1.x > > If a resource adapter indicates a connection has had a fatal error, then the > connection manager destroys the managed connection but still attempts to > commit/rollback at transaction end. This is bad as the connection has already > been destroyed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-268) Connection Error handling problems
[ http://issues.apache.org/jira/browse/GERONIMO-268?page=all ] David Jencks updated GERONIMO-268: -- Fix Version: 1.x (was: 1.0) > Connection Error handling problems > -- > > Key: GERONIMO-268 > URL: http://issues.apache.org/jira/browse/GERONIMO-268 > Project: Geronimo > Type: Bug > Components: connector > Versions: 1.0-M2 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.x > > A managed connection that encounters a fatal error and calls > ConnectionErrorOccured on the GeronimoConnectionEventListener may not have > the resources held by geronimo cleaned up properly. > In particular, if several ejbs have handles to this mc, the connection > tracking won't work properly. Only the currently active component (ejb) will > have it's handle(s) removed from tracking. When the other handles are > disociated or closed, errors are likely, such as putting the destroyed > managed connection back into the pool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-383) xmlbeans magic allows us to accept some invalid deployment descriptors
[ http://issues.apache.org/jira/browse/GERONIMO-383?page=all ] David Jencks updated GERONIMO-383: -- Fix Version: 1.x (was: 1.0) > xmlbeans magic allows us to accept some invalid deployment descriptors > -- > > Key: GERONIMO-383 > URL: http://issues.apache.org/jira/browse/GERONIMO-383 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M2 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.x > > The element reordering and other xmlbeans magic we do to convert pre-1.4 > deployment descriptors to 1.4 versions can have the unintended side effect of > converting invalid 1.4 descriptors to valid ones. This has been fixed in > SchemaConversionUtils.convertToServletSchema for servlet 1.3 web.xml. We > should apply this same fix of checking for namespace before conversion to > other modules (ejb etc) and extend the checking to: > 1. look for the DOCTYPE using xmlbeans > 2. converting to a made-up namespace for that dtd > 3. validating against xmlbeans objects for the schema corresponding to the > dtd. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-434) Connection factories extracted from conceptually wrong gbean
[ http://issues.apache.org/jira/browse/GERONIMO-434?page=all ] David Jencks updated GERONIMO-434: -- Fix Version: 1.x (was: 1.0) > Connection factories extracted from conceptually wrong gbean > > > Key: GERONIMO-434 > URL: http://issues.apache.org/jira/browse/GERONIMO-434 > Project: Geronimo > Type: Bug > Components: connector > Versions: 1.0-M4 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.x > > Currently connection factories/datasources (or their proxies) are obtained > from the JCAManagedConnectionFactory gbean. Since there is a > ConnectionFactory/Datasource gbean for the jsr-77 requirements, it would make > more sense to obtain the connection factory/datasource from there. This > would have the additional feature of allowing one to set up several > connection factories under different names that all use the same > ConnectionManager and ManagedConnectionFactory. This would for instance let > you set up separately named QueueConnectionFactory and TopicConnectionFactory > that share the same connections: named appropriately, this can let you leave > out resource-refs in plans for apps that call the factories different names. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-452) XAResource.setTransactionTimeout never called
[ http://issues.apache.org/jira/browse/GERONIMO-452?page=all ] David Jencks updated GERONIMO-452: -- Fix Version: Wish List (was: 1.0) > XAResource.setTransactionTimeout never called > - > > Key: GERONIMO-452 > URL: http://issues.apache.org/jira/browse/GERONIMO-452 > Project: Geronimo > Type: Bug > Components: transaction manager > Versions: 1.0-M2 > Reporter: David Jencks > Assignee: David Jencks > Fix For: Wish List > > Whether or not you supply a transaction timeout to the tm, we never try to > propagate this to the xaresources enrolled in the tx. It certainly isn't > clear what it would mean if it were called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-623) ejb timer sometimes doesn't get cancelled when ejb is undeployed.
[ http://issues.apache.org/jira/browse/GERONIMO-623?page=all ] David Jencks updated GERONIMO-623: -- Fix Version: 1.1 (was: 1.0) I think this is actually fixed but doubt I'll have time to prove it before 1.0 > ejb timer sometimes doesn't get cancelled when ejb is undeployed. > - > > Key: GERONIMO-623 > URL: http://issues.apache.org/jira/browse/GERONIMO-623 > Project: Geronimo > Type: Bug > Components: OpenEJB > Versions: 1.0-M3 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.1 > > In some unknown circumstances an ejb timer can not get cancelled and > continues firing even after the ejb has been undeployed. This results in a > stack trace like this: > 23:18:26,695 INFO [TransactionalExecutorTask] Exception occured while > running user task > java.lang.RuntimeException: Dead proxy for ejb > geronimo.server:EJBModule=modulename.jar,J2EEApplication=appName,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=ejbName > at > org.openejb.timer.BasicTimerServiceImpl.getTimerById(BasicTimerServiceImpl.java:204) > at > org.openejb.timer.BasicTimerServiceImpl$EJBInvokeTask.run(BasicTimerServiceImpl.java:256) > at > org.apache.geronimo.timer.TransactionalExecutorTask.run(TransactionalExecutorTask.java:57) > at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:552) > I'm going to put in some temporary hacks to BasicTimerServiceImpl so this > message only gets printed once even though the timer keeps firing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-513) jndi refs should result in dependencies, optionally
[ http://issues.apache.org/jira/browse/GERONIMO-513?page=comments#action_12356179 ] David Jencks commented on GERONIMO-513: --- Missed this file in initial commit: Sendingmodules/web-builder/project.xml Transmitting file data . Committed revision 329132. > jndi refs should result in dependencies, optionally > --- > > Key: GERONIMO-513 > URL: http://issues.apache.org/jira/browse/GERONIMO-513 > Project: Geronimo > Type: New Feature > Components: naming > Versions: 1.0-M3 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0 > Attachments: jndi-dependencies.diff, jndi-dependencies.diff > > After non-reference gbean dependencies (GERONIMO-512) are implemented, jndi > refs should result in creating these dependencies. They need to be optional > to take account of (at least) these scenarios: > 1. circular ejb references A uses B uses A. > 2. An ejb has 2 resource refs: if the first one isn't available, it tries the > backup second one. > So, the naming schema needs an optional tag to prevent a ref from > turning into a dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1116) LocalAttributeManager should allow command line override of its configuration file
[ http://issues.apache.org/jira/browse/GERONIMO-1116?page=all ] David Jencks closed GERONIMO-1116: -- Resolution: Fixed Sending modules/system/src/java/org/apache/geronimo/system/configuration/LocalAttributeManager.java Transmitting file data . Committed revision 329133. > LocalAttributeManager should allow command line override of its configuration > file > -- > > Key: GERONIMO-1116 > URL: http://issues.apache.org/jira/browse/GERONIMO-1116 > Project: Geronimo > Type: Bug > Components: core > Versions: 1.0-M5 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0 > > Now that all the user-modifiable config info and the list of configs to start > are in the config.xml, we can provide a system property to override the > location of the config.xml file used. I'm going to start with > org.apache.geronimo.config.file -- 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
